On Oct 30, 2007, at 10:32 PM, Alex Karasulu wrote:
Hi David,
On 10/30/07, David Jencks <[EMAIL PROTECTED]> 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 :-)
thanks
david jencks
Alex
