Proposal to add additional attributes to SCIM schema: entitlements and roles
chris phillips
Hi all,
I had an action item on the call last week regarding adding a new attribute to the schema. I should be on the call today to talk to about this as well. Here's my proposal:
Enhancing the SCIM schema to allow for additional access control attributes beyond just groups
The current SCIM schema is modelled as a group centric permission model which only addresses a portion of the access control styles that dominate the access control/identity ecosystem. I believe this to lower the utility of the design and will not present as attractive an option to use the protocol.
The current practice that has emerged is that if it isn't in the core, it will be required to be an extension and in my opinion this will have unintended consequences of pushing people and implementers out into areas where adequate stewardship over schema will be the weakest and a battleground of yet more 'do it my custom way'. This achilles heel may eventually fragment our whole effort. So rather than have the value be split 80%/20% for extensions to core, the core should represent a more rich definition of a user and what they are so that it may have better stewardship and yet allow the flexibility of extensions and enhancements that implementers will need. As a side request, I would like to also understand how the group would describe the process of new attributes being promoted into the core schema definition as time goes on.
To this end I propose adding two plural attributes to handle two additional styles of access control as OPTIONAL attributes. The other two styles I propose the SCIM core schema be capable of handling are role based access control (RBAC) where a person object may possess one or more roles held in an attribute called 'roles' which in turn act as a type of privilege mapping and the second is entitlement based access control (EBAC) where a person object has an attribute (aptly named 'entitlements') which is a multivalued attribute of zero or more strings of precomputed entitlements. This would closely track the attribute described as eduPersonEntitlement[1]. No limitations or constraints should be placed on entries in either 'roles', 'entitlements', or group memberships. I fully expect all 3 to be used in various ways at the same time for any given person object.
While one could argue that everything can be constructed as a group to reflect these models, I contend it is a square peg in a round hole exercise. If it is pounded hard enough it will fit, but it takes more energy than it should and it will be expensive on either ends of the protocol to compose and decompose the notion of groups just to support existing models in play. This doesn't quite live up to the expectation of 'simple' in the title of the protocol and will cost us all money and time to implement.
As to how the origin data and destination provisioning endpoint handle the attributes, that is up to their discretion but at least the transformation of role or entitlement doesn't have to be crammed into a group paradigm or a custom extension and then decomposed on the other end.
[1] example: http://www.incommonfederation.org/attributesummary.html#eduPersonEntitlement
see also: https://sites.google.com/site/clouddir/references
Chris.
Samuel Erdtman
//Samuel
On Jun 21, 6:23 pm, chris phillips <cjphill...@gmail.com> wrote:
> Hi all,
>
> I had an action item on the call last week regarding adding a new attribute
> to the schema. I should be on the call today to talk to about this as well.
> Here's my proposal:
>
> beyond just groups*