[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Groups vs. Roles
see embedded comments > -----Original Message----- > From: Pierangela Samarati [mailto:samarati@pinky.crema.unimi.it] > Sent: Wednesday, July 25, 2001 7:04 AM > To: Simon Y. Blackwell > Cc: 'xacml@lists.oasis-open.org' > Subject: Re: Groups vs. Roles > > > Hi, > > > For all roles R, there exists a group G such that all > members M of G have > > role R. > > yes and no. I can see this to be the case in many situations > but it is not > required. I agree that it is not required. Its just that logically there is at least some implicit group. > > > It is not true that for all groups G, there exists a role R > such that all > > members M of G have role R. For example, the group of > workers in the US may > > have a certain set of privileges based on their group. > However, they won't > > all have the same role. > > that's right. > > The difference between groups and roles is that groups are > sets of users, > which you collectively refer to with a name (e.g., Employee, > US-citizens, > Programmers, ....). > > Roles are "sets of privileges". Intuitively, they are > privileged hat that > users (authorized for that) can put on and take off as needed. In a > centralized organizational environment roles usually correspond to > organizaional responsibilities (e.g., manager, secretary, dean, > Dept-chair, ....) to which you associate privileges. In a role-based > context authorizations to access objects are granted to > roles. Users are > then granted authorizations to activate roles. By activating a role, a > user can execute all accesses for which the role is authorized. For > instance, in a hospital you can have a "doctor" role that is > authorized > to prescribe medicines. If Jane is authorized to activate the role, by > doing so, she will be allowed to prescribed medicine. This > ability will go > away when she releases the role. > > Simon, w.r.t. your point that for every role there is a group of users > authorized for that role, it can be so but it is not necessarily so. > For instance, you may have the same concept that you capture with a > semantic of a group and of role. As an example, you can have a group > "Doctors" and a role "doctor". Group "Doctors" will have all the > privileges that you intend to grant to all users who are doctors. Role > doctors will have all privileges that you intend to grant to > users only > when they are operating in that specific role. If this is the > case you can > indeed grant the authorization to activate role doctor to > group Doctors > (instead than specifying one authorization for each individual). > > do you agree? Yes > > In a distributed scenario i've seen the use of the term > "role" also used > to intend a more generic form of "dynamic activation" of > privileges, not > necessarily regulated by authorizations to activate roles. > For instance, > in a distributed setting you may have a certificate-based > access control > where access is granted depending on digital certificates requestor > presents. For instance, you may say that users presenting a > membership > certificate in ACM can access a given digital library. Although these > are not properly roles, the behavior is similar: by presenting the > certificate i can exercise given privileges that i would not > otherwise (in > this sense it is like activating a role). > > best > > -p > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC