Ersin pointed me to a very interesting paper http://csrc.nist.gov/
rbac/rbacSTD-ACM.pdf that has considerably influenced my ideas on
where tsec should head, and some of the ideas from that paper are (I
hope) represented in my comments below.
On Jan 25, 2007, at 11:02 AM, Alex Karasulu wrote:
Hello,
I would like to have a discussion on the meaning of these entities
in general and with respect to how they are modeled in Triplesec
today in the trunk:
o Permissions
o Roles
I think these are useful abstractions
o Groups
I don't think groups are a useful abstraction if you have the right
kind of roles.
I also don't think it's possible to discuss this subject without also
including Users and User-Role associations.
I've been talking to djencks about this stuff for a bit now as we
have started working together on various aspects of Triplesec. I'd
like to have a general discussion about these concepts here so we
can all be on the same page with what they are.
To me, we get to define our terms, and then they mean what we say the
mean. I don't see any of these concepts as having an immutable
meaning outside what we want the system to do.
Also to set the context here, I think the overall goal is to start
with something representing the identity of a person using the
system, possibly some other description of the activities they wish
to perform, and determine what they are allowed to do in the system.
Let me kick this off.
Permissions
===========
To me a permission is a right that is granted to access a resource
or perform some kind of protected operation. To a large degree the
semantics of permissions are undefined except within a specific
application. For example the permission to accessPayroll may not
have much meaning outside of an application dealing with payroll
management.
In Triplesec (trunk) a permission is just a label without any
meaning. The semantics of the permission is left up to the
application to define.
I basically agree with this, the label is a meaningless abstract
identifier. We do need to make sure we can attach more information
to the label for specific uses, e.g. attaching sufficient information
to construct a java permission for use in java apps. I've done this
in sandbox/triplesec-jacc2.
Roles
=====
A Role is a collection of permissions associated together to
represent the rights need by one to perform the actions or
activities of a function. For our purposes we can just say a role
is a collection of permissions.
As a collection of permissions which are application specific,
roles themselves become application specific.
In Triplesec (trunk) a role is just a collection of granted
permissions with a name. Roles entries in Triplesec have a SINGLE-
VALUED 'roleName' and a MULTI-VALUED 'grants' attribute. You just
add the names of permissions to a role entry to add them to the role.
This is really making a big assumption about the meaning of
permissions, namely that they aren't overlapping in any way, so that
to deny a permission you just remove it from the set of granted
permissions. If permissions overlap, as java permissions can, you
really need to be able to deny permissions as well. So you need to
have roles have a set of granted permissions and a set of denied
permissions.
Furthermore, as suggested in the NIST paper, hierarchical roles
provide great power and convenience for administering roles and
permissions. They're fairly trivial to implement in terms of the
data model, and you don't have to use them if you don't want to. So
I'd say a role is <name, grantsSet, denialsSet, rolesSet}
Note that with this role model, you can easily represent any
combination of existing roles, with individualized tweaks, as another
role. Therefore we can represent any set of permissions as a role.
To avoid duplication of concepts we should represent every
interesting set of permissions as a role.
Very little I have to say makes sense if you disagree with this....
the following is predicated entirely on this model of a role. If you
don't agree, stop here and lets talk about why.
Groups
======
Although you can group anything I think we're talking more about
groups of users in this context. Groups are primarily used to make
administration tasks easier. By grouping people and the can be
managed as a single group rather than performing the same upkeep
operations on all the members of the group.
In Triplesec a group is a static LDAP group (groupOfUniqueNames) or
user DNs right now. We may expand this to include dynamic groups
in the future.
OK, here's where we part company :-) As the nist paper points out,
the idea of groups is a precursor to the idea of general RBAC. We
definitely need a concept of identity (user), and we definitely need
a concept of set of permissions (role), and we definitely need a
concept of associating these two. Alex is proposing at least two
mechanisms for associating a user and a set of permissions. I'm not
happy with any of the existing associations and think we can do better.
I think these are the requirements:
each user can be associated with several sets of permissions (roles)
each set of permissions (role) can be associated with several users
at any time, at most one role can be active for a user
If we had a relational database this would be pretty easy to model --
a table with 2 columns, userId, and roleId, both part of the pk, and
the db would figure out how to navigate for us. However since we are
in a navigation-oriented database the best data model depends on the
expected access pattern. This unfortunately leads into a discussion
of typical login capabilities.... Lets start by assuming that we
start by identifying the user and then try to choose what role to put
them in, and exactly how we do that is not determined. Note that
this is NOT how triplesec is currently organized.
Having decided on an access pattern, our model should look like
UserRoles { userId, roleSet}. With this model groups are not needed,
nor are profiles which Alex didn't mention.
Lets look at how groups and profiles get modeled now.
groups: The purpose of the administration simplicity alex mentioned
is to assign a user to a set of permissions. The set of permissions
is a role, so you add the role to the users roleset. This is the
same action as assigning a user to a group, looked at from the other
end of the relationship.
profiles: profiles currently have 2 functions, constructing a set of
permissions out of other roles, and associating that set of
permissions with a user or group. The set of permissions is now a
role, so the remaining function is associating that role with one or
more users. This is done by adding the role to the UserRoles for
each user involved.
------------
Alternate suggestion
As noted profiles currently combine specifying a role (my
hierarchical definition) with associating a user with the role. If
we take out the aspect of subclassing role, we are left with a
profile containing a unique name, a user id, and a roleId. This is an
acceptable alternative data model for a n-n user role association,
although there is no obvious uniqueness constraint on (userId,
roleId). Here the user would identify themselves using the
profileId, the login framework would lookup their userId and
authenticate them using that, then we would determine the role from
the roleId. This is the same access pattern as currently in triplesec.
With this alternate suggestion the admin actions are basically the
same as with the first suggestion, except you add/remove profiles
rather than modifying UserRole contents. In either case groups
aren't needed.
My basic philosophical objection to including something called a
group in our model is that it duplicates the ideas we model better in
roles and user-role association.
Hopefully this is sufficiently coherent that everyone can understand
what I'm trying to say :-)
thanks
david jencks
Thoughts? Corrections?
Alex
<akarasulu.vcf>
