On Jan 10, 2007, at 7:59 PM, Alex Karasulu wrote:
David Jencks wrote:
There are 2 or 3 proposals that are getting mixed up here.....
I'll try to separate them.
1. hierarchical roles. This is a big part of the NIST RBAC model
and looks easy to implement in tsec to me. AFAICT a role would
have granted permissions, denied permissions, and a set of sub-roles.
Ok this is different as we already discussed than what tsec does
today but that's fine.
We'd
presumably need to implement something to prevent cycles in the
resulting graph.
Yeah exactly.
A role would imply a permission if some granted
permission in on of the set of role + transitive closure of sub-
roles implies the permission and no denied permission implied it.
Sounds like a good way to devise the composite implies for the role.
If and only if we do (1), we can think about (2)
2. The role above is almost the same thing as the current
profile: as far as data the only difference is that profile has a
user attached.
That's a big thing to undo.
If
we associate users and profiles in some other way we can eliminate
the concept of profile, simplifying the model considerably.
This is a problem. Whether or not you call it a profile does not
matter. Call it anything you like.
To avoid having to muck with a user's entry you need some other
entry to store the roles associated with that user. It's like a
record in a link table in the RDBMS world. We just so happen to
call that the authz profile.
If you muck with the user entry you make Tsec pretty useless in
enterprise scenarios where many will want to use a pre-established
user credential store like Active Directory.
There's the
other difference that roles are all loaded at startup and profiles
are loaded on demand.
Right since the number of profiles in the system ~= # of users and
this can be in the millions.
If loading everything at once turns out to be a
problem perhaps a LRU cache would work: in any case this does not
necessarily affect the data model.
Roles and permissions are preloaded because the number of
permissions and roles for applications are usually tiny in
comparison to the unbounded number of user profiles you can have.
Furthermore on startup without having any users logged into an
application an application can inquire about what roles and or
permissions are used.
Note that there's already a big
problem with the current association between users and profiles
that people are proposing to fix with a "groups" concept.
leading to
3. The current association between users and profiles is
problematical, independent of (1) or (2)
a. without something like groups, you get too many duplicated
profiles, which is unmaintainable. So, associating each profile
with exactly one user doesn't work. We need to do something else.
Yes this is why the group profile concept came about. You can
still fine tune this with having individual user based profiles.
b. I think the NIST model incorporates the idea of switching roles
in an app perhaps without logging in again. I'm pretty sure I've
seen this idea elsewhere. This is not supported by the "log in as
your profile id" concept.
Not necessarily. I think you're mixing some ideas here.
You're bringing in your conceived notion of a user's role here.
Strictly wrt to triplesec what you're talking about corresponds to
a triplesec profile. Apps can be designed to allow you to switch
your profile (which is what you're thinking about instead of role).
yup, I'm using the NIST terminology here.... they only talk about
roles, not profiles. And at least with hierarchical roles I got the
strong impression that you'd be in one role at a time.
c. I'm not sure how the groups idea is supposed to work, but in my
mind's model I don't see it working.
Ok take a breather :). Step back and check this out. Users log
into applications using some login id. It could be anything ...
it's up to triplesec and it's login module to interpret that based
on what is defined within the application.
Triplesec will use the following algorithm to figure out what that
id corresponds to:
(1) check to see if the login id is a profile id of a profile
defined specifically for a user
(2a) if so the user is dereferenced and authentication occurs
(2b) if no profile exists, the id is presumed to be a user id in
which case we continue to #3 below
(3) check to see if a user exists with the login id, if so continue
to #4 if not reject access by the user to the application
(4) check to see if that user is a member of a group profile
defined for the application
(5a) if the user is a member of a group profile authenticate the
user and enable the user with the permissions associated with the
group profile
(5b) if the user is not a member of any group profile deny access
to the application by that user
This is pretty straight forward to implement. As far as the
application is concerned no one cares what the login id is actually
for or represents.
As far as the tsec admin is concerned he manages profiles for
individuals and for groups. Sometimes individual profiles are
preferred for special people and sometimes not. The admin is happy
because he has the power to group users and the power to work
specifically with individuals.
I dont see how this works if...
- a user is in more than one group
- a group has more than one profile
In either or both of these cases it looks to me as if you have the
same problem of lots of profiles for one user, and all you have is
the user name. Without a default profile I think you're stuck.
I wonder if the start of this group idea was that most user tracking
systems already classify the users into groups, and you want to use
that preexisting information in triplesec? The thing is, this idea
of groups is really just a simple form of RBAC where group is a kind
of role, so having user >> group >> profile >> roles is really kind
of circuitous. I'm proposing we just have user > > role (one role at
a time) with a suitably modified definition of role. All these ideas
have a need to map users to profile/role and I see big problems in
all of them except simply having an explicit mapping, which has the
problem of ignoring whatever knowledge is captured in existing user >
group mappings.
Now we are requiring you to supply your userId, password, and
profileId. This doesn't fit most login systems that well AFAIK.
I agree with you completely but that's not what we're trying to do.
I talked a little bit with a Zos expert who tells me that the zos
security system built into the operating system does exactly this,
and has a default profile in case you don't want to specify the
profile you want explicitly.
Ignoring any possible implementation for the moment, I wonder if
we can agree on the data model characteristics for this. From (1)
and (2) we may end up calling a bunch of permissions that can be
associated with a user a role or a profile: I'll try to remember
to call it a profile even though I think calling it a role is
better :-) So:
Hehe yeah we need to agree on our jargon. We need a darn glossary
you're right.
Again to do this you have to understand the real world constraints
on us. We cannot put what is today in the profile into a user
entry. So we need something to associate roles with users. Just
pick an name for what this entity is to be called and we can call
it that.
A. I think we need a many-many association between users and
profiles.
Yep that's the group profile. It's a new construct that refers to
a group instead of a user.
see above :-)
This means the user ID by itself doesn't determine the profile and
the profileID by itself doesn't determine the user.
True but there will be a way to determine this from the other side
by being provided a login id. The evaluation of what that
corresponds to will be handled by tsec using the heuristic I wrote
up above.
see above
B1. To cater to systems that can only accept userID and password,
we could have a "default profileId" for each user. This gets you
past authentication to the point where the system can show you
your available profiles and you can pick one to change to.
Yeah this is too weird and we don't need to do it.
but is used by zos.... so it may not be that far-fetched an idea.
B2. Alternatively if there was some way of having lots of aliases
for users that could be linked with unique profiles you could log
in with an alias and that would determine a profile.
Again I don't think this is at all necessary.
B3. ??? Maybe we need more ideas or a better explanation of the
groups idea?
Yeah I hope the above explanation (heuristic) helps with that. If
not we can discuss this a bit more.
Moving over to implementation Alex points out that we can't rely
on any info being attached to users in the same place their
authentication info is stored. So, we have to store it with the
application data somehow. So, one easy thing we could do is have
a ou=Users area in the application where we store an entry for
each user, with an ordered list of profileIds. This is just an
idea, not necessarily a good one.
Hmmm this may be another way. Basically your ou=users container
under applications is almost the same as ou=profiles. Why?
Because what's in there is not the user themselves but references
to profiles associated with them. However this is not good because
you still don't know which profile to associate with a user logging
in.
On Jan 10, 2007, at 1:48 PM, Alex Karasulu wrote:
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.
They seem to be an important part of the NIST model.... and I
think supporting them simplifies and clarifies our data model.
However it's not essential.
I would agree with you on this one. Many people ask for it so
supporting it is not a bad idea.
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.
I thought user profiles were usually modifyable by the user. IIUC
this would normally not be the case for security profiles.
Whether or not a profile is modifyable by the user is irrelevent.
Writability is orthogonal and unrelated to whether something is or
is not a profile.
Users will not be able to modify their profiles or even read them.
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.
I suspect this is getting hard to understand between hierarchical
roles and profiles. With hierarchical roles, what we are now
calling a profile is a role + userId.
Not really. A user profile also has tweaking attributes to grant
or deny permissions that may or may not be inherited from roles
assigned to the profile.
We seem to have different ideas of what a role would be in the world
of hierarchical roles. I think a role has a set of granted
permissions, a set of denied permissions, and a set of sub-roles. I
can't tell for sure but this comment makes it sound like you think a
role would have either sets of granted and denied permissions, or a
set of sub-roles, but not both. I think that's too limiting, I think
we only need one kind of role.
So saying that every user is in exactly one
role at a time is exactly the same as what we have now.
No I disagree with this statement. You're basing this on the
presumption that a profile ~= role which is not correct.
My definition of a role above makes our current profile exactly a
role + userId. Its not a presumption, its comparing definitions.
Again this makes me think that you have a different definition of
hierarchical role in mind, but I don't know what it is.
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.
As noted at the top, I don't think this works.
Again I think you're basing this conclusion on a misunderstanding.
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 didn't get that earlier.... I agree completely.
Cool. Then it becomes a question of how we satisfy these
constraints while doing RBAC (satisfy nist) with LDAP and working
well with JACC.
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.
Again, I was mixing up too many things at once. I'm using roleId
to mean what we now call profileId.
Yeah this is not going to work. I think we just need to talk more
about this.
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.
I agree, multiple users is a non-starter.
Great.
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 hope you're right but don't see any alternative yet.
We're getting there I think... Hopefully my response in this email
will clarify some things.
I think it clarifies that we need to talk some more :-)
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?
To avoid mixing up 3 ideas lets call it profileIds for now :-)
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.
I get it now :-)
Great.
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.
So, I now agree we certainly can't attach this to the credential
store. I wonder about keeping this info in the application
though. This also makes more sense since profiles or roles
generally won't go across applications.... another reason
attaching it to the user/credential store is a terrible idea.
Glad you recognize this.
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.
convoluted == bad, viable == good :-). I'm not convinced we have
any viable solutions yet though...
:)
[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.
IMO jacc won't really mean anything useful until there is
something like triplesec hooked up that allows meaningful
administration. That's why I'm so excited about trying to hook it
up to jacc.
Yeah me too ... glad you're so enthusiastic about this. Finally
someone besides me is too :).
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.
Regards,
Alex
<akarasulu.vcf>
So hopefully we can free up some time to chat and see if we can clear
up our mutual misunderstandings
many thanks
david jencks
