[TRILPLESEC] JACC & RBAC

[Ersin Er <er...@gmail.com>]

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

Cheers,

-- 
Ersin

Re: [TRIPLESEC] JACC & RBAC

[David Jencks <da...@yahoo.com>]

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

Re: [TRIPLESEC] JACC & RBAC

[Alex Karasulu <ak...@apache.org>]

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

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

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

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

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

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

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

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.

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

Re: [TRIPLESEC] JACC & RBAC

[David Jencks <da...@yahoo.com>]

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.   
We'd presumably need to implement something to prevent cycles in the  
resulting graph.  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.

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.  If we associate users and profiles in some other way we  
can eliminate the concept of profile, simplifying the model  
considerably.  There's the other difference that roles are all loaded  
at startup and profiles are loaded on demand.  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. 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.
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.
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.  According to "log in as your  
profileId" you log in basically with one of your group ids, and your  
password.  Now suppose the enterprise is IBM with ~300,000 people,  
there's a good chance the password is not sufficient to identify  
you.  (I at least think that telling someone they can't use  a  
password because someone else already has it is an unacceptable  
information leak)  For auditing purposes the system needs to know who  
you actually are..... so this won't work.  So, you need to supply  
your userId to identify yourself.  Now we are requiring you to supply  
your userId, password, and profileId.  This doesn't fit most login  
systems that well AFAIK.


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:

A. I think we need a many-many association between users and  
profiles.  I think we all agree that a user needs to be able to have  
several profiles, and if there are a lot of users we definitely want  
to share a profile between several users.  This means the user ID by  
itself doesn't determine the profile and the profileID by itself  
doesn't determine the user.

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.

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.

B3. ??? Maybe we need more ideas or a better explanation of the  
groups idea?

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.

More comments inline.

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

>
>> 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.  So saying that every user is in  
exactly one role at a time is exactly the same as what we have now.

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

>
>> 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 :-)

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

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

yup.

thanks
david jencks

>
> Alex
>
>
>
> <akarasulu.vcf>

Re: [TRIPLESEC] JACC & RBAC

[Alex Karasulu <ak...@apache.org>]

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

Re: [TRIPLESEC] JACC & RBAC

[David Jencks <da...@yahoo.com>]

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>

Re: [TRIPLESEC] JACC & RBAC

[Alex Karasulu <ak...@apache.org>]

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

Re: [TRIPLESEC] JACC & RBAC

[David Jencks <da...@yahoo.com>]

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.

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.

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.


thanks
david jencks



>
> Cheers,
>
> -- 
> Ersin