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, 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?
thanks
david jencks
Alex
<akarasulu.vcf>
