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
