directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [Triplesec] [AuthZ] Role Assignment
Date Wed, 31 Oct 2007 08:51:50 GMT

On Oct 30, 2007, at 10:32 PM, Alex Karasulu wrote:

> Hi David,
> On 10/30/07, David Jencks <> wrote:
> On Oct 24, 2007, at 10:36 AM, Alex Karasulu wrote:
> > Role Assignment
> > -------------------------
> Snipped out what we agree on ...
> > Role assignment during and after deployment is required for
> > identities to fulfill their
> > designated functions within applications and systems.  Role
> > assignment can be done
> > on a per principal basis and should be allowed.  However doing so
> > for every assignment
> > would not be very tractible especially within the scale of an
> > enterprise.  Role assignment
> > to groups must be possible to make management feasible at medium to
> > large scales.
> > Role assignment is a task required of application and system
> > administrators.  Role
> > assignment begins as part of an application's deployment yet it
> > continues indefinately as
> > an operational overhead while identities are created, destroyed,
> > regrouped and allowed to
> > access the application at with various roles.
> >
> Here's where I start having problems.  As noted earlier, to me the
> only grouping we can be thinking about in the context of an
> authorization manager is to say that we want to grant a set of people
> the same permissions.
> Yes but how you do that and their implications to manageability hence
> a feasible authorization manager (a successful easy to use product) is
> the question.
> We already have the Role concept which is the
> set of permissions we're interested in, whether they are directly
> assigned to the role or via the role partial ordering or
> inheritance.
> That's fine let's do it with or without Role hierarchies.
> So the simplest thing to do is to, as we identify the
> people in this set, associate them with the role that represents the
> set of permissions we want them to have.
> No this is just simpler for naive implementations that don't  
> consider the perspective
> of our users.  This will create issues for us downstream.
> First the set of users may not be defined locally.  In fact, most  
> medium to large
> corporations which would bother to use an authorization manager in  
> the first place,
> already have external credential stores which already group their  
> users.
> I don't know exactly what the figures are but I would venture to  
> guess that over 90%
> of companies with enterprise scale mass and operations, Active  
> Directory, is the data
> base of record (DBOR) for network (LAN) users. Users that don't  
> fall under the domain of the
> network, those users external to the organization, needed for  
> Internet Applications, are
> often stored in other LDAP servers or within an RDBMS with a schema  
> containing some
> kind of users table and groups table.
> You may think this is unfortunate but it is the reality. The stone  
> cold realization is we cannot
> force these people to transition to using Triplesec as the DBOR in  
> these environments which
> already AD and/or other credential stores.
> So we need either a form of very specialized virtual directory or a  
> mechanism for referring to
> these external users and groups.  Copying group information into  
> Triplesec and transforming
> the groups into Roles is not the answer since it introduces the  
> synchronization and
> authoritative copy problems.
> How do I know that my changes to a Role (which was a group in the  
> external system) will
> stick and propagate?   When the group changes in the external  
> system, how can I be notified
> of that to update my copy?
> Are we going to invest time in building synchronization tools?   
> This is not where I want to go.
> If we were going to define all the groups in Triplesec in an ideal  
> world than I don't have as much
> of an issue going along with the idea of modeling them as roles.   
> This however is not the case,
> groups and users exist and they're defined by external systems as  
> well as within Triplesec.
> Forcing the use of roles to represent groups will create these  
> massive integration issues for
> us in the near future.

I want to be really clear that I am not suggesting that we need to  
copy, synchronize, deny the existence of, or hide any existing  
systems.  I'm only talking about a model so far. Code is relatively  
easy to write compared to acquiring data.  I figure that if we decide  
that groups as distinct from roles are not conceptually necessary,  
even though they are in most existing systems, we can then think  
about whether it's practical to write code that only uses roles, not  
groups.  I don't know if this is practical, but I think it's worth  
thinking about without throwing up our hands and saying its too  
hard.  For instance, it might be possible for our role objects to be  
backed by either tsec roles (in the part of ldap we control) or AD  
groups.  Obviously the role objects backed by AD groups are likely to  
be read-only from tsec.
> Plus it's just not natural. Groups exist.  Roles exist.  They are  
> not the same to the majority
> of administrators out there.  So why push it if it's going to  
> alienate people and create more
> problems and work for us.

Isn't this a UI question?  Administrators are not likely to be poking  
around in our code to see what we named our objects.   What if  
whenever you get to group users together or construct a "group  
hierarchy" we call the unnameable object a group and whenever you get  
to associate permissions to it or construct a "permission hierarchy"  
we call it a role?
> Another way to say this is that I think roles and groups are the same
> concept so we should only use one name for it.
> This is not going to fly for the reasons above.
> We certainly agree
> that we want to be able to associate users and roles.
> Yes but this is to be done by using something called a role- 
> assignment object.
> Presently Triplesec associates users with roles in something called  
> a Profile.  In
> this way it's a simple role assignment to individual users.
> This has a serious deficiency. It makes it so administrators now  
> need to define a
> profile for each user.  This is not feasible for anything other  
> than a small number of
> users.  To do this right (make it useful) you need to be able  
> associate groups of
> users with roles.
> My approach now after analyzing existing products is to use a role- 
> assignment
> not only to users but to groups.  Hence a role-assignment  
> associates either a user
> or a group with a set of roles.

If we have groups, we obviously need to associate groups with roles.   
If we agree to call the "groups" roles, the group-role association  
becomes part of the role hierarchy.
> Now if I
> understand what you are proposing it is to have a "group" which has a
> set of users associated with it (like a role) and has roles
> associated with it.
> No the group is just a group.  It sits out there.  The role- 
> assignment is what is our
> join table used to associate the group with the roles.

I'm not claiming that the association is stored in any particular  
place.  If you want to claim that the role-assignment is an object  
then we will have to make all the associations objects so we don't  
bias the discussion by implementation details about which end of an n- 
n relationship we store the pointers.
> Except for you calling it a group, that's a role
> that happens to get all its permissions from the partial ordering or
> inheritance rather than through direct assignment.
> Roles assigned to the group in a role-assignment can be utilizing  
> inheritance.  But
> you need this intermediate role-assignment object because the group  
> may need to
> be referred to if external to the system.  You just cannot compose  
> the group in a
> role object as you've defined it.  Doing so removes a required  
> layer of indirection.

I'm not claiming all the roles are in tsec controlled ldap.  I'm  
perfectly happy to have lots of the roles stored in AD where they are  
called groups.  That doesn't mean we have to call them groups, and it  
also does't mean when we are showing that data to our users we have  
to call them either roles or groups.
> I don't think we
> need two names for the same concept.
> Is it the same concept? I still don't see how you can say that.
> I recognize that there are existing systems that already have lots of
> users registered in them and the users organized into "groups".
> However, my understanding is that we are trying to come up with terms
> we agree will be most useful for discussing an authorization manager,
> so I don't think basing our terminology on someone else's
> implementation decisions no matter how popular they are is
> necessarily the best idea.
> It's not just some ONE else.  It's the majority of systems out  
> there.  I'm telling
> you that by pissing straight against the wind on this one your  
> going to have us wet
> and dirty :).
> Let's look again at the division of labor:
> (1) operator/administrator
>      - creates, deletes, modifies users
>      - creates, and deletes groups
>      - adds and removes users from groups

so AFAICT the model I'm talking about supports this just fine,  
provided the UI these people use labels the roles "groups".  When you  
hire joe, you have to  group him with the other people who do the  
same kind of work.  Whether we call the object a role or a group, its  
the same amount of work.
> (2) policy maker (technical security officers)
>      - create, delete, role assignments
I think these are the group-role associations?  To me these are some  
of the role-role hierarchy relationships.

>      - create, delete role exclusions (for static separation of duty)
> (3) application architects (engineers & developers)
>      - create, delete, modify permissions
>      - create, delete, modify role names
>      - add, remove permissions from roles
>      With role hierarchies:
>      - add, remove roles from roles

I agree with all these tasks.  I don't agree that they favor or  
disfavor having groups in the model.
> And another thing :-).  I think there's this idea floating around to
> the effect that sometimes a user may be authorized to do one kind of
> job and sometimes authorized to do another kind of job, although they
> are the same user.  My understanding of the Profile idea in triplesec
> trunk is that it was intended to support this.  There are probably
> other ways to describe this, but until someone has a problem with it
> lets describe this as the user being in one set of roles or another
> set of roles for the two kinds of jobs.  AFAICT the only reason to
> separate the sets of roles is if there is some kind of constraint
> preventing the user from being in all the roles at once.
> Yep this can be done using role exclusions.  These are constraints  
> that are
> managed by the policy making authority.  It prevents certain roles  
> from being
> assigned to the same user or group.  Furthermore it should also detect
> conditions where the membership of the same user in separate groups  
> would
> result in violations, hence this would constrain role assignments  
> to groups
> that would result in this case.
> When the groups and users are external to the system. Nothing  
> prevents the
> external system from violating this constraint.  However at runtime  
> since authentication
> is also handled or routed through Triplesec, violations of these  
> constraints can be
> caught and dealt with to disable user authentications.
> Some people
> (well the NIST guys anyway) call this kind of constraint "separation
> of duty".
> Sure I call it that too since this is where I learned about it.
> They suggest modeling them by saying, a user has
> associations with a set of roles, which are all the roles they could
> possibly be in.  In addition, there's a user Session, which is  the
> set of roles they happen to be in right now.
> This can be implemented by allowing for multiple named role- 
> assignments to users.
> This goes back to the profiles concept.  Triplesec allowed the same  
> user which could
> be defined externally, to have two separate "authorization  
> profiles".   Say I had a regular
> user profile called akarasulu, then I can have an administrator  
> profile called
> akarasulu_admin.  I like this since I don't want to be a super user  
> while doing regular
> things. I don't want to be concerned with having to watch out for  
> busting up the system.
> Only when needed I can put on my admin cap and do what I have to do  
> but with the
> same identity for auditing etc.
> Having multiple named role-assignments accomplishes this same goal.

Maybe.  If these are group-role assignments I think this is a much  
more complicated harder to understand way of implementing separation  
of duty constraints.  If we have groups I think having a session that  
contains the currently active groups and (directly assigned roles)  
will be much easier to implement and understand than trying to do SOD  
at the group-role assignment level. I could be wrong but I think this  
might well outweigh the difficulties in writing java-ldap mapping  
code from a role object to both ldap roles and groups.

Anyway I'm not sure we need to implement all of SOD right away.

Well I'm sure you completely agree with my arguments by now :-) but  
in case you don't :-D I wonder if we can move forward anyway?  If we  
allow both user-role and user-group assignments then I can have  
models without groups and you can have models with groups.  If we do  
this I would prefer that the associations be represented differently  
in the ldap schema as far as practical so user-role and group-role  
assignments can be distinguished.

> SNIP ... too tired to continue for tonight.

I am always amazed at how little sleep you need :-)

david jencks
> Alex

View raw message