RE: Groups vs. Roles

["Simon Y. Blackwell" <sblackwell@psoom.com>]

Not sure we are debating anything. I am simply putting forward what I have
found as potential definitions of group and role in the context of a
discussion that occurred at the F2F. The purpose, I think, would be your
alternative number 2. Hopefully, this is not inconsistent with alternative
1; although, it might be.

What is most useful to me is that you have pointed to further work in the
area.

> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Friday, July 27, 2001 7:29 AM
> To: 'Simon Y. Blackwell'; 'Pierangela Samarati';
> 'xacml@lists.oasis-open.org'
> Subject: RE: Groups vs. Roles
> 
> 
> Simon,
> 
> I just re-read this entire thread and I cannot figure out who you are
> quoting and to what purpose (agreement or disagreement).
> 
> More importantly, I am not clear on what exactly we are debating.
> 
> Is the question:
> 
> 1. What are the most generally understood meanings of Group 
> and Role, with
> particular attention to their distinguishing characteristics, in the
> Information Security field today?
> 
> or
> 
> 2. What would the most useful meanings to apply to Group and 
> Role for the
> purposes of XACML, which are also largely consistent with common and
> technical usage of the terms?
> 
> I think #2 would be most productively debated in the context 
> of a specific
> Authorization Model proposal.
> 
> I will confine my comments here to #1.
> 
> Group is pretty well understood as a simple aggregate.
> 
> Role on the other hand is used in literally hundreds of 
> different ways. To
> make it worse, in some cases, the "official description" 
> states the intended
> use, rather than the actual semantics of Role. We recently 
> encountered a
> case of this in the context of EJB security.
> 
> In my mind the people who have done the most thorough job of 
> figuring our
> what people mean by role and what useful features roles might have is
> Sandhu, Ferraiolo, and Kuhn, the NIST RBAC people.
> 
> Their latest paper is at:
> http://www.list.gmu.edu/confrnc/rbac/pdf_ver/rbac-nist.pdf 
> 
> (Note, this is not linked to from the NIST RBAC page.)
> 
> They identify 7 useful properties Roles might have. (They say 
> four, but 3 of
> the 4 have two sub levels each.) Originally they called it 4 
> Levels, but in
> an appendix to their latest paper they correctly recognize 
> that only flat
> vs. hierarchical forms any kind of linear sequence. The 
> others are just
> independant characteristics along different dimensions. 
> 
> Actually the paper identifies 9 additional Role attributes 
> for a total of
> 16. They say "RBAC is a rich and open-ended technology." This 
> statement
> suggests to me that definition will be difficult.
> 
> I do not agree that all their ideas are necessarily useful or 
> practical in
> large scale distributed environments. Nor do I think they 
> have necessarily
> captured every useful property thet Roles might have. 
> However, they have
> done a lot of work on this and it represents the best 
> baseline on Roles I
> have seen.
> 
> Specifically, they state that their first category, "Flat Roles" are
> identical to Groups. I won't recapitulate the entire paper, 
> except to note
> that Dynamic Seperation of Duty captures the notion of assuming Roles,
> mentioned previously in this thread.
> 
> Actually, a recent discussion in the context of JSR 115 has 
> made me realize
> that the important, high-level distinction is between 
> Attributes of a User
> and Attributes of a User Session. Examples:
> 
> User Attributes
>  Group
>  Clearance
>  Approval Limit
>  Organization
>  Authorized Roles
> 
> User Session Attributes
>  Date/time of Authentication
>  Method of Authentication
>  Currently Enabled Role(s)
> 
> Hal
>  
> 
> > -----Original Message-----
> > From: Simon Y. Blackwell [mailto:sblackwell@psoom.com]
> > Sent: Thursday, July 26, 2001 10:42 PM
> > To: 'Pierangela Samarati'; 'xacml@lists.oasis-open.org'
> > Subject: RE: Groups vs. Roles
> > 
> > 
> > Here's the full quote:
> > 
> > "Roles provide a semantic grouping of policies with a 
> common subject,
> > generally
> > pertaining to a position within an organisation such as 
> > department manager,
> > project
> > manager, analyst or ward-nurse. Specifying organizational 
> > policies for human
> > managers in terms of manager positions rather than persons 
> permits the
> > assignment of
> > a new person to the manager position without re-specifying 
> > the policies
> > referring to
> > the duties and authorizations of that position [16]. A role 
> > can also specify
> > the policies
> > that apply to an automated component acting as a subject in 
> > the system.
> > Organisational positions can be represented as domains and we 
> > consider a
> > role to
> > be the set of authorisation, obligation, refrain and 
> > delegation policies
> > with the subject
> > domain of the role as their subject. A role is thus a special 
> > case of a
> > group, in which
> > all the policies have the same subject."
> > 
> > The above is clearly in error in at least one way "subject" 
> should be
> > "subject type" or "subject class".
> > 
> > > -----Original Message-----
> > > From: Pierangela Samarati [mailto:samarati@pinky.crema.unimi.it]
> > > Sent: Thursday, July 26, 2001 7:02 AM
> > > To: Simon Y. Blackwell
> > > Cc: 'xacml@lists.oasis-open.org'
> > > Subject: RE: Groups vs. Roles
> > > 
> > > 
> > > Hi
> > > 
> > > > "A role is thus a special case of a group, in which all the 
> > > policies have
> > > > the same subject."
> > > 
> > > ????? i am not sure i understand this......
> > > 
> > > > This would imply that although roles are useful, one never 
> > > has to reference
> > > > a role from a policy. One can simply reference the group 
> > > which has a one to
> > > > one mapping with the named role. This is not inconsistent 
> > > with my first
> > > > statement:
> > > 
> > > i'm not sure ......
> > > 
> > > roles are dynamic by nature and can be activated and released.
> > > 
> > > -p
> > > 
> > 
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: xacml-request@lists.oasis-open.org
> > 
>