OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Groups vs. Roles


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?


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:

(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
 Approval Limit
 Authorized Roles

User Session Attributes
 Date/time of Authentication
 Method of Authentication
 Currently Enabled Role(s)


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC