Subject: [scim] entitlements & roles attributes

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 31 Jul 2014 22:46:49 +0000

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

---

From: Ian Glazer <[email-masked]>
Date: Thu, 31 Jul 2014 18:59:29 -0400

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]> wrote:

>  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]
> 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: Thu, 31 Jul 2014 16:03:35 -0700

One issue is that technically they are multi-valued attrs which means type is a valid sub attr that can be used. 

This might catch some by surprise. 

Phil

> On Jul 31, 2014, at 15:59, Ian Glazer <[email-masked]> 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?
> 
> 
>> On Thu, Jul 31, 2014 at 6:46 PM, Morteza Ansari (moransar) <[email-masked]> wrote:
> @iglazer

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 31 Jul 2014 23:31:01 +0000

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

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

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: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 31 Jul 2014 23:33:07 +0000

Yes, given the vague nature of the definition in the spec one could implement this attribute as a complex but then the client is even in more of risk as other than “value” it knows nothing about the schema. And the schema is not discoverable given it is not an extension.

Cheers,
Morteza

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

Phil

On Jul 31, 2014, at 15:59, Ian Glazer <[email-masked]<mailto:[email-masked]>> wrote:

Thoughts?

Cheers,
Morteza

---

From: Kelly Grizzle <[email-masked]>
Date: Fri, 1 Aug 2014 02:31:42 +0000

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]
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

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