directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Date Wed, 10 Jan 2007 21:58:08 GMT
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"  

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:
>>>>> ?
>>>>> 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.


david jencks

> Alex
> <akarasulu.vcf>

View raw message