directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [Triplesec] [AuthZ] Role Assignment
Date Tue, 30 Oct 2007 21:56:29 GMT

On Oct 24, 2007, at 10:36 AM, Alex Karasulu wrote:

> Role Assignment
> -------------------------
>
> Once an application is deployed, identities must be granted  
> permissions to be
> authorized to perform operations and access resources.  Assigning  
> permissions
> one at a time to users is unmanageable and prone to error.  Role  
> based access
> control arose primarily from this requirement to associate  
> permissions within
> roles and assign roles to identities rather than permissions  
> directly.  This way,
> identities that have roles assigned to them, are granted the  
> permissions associated
> with their assigned roles.
>
I completely agree.

> There are several benefits to RBAC which I won't go into in this  
> section but consider
> the impact of a change in the application which alters a role by  
> adding a new permission.
> Most administrators, I am sure, would prefer to add a new  
> permission to a role and
> have that trickle down to users, rather than modifying each user in  
> the system to have
> this new permission.
>
I agree.

> Role assignment during and after deployment is required for  
> identities to fulfill their
> designated functions within applications and systems.  Role  
> assignment can be done
> on a per principal basis and should be allowed.  However doing so  
> for every assignment
> would not be very tractible especially within the scale of an  
> enterprise.  Role assignment
> to groups must be possible to make management feasible at medium to  
> large scales.
> Role assignment is a task required of application and system  
> administrators.  Role
> assignment begins as part of an application's deployment yet it  
> continues indefinately as
> an operational overhead while identities are created, destroyed,  
> regrouped and allowed to
> access the application at with various roles.
>
Here's where I start having problems.  As noted earlier, to me the  
only grouping we can be thinking about in the context of an  
authorization manager is to say that we want to grant a set of people  
the same permissions.  We already have the Role concept which is the  
set of permissions we're interested in, whether they are directly  
assigned to the role or via the role partial ordering or  
inheritance.  So the simplest thing to do is to, as we identify the  
people in this set, associate them with the role that represents the  
set of permissions we want them to have.

Another way to say this is that I think roles and groups are the same  
concept so we should only use one name for it.  We certainly agree  
that we want to be able to associate users and roles.  Now if I  
understand what you are proposing it is to have a "group" which has a  
set of users associated with it (like a role) and has roles  
associated with it.  Except for you calling it a group, that's a role  
that happens to get all its permissions from the partial ordering or  
inheritance rather than through direct assignment.  I don't think we  
need two names for the same concept.

I recognize that there are existing systems that already have lots of  
users registered in them and the users organized into "groups".   
However, my understanding is that we are trying to come up with terms  
we agree will be most useful for discussing an authorization manager,  
so I don't think basing our terminology on someone else's  
implementation decisions no matter how popular they are is  
necessarily the best idea.

And another thing :-).  I think there's this idea floating around to  
the effect that sometimes a user may be authorized to do one kind of  
job and sometimes authorized to do another kind of job, although they  
are the same user.  My understanding of the Profile idea in triplesec  
trunk is that it was intended to support this.  There are probably  
other ways to describe this, but until someone has a problem with it  
lets describe this as the user being in one set of roles or another  
set of roles for the two kinds of jobs.  AFAICT the only reason to  
separate the sets of roles is if there is some kind of constraint  
preventing the user from being in all the roles at once.  Some people  
(well the NIST guys anyway) call this kind of constraint "separation  
of duty".  They suggest modeling them by saying, a user has  
associations with a set of roles, which are all the roles they could  
possibly be in.  In addition, there's a user Session, which is  the  
set of roles they happen to be in right now.  Now you can have static  
separation of duty constraints which say a user can't be associated  
with all of some set of roles (in the more static, user-role  
association) or dynamic separation of duty constraints which say that  
a session can't have all of some set of roles in it at once.

Now its kind of a small point, but when I think of users being in  
groups, it seems to me that they are always in those groups, so when  
I start wondering where to put some kind of SOD constraint in it gets  
pretty hard to see where to put it.... are user-group assignments  
temporary?  Are group-role assignments temporary? Are role-permission  
assignments temporary?  None of these quite seem to feel right to  
me.  When I think of the role-permission association being fixed then  
putting the roles the user is currently in into a session feels like  
a very simple and natural solution to me.

Finally, I'm worried that we are in danger of lumping two kinds of  
relationships under one name.  We seem to agree that users and roles  
need to be associated, and I put this into my suggested role  
definition a couple emails back in this series.  If we have groups,  
then we also need group-role assignments.  Even if its possible to  
model two kinds of relationships with the same structure using a  
particular technology such as ldap object classes, if they have  
significant differences in meaning I think we should recognize that  
and avoid using the same name for them.  So to me it makes much more  
sense, assuming we do have groups, to have user-role assignments and  
group-role assignments, and to carefully distinguish which one (or  
both) we are talking about.

thanks
david jencks

> Alex


Mime
View raw message