directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [Triplesec] [AuthZ] Role Assignment
Date Wed, 31 Oct 2007 05:32:54 GMT
Hi David,

On 10/30/07, David Jencks <david_jencks@yahoo.com> 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.

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.

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.


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.

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

(2) policy maker (technical security officers)

     - create, delete, role assignments
     - 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

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.

SNIP ... too tired to continue for tonight.

Alex

Mime
View raw message