Subject: [scim] Proposing permissions/entitlements attribute to group schema

From: Hasini Gunasinghe <[email-masked]>
Date: Sun, 2 Sep 2012 15:10:05 +0530

Hi all,

In the identity management systems that support Role Based Access Control,
groups/roles are assigned a set of permissions/entitlements which are
required to be synchronized across domains along with the corresponding
groups.
Having an optional, multi-valued attribute as permissions/entitlements in
the group schema is useful to facilitate such requirements.

Appreciate thoughts on this.

Thanks,
Hasini.

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 5 Sep 2012 13:32:04 +0000

I agree that this is very useful for identity management systems that provide group management and/or synchronization.  I'm not sure if this is generally useful for the typical SCIM consumer, so I don't know whether it would be better placed in the core or as a standard extension.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hasini Gunasinghe
Sent: Sunday, September 02, 2012 4:40 AM
To: [email-masked]
Subject: [scim] Proposing permissions/entitlements attribute to group schema

Hi all,

In the identity management systems that support Role Based Access Control, groups/roles are assigned a set of permissions/entitlements which are required to be synchronized across domains along with the corresponding groups.
Having an optional, multi-valued attribute as permissions/entitlements in the group schema is useful to facilitate such requirements.

Thanks,
Hasini.

---

From: Hasini Gunasinghe <[email-masked]>
Date: Mon, 10 Sep 2012 13:22:51 +0530

Hi Kelly,

Yes, I get your point. Usually most identity management systems support
authorization management and RBAC has become common.
Therefore having it as an optional attribute in core-group schema will not
make any harm IMO.
Currently 'entitlement' attribute is in core-user schema which facilitate
user based authorization model - which is kind of obsolete.
However, If the majority think it is not useful to have in core-group
schema, we can define a custom extended schema and use.

Thanks,
Hasini.

On Wed, Sep 5, 2012 at 7:02 PM, Kelly Grizzle
<[email-masked]>wrote:

>  I agree that this is very useful for identity management systems that
> provide group management and/or synchronization.  I’m not sure if this is
> generally useful for the typical SCIM consumer, so I don’t know whether it
> would be better placed in the core or as a standard extension.****
>
> ** **
>
> --Kelly****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Hasini Gunasinghe
> *Sent:* Sunday, September 02, 2012 4:40 AM
> *To:* [email-masked]
> *Subject:* [scim] Proposing permissions/entitlements attribute to group
> schema****
>
> ** **
>
> Hi all,****
>
> ** **
>
> groups.****
> the group schema is useful to facilitate such requirements.****
>
> ** **
>
> Appreciate thoughts on this.****
>
> ** **
>
> Thanks,****
>
> Hasini.****
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>

---

From: Chris Phillips <[email-masked]>
Date: Mon, 10 Sep 2012 09:24:34 -0400

I'm supportive of enhancing/decorating the group schema with additional attributes that are relevant to groups specifically.  I see this being  similar in function as  attribute decoration in  the user schema from the perspective that it behaves as a container for useful information about the user.  Keeping attributes relevant and 'just enough' are still key in this context though.

However, if the intent behind the enhancements/attribute decorating is to imply or limit SCIM adopters to a single model such as   'SCIM wants RBAC' or 'SCIM will favour group based access control' then I would say we need to talk this through more as I see this as a negative thing to do.
I doubt this is the case though -- SCIM should be agnostic to any and all access control methodologies but have 'just enough' to minimally support common ones.

Another point, FWIW, entitlements are not obsolete— they have their place and you may not have encountered their use/utility in your environment yet.  The environment I'm in, Research and Education federations, frequently use entitlements across hundreds of Service Providers world wide.   With the Canadian Access Federation dealing with 1/10th the size of higher ed & researchers as compared to the US we are not one of the largest data points. That said, inCommon as the US R&E Fed. certainly ranks up there and has > 800 Service Providers[1] alone and they are just one of 27+ federations[2].

For background, a recent R&E perspective on privilege and access management that talks about groups,entitlements, and more can be found here[3] -- for the TL;DR crowd, slides 23/24 may be of direct interest as this has direct bearing on the interesting bits of schema and provisioning to the R&E community.

C.

[1] http://www.incommon.org/federation/info/all-entities.html
[2] https://refeds.org/resources.html
[3] http://www.incommon.org/docs/iamonline/IAM_Online_2012_08_08.pdf

From: Hasini Gunasinghe <[email-masked]<mailto:[email-masked]>>
Date: Monday, 10 September, 2012 3:52 AM
To: Kelly Grizzle <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] Proposing permissions/entitlements attribute to group schema

Hi Kelly,

Yes, I get your point. Usually most identity management systems support authorization management and RBAC has become common.
Therefore having it as an optional attribute in core-group schema will not make any harm IMO.
Currently 'entitlement' attribute is in core-user schema which facilitate user based authorization model - which is kind of obsolete.
However, If the majority think it is not useful to have in core-group schema, we can define a custom extended schema and use.

Thanks,
Hasini.

On Wed, Sep 5, 2012 at 7:02 PM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
I agree that this is very useful for identity management systems that provide group management and/or synchronization.  I’m not sure if this is generally useful for the typical SCIM consumer, so I don’t know whether it would be better placed in the core or as a standard extension.

--Kelly

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hasini Gunasinghe
Sent: Sunday, September 02, 2012 4:40 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [scim] Proposing permissions/entitlements attribute to group schema

Hi all,

Thanks,
Hasini.

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

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 10 Sep 2012 21:44:17 +0000

It's somewhat of a rat's nest to try to universalize these assertions/attributes  when in reality they must be evaluated from the point of view of individual relying parties.  A universalized authorization fabric is infinitely less likely to succeed than one like OAuth which allows the user to make these decisions on a per-resource basis and then essentially caches the results.  If one wanted to go beyond this it would be a matter of automating the user's decision-making process, not universalizing the authorization statements.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Phillips
Sent: Monday, September 10, 2012 6:25 AM
To: [email-masked]
Cc: Hasini Gunasinghe; Kelly Grizzle
Subject: Re: [scim] Proposing permissions/entitlements attribute to group schema

Another point, FWIW, entitlements are not obsolete- they have their place and you may not have encountered their use/utility in your environment yet.  The environment I'm in, Research and Education federations, frequently use entitlements across hundreds of Service Providers world wide.   With the Canadian Access Federation dealing with 1/10th the size of higher ed & researchers as compared to the US we are not one of the largest data points. That said, inCommon as the US R&E Fed. certainly ranks up there and has > 800 Service Providers[1] alone and they are just one of 27+ federations[2].

C.

Hi Kelly,

Thanks,
Hasini.

--Kelly

Hi all,

Thanks,
Hasini.

---

From: Hasini Gunasinghe <[email-masked]>
Date: Tue, 11 Sep 2012 09:55:58 +0530

On Mon, Sep 10, 2012 at 6:54 PM, Chris Phillips
<[email-masked]>wrote:

> I'm supportive of enhancing/decorating the group schema with additional
> attributes that are relevant to groups specifically.  I see this being
>  similar in function as  attribute decoration in  the user schema from the
> perspective that it behaves as a container for useful information about the
> user.  Keeping attributes relevant and 'just enough' are still key in this
> context though.
>

I'm +1 for keeping the attributes relevant and 'just enough' to make the
schema simple.

>
> However, if the intent behind the enhancements/attribute decorating is to
> imply or limit SCIM adopters to a single model such as   'SCIM wants RBAC'
> or 'SCIM will favour group based access control' then I would say we need
> to talk this through more as I see this as a negative thing to do.
> I doubt this is the case though -- SCIM should be agnostic to any and all
> access control methodologies but have 'just enough' to minimally support
> common ones.
>

I might have not been clear in my previous mails. Proposing
entitlements/permission attribute to Group schema is NOT to motivate that
SCIM supports/favour RBAC at all. Of course, access control is out of scope
of SCIM and why I proposed it was, it would facilitate an Identity
Management System to synchronize group management(which manages
entitlements of groups) through SCIM if we have this attribute. And I
believe it will be a common requirement for many Identity Management
Systems.

>
> Another point, FWIW, entitlements are not obsolete— they have their place
> and you may not have encountered their use/utility in your environment yet.
>  The environment I'm in, Research and Education federations, frequently use
> entitlements across hundreds of Service Providers world wide.
>

Well, I didn't mean that entitlements are obsolete. What I mentioned in my
previous mail was user-centric access control model (for which the
'entitlement' attribute in User schema is mostly useful for) is obsolete
because it doesn't really scale when the number of users grow. And several
alternative models have become popular among which RBAC, ABAC and PBAC with
XACML are some of them to mention.

Thanks,
Hasini.

With the Canadian Access Federation dealing with 1/10th the size of higher
> ed & researchers as compared to the US we are not one of the largest data
> points. That said, inCommon as the US R&E Fed. certainly ranks up there and
> has > 800 Service Providers[1] alone and they are just one of 27+
> federations[2].
>
> For background, a recent R&E perspective on privilege and access
> management that talks about groups,entitlements, and more can be found
> here[3] -- for the TL;DR crowd, slides 23/24 may be of direct interest as
> this has direct bearing on the interesting bits of schema and provisioning
> to the R&E community.
>
> C.
>
>
> From: Hasini Gunasinghe <[email-masked]>
> To: Kelly Grizzle <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> On Wed, Sep 5, 2012 at 7:02 PM, Kelly Grizzle <[email-masked]
> > wrote:
>
>> *From:[email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Hasini Gunasinghe
>> In the identity management systems that support Role Based Access
>> Control, groups/roles are assigned a set of permissions/entitlements which
>> are required to be synchronized across domains along with the corresponding
>> groups.****
>>