directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Date Mon, 08 Jan 2007 05:58:53 GMT
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.

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



View raw message