Subject: [scim] draft-grizzle-scim-pam-ext-01: Section 3.3, 3.4 - behavior of authorization granted outside scope of SCIM

From: "Matt Peterson (mpeterso)" <[email-masked]>
Date: Tue, 23 Jan 2018 22:05:39 +0000

SCIM itself is possible because there are common models for Identity management that are built into applications (users, groups, etc) that have been inherited through the mature patterns and legacy of X509 directories.  SCIM was an opportunity to standardize a simple protocol on top of a well-established model.

It is notable that SCIM itself is explicitly NOT designed not for authorization management.  SCIM recognizes that authorization models vary widely from application to application and that SCIM would not be able to cover both identity management and authorization management. 

True, an argument could be made that SCIM's ability to manage groups is a form of authorization management, but in this case SCIM is on solid ground due to the prolific use of "group of users" concept in software applications.  SCIM allows management of the "groups", not what the groups can do.

SCIM specification makes several attempts to clarify the the scope of SCIM using statements like the following:
 
RFC 7643 section 4.2  -
   ...although no explicit authorization model is defined.  It is intended
   that the semantics of group membership, and any behavior or authorization
   granted as a result of membership, are defined by the service provider; these are
   considered out of scope for this specification.

The pam-ext draft suggests that there is a common authorization model that would be interoperable for SCIM clients of PAM services.  We are suspicious.  As evidence, there are several very important attributes that make up the proposed authorization model that are defined as implementation-specific, free-form strings.  

PrivilegedData.type 
PrivilegedDataPermission.rights
ContainerPermission.rights

>From the perspective of a SCIM Client, the model presented has minimal interoperability value for a read-only (i.e. GET verb only) SCIM client, and almost no interoperabilty value for a SCIM client that needs to actually write (POST,PUT) to these collections.

It would be good if there was more public discussion about whether or not the model described in the pam-ext draft in sections 3.3-3.4 is 1) Implementable by PAM software, and 2) useful to SCIM client.