directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Date Mon, 08 Jan 2007 06:28:30 GMT

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.

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, 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.

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

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

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).  When you log in you get the  
defaultRole, but then you can change to one of the others.  Why wont  
this work?

david jencks

> Alex
> <akarasulu.vcf>

View raw message