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

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?


> 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