Subject: Re: [scim] entitlements & roles attributes

From: Chris Phillips <[email-masked]>
Date: Fri, 1 Aug 2014 16:25:00 +0000

Hi,
Just catching this thead during summer holidays,  apologies if I didn't track it all and for late replies over the next week or so.

To Kelly's question:
What’s the lesser of the evils?  To have an underspecified standard attribute or a non-specified custom attribute that a bunch of folks will probably want to use?

I put forward that the lack of specificity is valuable. Anyone wanting to use their own  groups, roles, and entitlements values can work within the core is better than always working in custom attributes and hoping your endpoints have them.

I believe this highlights the question around WHERE you want to apply a policy about what is contained in the attributes (to me, policy equates to constraints not written into the spec)
So where does policy begin and end? I believe the usually answer is around who can connect to your endpoints.  That's your permitter where your policy is adhered to/enforced by someone/adopted by those who connect)

To look back at another similar problem space to see what happened, take a look at the HTML spec(RFC1866) around the forms section 8.
It doesn't specify valid names nor valid values for form fields.
The strength of this is that it has allowed any arbitrary combinations that were not thought of when the spec was written. It was prescriptive 'enough'.

In one respect, SCIM is much like the HTML spec but for identity data.
Prescriptive enough as a specification, but open ended  enough to allow flexibility.

Moving things around with respect to roles, groups, and entitlements was in ticket #11[1] and was closed as 'won't fix.
 I (subjectively) think was due to lack of sufficient discussion about the comments raised in the ticket due to larger fish to fry in other tickets.

Now that some of the other items are behind us, and this topic is resurfacing, maybe now is the time to dig a bit deeper to some of the points..?

Chris.

Other items related to this thread:

Should attributes like this be collapsed?[2]
Original use cases for the attributes: [3]
One way entitlements can be described: [4]

[1] http://trac.tools.ietf.org/wg/scim/trac/ticket/11
[2] https://www.ietf.org/mail-archive/web/scim/current/msg00237.html
[3] http://groups.google.com/group/cloud-directory/msg/41d160f6d0edddb6?
[4] https://www.internet2.edu/media/medialibrary/2013/09/04/internet2-mace-dir-eduperson-201203.html#eduPersonEntitlement

From: Kelly Grizzle <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 31 July, 2014 10:31 PM
To: "Morteza Ansari (moransar)" <[email-masked]<mailto:[email-masked]>>, Ian Glazer <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] entitlements & roles attributes

I’m not sure that I would say that there is no interoperability.  The client just has to have some knowledge about what the server supports for values here (maybe through /Entitlements and /Roles extended resource types?).  Of course, the same values probably wouldn’t work on both SF and Cisco servers.

I agree with you, though, that complex attributes are warranted for some cases of roles and entitlements.  I’d be interested to hear from some of the folks that have implemented SCIM servers if they make use of these or whether they would have any opposition to dropping them.

IIRC they were added because it was thought that most SPs would have some notion of roles, entitlements, groups, or some combination of them, and that if they were left out of the schema that there would be more interop problems because everyone would have custom extensions for these.

What’s the lesser of the evils?  To have an underspecified standard attribute or a non-specified custom attribute that a bunch of folks will probably want to use?

From: scim [mailto:[email-masked]] On Behalf Of Morteza Ansari (moransar)
Sent: Thursday, July 31, 2014 6:31 PM
To: Ian Glazer
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] entitlements & roles attributes

I don’t think there is any impact as there is no interoperability possible given the semantics of the attributes are undefined. How could a client provision a value for this attribute if the definition of that value is different from SF to Cisco to the next vendor?

Cheers,
Morteza

From: Ian Glazer <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 31, 2014 at 6:59 PM
To: Morteza Ansari <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] entitlements & roles attributes

A fine can of worms you've cracked into ;-)

I totally understand the need for complex attributes for roles. But I am little worried about the implications of dropping them from the core spec. Any thoughts on what the impact would be?

On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:
Speaking as an implementer:

In our implementation, we have a new use case where we need the entitlement and roles attributes to be complex. This is for cases where a user has an entitlement to a service with further qualifier.  Similarly for the roles attribute there are cases where a simple string is not sufficient and role may require additional parameters and a complex object would nicely solve the problem.

The spec is very vague on these two attributes intentionally because the authorization model at various vendors are so different that it seemed impossible to come up with a single model to cover them all.  As such the attributes were left in the spec but they are essentially implementation specific.

As this use case came up I was thinking about this and to be honest I am not sure why we have these in the core spec to begin with.  If we don’t define the semantics of the attributes we are not helping with interoperability and if anything we make it more difficult for clients and vendors to do what they need for these attributes. I would like to propose we drop these two attributes from the core spec and implementors either add these as their specific extensions.  This also has a very nice benefit that if at some point we come up with a common model to handle entitlements, we could define an extension to the core user object with its semantics well defined for interoperability.

Thoughts?

Cheers,
Morteza

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer<https://twitter.com/iglazer>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Aug 2014 10:02:07 -0700

+1.  Nice analysis.

Phil

@independentid
www.independentid.com
[email-masked]

On Aug 1, 2014, at 9:25 AM, Chris Phillips <[email-masked]> wrote:

> From: Kelly Grizzle <[email-masked]>
> To: "Morteza Ansari (moransar)" <[email-masked]>, Ian Glazer <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Cc: [email-masked]
> From: Ian Glazer <[email-masked]>
> To: Morteza Ansari <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) <[email-masked]> wrote:
> [email-masked]
> @iglazer
> [email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Mon, 04 Aug 2014 09:48:40 +0200

On 2014-08-01 00:59, Ian Glazer wrote:
> I totally understand the need for complex attributes for roles. But I am
> little worried about the implications of dropping them from the core
> spec. Any thoughts on what the impact would be?
> 

<nohat>

I agree. I'd say we should keep entitlement explicitly a string value
and leave more complex ACIs for extensions.

As an aside there have been several successful deployments of
parametrized ACIs that nevertheless are represented as strings. One
such is
http://www.swami.se/download/18.248ad5af12aa8136533800044/gmai.pdf and
another is MIT PERMIT. Most of them seem to fall into
a same subject-object-constraints.

</nohat>