[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC