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