Alex previously proposed some definitions of terms so we can talk
about what Triplesec might do and I, thinking they weren't all that
clear, suggested we use definitions from the NIST paper. Alex quite
rightly pointed out that my proposal has an uncanny similarity to
suggesting putting vaporware into production (those weren't his
words) so I'm going to try to come up with proposed definitions that
I think are the same as the NIST ones, with a tiny bit of motivating
discussion. I'll discuss the problems I see in Alex's definitions in
a separate note. I'm also going to leave out discussion of denied
permissions or roles which although they are pretty useful make
logical analysis of the meaning of a role a lot more complicated.
Lets see if we can agree on the positive aspects before we consider
these negative ones :-)
So, we have actors who want to do stuff to things, and we want to
decide whether to let them. The actors are usually people but might
be services or something else: in any case we'll assume we've figured
out who they are.
-- Users: the set of actors who are trying to do stuff.
-- Objects: the set of things the users are trying to do stuff to
-- Operations: the things the users are trying to do to the objects
We start by grouping the things and objects together into
permissions: a permission is a set of things you can do to a set of
objects. More formally
-- Permissions: the set of subsets of the cross product of Objects
and Operations. (one permission is a subset of Objects X Operations)
A simple permission might be one operation on one object, such as
"read this file foo.xml" but more complicated permissions do show up
such as a javaee web permission "access to urls (in the app) starting
with /myContext/ except for /myContext/private/ and /myContext/
forbidden/"
So we could just directly configure a subset of Users X Permissions
and declare victory, but that is obviously unmanageable. Instead we
group stuff together into roles. On one hand we associate roles and
permissions, and on the other hand we associate roles and users.
-- Roles: the set of roles. (so far they are just names)
So, we associate roles and permissions
-- Role-Permissions the permissions assigned to a role, more formally
a subset of Roles X Permissions
-- Role-Users the users assigned to a role, more formally a subset of
Roles X Users.
I'm about to make things a little more complicated, but for now lets
just say a user in a role gets the permissions assigned to that
role. So if a user is in a set of roles, they get the union of the
permissions assigned to those roles.
So this is better than no roles at all, but with a lot of users or a
lot of permissions, there's still waaaaay too much work to do. So we
need hierarchical roles where a role can have children and/or
parents. So we figure the roles form a directed acyclic graph which
defines a partial ordering on the roles. One very important thing to
notice here is that it appears to go in opposite directions for
permissions and users. If Role1 is senior to Role2 then Role1 has
all the permissions of Role2 (and presumably more) whereas Role2 has
all the users of Role1 (and presumably more). In other words, a
bigger (in terms of permissions) role has fewer users.
Now for the complicating factor. Just like your bank safe deposit
box has 2 keys, one for you and one for the bank, sometimes people
want to set up processes where no one person can do it all. This
generally seems to be called separation of duty. There are two ways
to think about this. One is that if a user ever has the possibility
of being in role A (fill out the purchase order) they cannot ever be
in role B (approve the purchase order). This is called static
separation of duty and is a constraint on the Role-Users
assignments. Such a constraint is a set of roles and a number n and
means that no user can have n of the roles in the set. For instance
{A, B} and 2 for the purchase order example.
So, maybe this is too restrictive and you just want to make sure that
the user can't be in the roles at the same time, but if they change
which roles are active that would be ok. So we need a concept of a
user session which is the roles that are active for a particular user
at a particular time.
-- Sessions: a session is the set of roles active for a user now.
So, its a subset of the Roles-User association which is all the roles
a user could possibly activate.
Now, a dynamic separation of duty constraint is just like the static
one but it applies to the Sessions rather than the Role-Users
association.
---------------------------------------------------------------------
Extensions:
1. The objects involved in permissions are apt to be really numerous,
but they typically come in bunches, namely from application modules
or applications. Furthermore, you may want to assign application
specific roles and then aggregate them into larger cross-application
roles. (for instance this is pretty much necessary for javaee and
jacc). So I propose organizing the objects into one or a set of
trees which we might call scopes, and associating roles with scopes:
a role could only include permissions using objects in the scope
(including descendants) and all the junior roles would also be in the
scope or descendants.
[ I originally called these applications in my triplesec branch, but
this doesn't seem very appropriate. Scope may not be the best
term. I don't know how it relates to "scopes" in microsoft AzMan ]
2. Theoretically one should not need denied permissions since you can
presumably just take the set theoretic difference of the subsets of
Objects X Actions to get a new permission representing granted -
denied. However the representation of permissions may make this
difficult or impractical so allowing roles to have granted
permissions, denied permissions, granted roles, and denied roles
seems to make it easier to fine tune the meaning of a larger role. I
haven't investigated the exact meaning of this in terms of the set-
theoretic model above. It's pretty easy to implement however.
----------------------------------------------------------------------
Comments
1. triplesec (trunk) has a Profile feature that Alex has recently
been telling me he doesn't like any more. I don't like the
implementation but I think its for the same purpose as the dynamic
separation of duty constraints and the session concept. Basically
profiles are, to me, statically configured sessions for different
jobs; enforcement of separation of duty constraints is left up to the
viligance of the administrator setting up the profiles.
2. These definitions are fairly set-theoretic which may not be to
everyones taste. Perhaps due to my previous training as a
mathematician I find this style a lot clearer than a lot of words.
In particular I recognize that the extensions are a lot less clear
than the main stuff. Maybe we could add more words and keep everyone
happy :-)
3. With the exception of separation of duty constraints this is all
implemented in my sandbox triplesec branch. By no means am I
suggesting anything particularly good about this, but it is possible
to implement and if you want to see a possible ldap schema that will
store this info you can look at it. Most likely lots of big
improvements can be made. This should definitely not be regarded as
anything other than a proof of concept and it has some major
practical problems such as not relating to existing external stores
of user information.
thanks
david jencks
