There are 2 or 3 proposals that are getting mixed up here..... I'll
try to separate them.
1. hierarchical roles. This is a big part of the NIST RBAC model and
looks easy to implement in tsec to me. AFAICT a role would have
granted permissions, denied permissions, and a set of sub-roles.
We'd presumably need to implement something to prevent cycles in the
resulting graph. A role would imply a permission if some granted
permission in on of the set of role + transitive closure of sub-roles
implies the permission and no denied permission implied it.
If and only if we do (1), we can think about (2)
2. The role above is almost the same thing as the current profile:
as far as data the only difference is that profile has a user
attached. If we associate users and profiles in some other way we
can eliminate the concept of profile, simplifying the model
considerably. There's the other difference that roles are all loaded
at startup and profiles are loaded on demand. If loading everything
at once turns out to be a problem perhaps a LRU cache would work: in
any case this does not necessarily affect the data model. Note that
there's already a big problem with the current association between
users and profiles that people are proposing to fix with a "groups"
concept.
leading to
3. The current association between users and profiles is
problematical, independent of (1) or (2)
a. without something like groups, you get too many duplicated
profiles, which is unmaintainable. So, associating each profile with
exactly one user doesn't work. We need to do something else.
b. I think the NIST model incorporates the idea of switching roles in
an app perhaps without logging in again. I'm pretty sure I've seen
this idea elsewhere. This is not supported by the "log in as your
profile id" concept.
c. I'm not sure how the groups idea is supposed to work, but in my
mind's model I don't see it working. According to "log in as your
profileId" you log in basically with one of your group ids, and your
password. Now suppose the enterprise is IBM with ~300,000 people,
there's a good chance the password is not sufficient to identify
you. (I at least think that telling someone they can't use a
password because someone else already has it is an unacceptable
information leak) For auditing purposes the system needs to know who
you actually are..... so this won't work. So, you need to supply
your userId to identify yourself. Now we are requiring you to supply
your userId, password, and profileId. This doesn't fit most login
systems that well AFAIK.
Ignoring any possible implementation for the moment, I wonder if we
can agree on the data model characteristics for this. From (1) and
(2) we may end up calling a bunch of permissions that can be
associated with a user a role or a profile: I'll try to remember to
call it a profile even though I think calling it a role is
better :-) So:
A. I think we need a many-many association between users and
profiles. I think we all agree that a user needs to be able to have
several profiles, and if there are a lot of users we definitely want
to share a profile between several users. This means the user ID by
itself doesn't determine the profile and the profileID by itself
doesn't determine the user.
B1. To cater to systems that can only accept userID and password, we
could have a "default profileId" for each user. This gets you past
authentication to the point where the system can show you your
available profiles and you can pick one to change to.
B2. Alternatively if there was some way of having lots of aliases for
users that could be linked with unique profiles you could log in with
an alias and that would determine a profile.
B3. ??? Maybe we need more ideas or a better explanation of the
groups idea?
Moving over to implementation Alex points out that we can't rely on
any info being attached to users in the same place their
authentication info is stored. So, we have to store it with the
application data somehow. So, one easy thing we could do is have a
ou=Users area in the application where we store an entry for each
user, with an ordered list of profileIds. This is just an idea, not
necessarily a good one.
More comments inline.
On Jan 10, 2007, at 1:48 PM, Alex Karasulu wrote:
David Jencks wrote:
On Jan 8, 2007, at 12:58 AM, Alex Karasulu wrote:
David Jencks wrote:
On Jan 2, 2007, at 3:02 AM, Ersin Er wrote:
Hi (David),
I have two simple connected questions:
Is JACC basically a RBAC (Role Based Access Control) system?
If it's, do you think its model can be mapped onto the
following RBAC model:
http://csrc.nist.gov/rbac/rbacSTD-ACM.pdf ?
The NIST model for RBAC is quite sophisticated and can meet
most of
the RBAC model requirements. We cannot implement this fast and
it's
not our first priority but I am just dropping an email to keep
this in
mind. We would also like to support XACML and its RBAC module
in the
future so we'll have a stable core and a service layer that can
easily
be adopted by providers as JACC. Lots of TODO.. :-)
It took me a long time to actually read the paper.. still not
quite done. I think we should be careful to make sure triplesec
is consistent with the NIST model and implement as much as we
can to start with.
+1 Incidentally this is one of the biggest issues we're going to
run into. I read somewhere in the JACC spec that it does not
address the need for RBAC so there may be some impedance mismatch
here.
JACC basically makes the role >> permission mapping specified in
the j2ee/jee deployment descriptors somewhat more explicit, in
particular specifying the java classes for the permissions. It
leaves the identity >> role mapping up to the implementation.
I'd say it's consistent with RBAC but not the whole story.
Hope you're right - I really haven not been able to get a clear
picture of JACC up to this point.
A lot of the spec is not a model of clarity. It's really unclear
on who can change the role >> permission mappings when. On the
one hand it seems to state that they are determined by the spec
deployment descriptors, so presumably to change them you should
redeploy. On the other hand it provides a peculiar api for
changing them, but doesn't say who is supposed to use it other
than deployment.
I'm hoping triplesec will provide usable administration.
I'm thinking that perhaps we could implement the role hierarchy
features of the NIST model by combining the role and profile
object classes: i.e. each role could have subsidiary roles as
well as granted and denied permissions. This might simplify the
data model as well as making it more powerful. I haven't read
the admin features part of the model yet.... this seems likely
to be the hard part.
It does seem to me that with a role hierarchy it's only
necessary for a user to be in one role at a time, since you can
define the set of roles they are in to be yet another role.
I talked a bit with Alex about the user <> role association and
I still don't think we've found a good solution: I'm not very
happy with the current restriction of 1 user for a profile but
don't really have a better idea. I don't yet see groups as
providing a big improvement.
Another approach can be to create a special group profile.
Instead of the profile referring to one *user* the group profile
would refer to the DN of a *group* using say a group attribute.
This way users in a group that is referred to by a group profile
can gain access to the application with the effective permissions
defined for the group via the group profile.
WDYT?
I'm not happy with this yet, but maybe I just haven't thought it
through enough. It seems to me that hierarchical roles make
profiles redundant,
Hmmm I don't know if I would agree with that. A profile is a place
where we can aggregate and associate a user with roles and other
tweaked permissions for an application.
Hierarchical roles would just help as an administrative tool to do
RBAC better essentially with less verbosity.
They seem to be an important part of the NIST model.... and I think
supporting them simplifies and clarifies our data model. However
it's not essential.
Basically view a profile as a security profile. You have profiles
in apps that track your user specific settings. This profile is
just the same. It tracks your authZ settings or the application.
I thought user profiles were usually modifyable by the user. IIUC
this would normally not be the case for security profiles.
so I want to link users and roles, with the idea that a user can
choose one role at a time (like they can now choose one profile at
a time if they have several profiles). So to my mind there's a
many-many relationship between users and roles.
A user can be in any number of roles within an application. And a
role can be taken by any number of users in the same application.
I suspect this is getting hard to understand between hierarchical
roles and profiles. With hierarchical roles, what we are now calling
a profile is a role + userId. So saying that every user is in
exactly one role at a time is exactly the same as what we have now.
One of the problems I have here is wondering how the ui for
logging on is going to work. In say a web app you can usually
only supply the username and password to log on. How do you then
specify the role (or profileId)?
The username would be the profileId. Basically the profileId
usually is the same as the username 99.99% of the time.
As noted at the top, I don't think this works.
Behind the scenes the login module/triplesec will determine what
actual user that profileId corresponds to. Note the user is only
used for doing the authN.
Why is this separation a good thing you might ask?
Well sometimes the user info will not be contained in tsec although
it might be. Instead the users may be in the companies
ActiveDirectory or in another data source that Tsec will chase a
referral to.
This way we can store app specific profile information in tsec even
if the users and their credentials for authentication are
maintained in another store.
I didn't get that earlier.... I agree completely.
I think it would be nice after authenticating the user to
provide a list of their role/profile choices. It seems really
strange to me to provide the role/profileId as your user name....
You would not provide the role as your username. Just the
profileId but the user will never need to know this unless the user
needs different profiles on that same application.
Again, I was mixing up too many things at once. I'm using roleId to
mean what we now call profileId.
Sometimes you might have an alex user with both an alex and an alex-
admin profile. One may allow more privs than the other.
You asked then why don't you just create two users instead. Well
then you would have different passwords for each user. And what
would you do if that user was not in fact stored in Triplsec but
stored in ActiveDirectory and some delegation/proxying was
required? Also it's the same user so we want to correlate the
audit trails.
The two user alternative is not sound IMO.
I agree, multiple users is a non-starter.
So I guess one way to do this is to have a login page, which
results in you getting to a low-permissions role that then lets
you change roles, giving you a choice. Basically this gives each
user a default role, which is handy for the perhaps common
situation where in fact each user only has one role.
I don't think any of these measures are necessary.
I hope you're right but don't see any alternative yet.
I think alex tried to explain to me what the problem was with
giving each user a multi-valued attribute of their roles/profiles
but I'm not remembering it clearly enough to still believe it :-
( and it's seeming like a good idea to me...
Hmm let me see ... instead of having a profile for the user you
want to stuff role information as attributes into the user entry to
form associations that way?
To avoid mixing up 3 ideas lets call it profileIds for now :-)
This is a very bad idea IMO. Reason being that again we may be
proxying users from ActiveDirectory for example. This will be very
common. If so no Domain Admin will want to mess with the AD schema
to add triplesec or application specific schema elements to it.
Let me make a clear statement that the user credential store may
not be Triplesec while the application specific policy will be.
Most enterprises will not change their central credential store but
need to leverage it.
I get it now :-)
so I'm thinking of a required single valued attribute defaultRole
and an optional multivalued attribute roles in a new object class
that we can attach to users (or groups).
Again this is not a good idea. Easy to do and we can do it for
sure but it will make this solution very inflexible for real world
use cases.
So, I now agree we certainly can't attach this to the credential
store. I wonder about keeping this info in the application though.
This also makes more sense since profiles or roles generally won't go
across applications.... another reason attaching it to the user/
credential store is a terrible idea.
When you log in you get the defaultRole,
but then you can change to one of the others. Why wont this work?
This is a very convoluted IMHO. It could be made to work .. many
things can be made to work but this is not the question. Whether
it is going to lead to a viable enterprise solution is the question.
convoluted == bad, viable == good :-). I'm not convinced we have any
viable solutions yet though...
[NOTE: goal discussed below is wrt authZ aspects of tsec]
The goal of Triplesec is not to become a simple JACC implementation
in which case you can just use some flat file with some custom
syntax to represent policy as a simple static policy store.
It's supposed to be a central service to administer & control
policy for applications across the enterprise which works for real
world scenarios.
IMO jacc won't really mean anything useful until there is something
like triplesec hooked up that allows meaningful administration.
That's why I'm so excited about trying to hook it up to jacc.
This is why LDAP comes into the picture.
I think we need some more conversation around these concepts so we
can re-approach the JACC integration problem. I don't understand
JACC enough and perhaps Triplesec still alludes you a bit. We can
do it though please bear with us. We will find the solution.
yup.
thanks
david jencks
Alex
<akarasulu.vcf>
