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.
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?
Alex
begin:vcard
fn:Alex Karasulu
n:Karasulu;Alex
org:Apache Software Foundation;Apache Directory
adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA
email;internet:[EMAIL PROTECTED]
title:Member, V.P.
tel;work:(904) 791-2766
tel;fax:(904) 808-4789
tel;home:(904) 808-4789
tel;cell:(904) 315-4901
note;quoted-printable:AIM: alexokarasulu=0D=0A=
MSN: [EMAIL PROTECTED]
Yahoo!: alexkarasulu=0D=0A=
IRC: aok=0D=0A=
PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A=
x-mozilla-html:FALSE
url:http://people.apache.org/~akarasulu
version:2.1
end:vcard
