[Triplesec] [AuthZ] Role Assignment

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

Role Assignment
-------------------------

Once an application is deployed, identities must be granted permissions to
be
authorized to perform operations and access resources.  Assigning
permissions
one at a time to users is unmanageable and prone to error.  Role based
access
control arose primarily from this requirement to associate permissions
within
roles and assign roles to identities rather than permissions directly.  This
way,
identities that have roles assigned to them, are granted the permissions
associated
with their assigned roles.

There are several benefits to RBAC which I won't go into in this section but
consider
the impact of a change in the application which alters a role by adding a
new permission.
Most administrators, I am sure, would prefer to add a new permission to a
role and
have that trickle down to users, rather than modifying each user in the
system to have
this new permission.

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.

Alex

Re: [Triplesec] [AuthZ] Role Assignment

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

Hi David,

Again I am condensing out the agreed to points ...

On 10/31/07, David Jencks < david_jencks@yahoo.com> wrote:
>
>
> On Oct 30, 2007, at 10:32 PM, Alex Karasulu wrote:
>
> Hi David,
>
> On 10/30/07, David Jencks < david_jencks@yahoo.com> wrote:
>
>
...

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

We can do that but do we want to?  Will it be beneficial?

This is an optimization problem so we can give up clarity in the model's
ability to represent real entities to make implementing that model in code
easier.  This is what
you are proposing.

We can create any model we want to.

However my whole point is, I don't want to give up clarity no matter how
easy the code gets.
That's not an option for me.

My turn to flame :-),

<flame>

I don't know if this is practical,
>

OK so respectfully then, I ask that you stop wasting time pushing this
point. You admit
here that you don't know if it is practical.

And please stop presuming I don't know what I am talking about. I do know
that it is
not practical.  I'm not lying here guy.

 but I think it's worth thinking about without throwing up our hands and
> saying its too hard.
>

(1) I've been thinking about this for weeks giving you the time you
requested to discuss
     your points and consider your views.

(2) I think you mentioned yourself that it is harder to code with my
approach which differentiates
     groups from roles.  Note its also easier to code a model where
permissions can only be directly
     added to users but I'm not going to do that since the result would not
be optimal nor RBAC.

I stepped back and put down my inherent leverage as a senior member here and
as one who
has done this several times.  I have a long history along these lines where
I've learned from
several mistakes.

I humbly engaged you for a long time.  I dropped any advantage that a
meritocracy gives me.
I could have at any point after having in earnest tried to understand you,
say OK sorry but I'm
going to have to do it this other way due to time constraints.  I even tried
hard to get third parties to
say something in case I'm totally out of my gourd.  I hope you see that I'm
willing to be
corrected.  At this point I'd rather be shown I am wrong, then continue
pissing away time.
Unfortunately there is nothing that shows my being incorrect in your points.

So let me be clear. I don't have to "throw my hands up" and say anything at
this point.
</flame>

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

Hmmm read-only ... maybe there's a way around that :).

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

Not if we consider more than just administrators.  People like me are going
to have
to deal with translating natural concepts into the convoluted optimization
you've found
to make the code easier to manage for you.

Administrators are not likely to be poking around in our code to see what we
> named our objects.
>

Well I will and others will.

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

This is fine if it is across the board.  It's a problem when this is only in
a GUI.  These things
will be reflected in public APIs.

So the exposure has greater surface area and is more than just the GUI.


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

I understand that from the standpoint of simple mechanics, this will work.
However from the
standpoint of model clarity and consistency with our users, administrators
and the majority
of developers using our API's (not to mention us) it will not fit.  It will
create more chaos
than it's worth.  Let's grok the code and make sure we have no problem.

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

This is not making sense to me here.

The creation of a role-assignment object is the least bias you can have
since it removes the
directionality by putting the associations in objects other than groups or
roles.  It decouples
us from being at a particular "end of an n-n relationship."

Did I miss something?

...

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

What about our API's?  Are our API users going to need API's that refer to
roles or groups?  Where
does this end?

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

Regardless of the amount of work point which you seem to flip-flop on it is
confusing.

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

Yes these are group-role or user-role associations.

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

...

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

Perhaps but it works for user-role assignments since this defaults to what
we call a profile.

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

Maybe but we should think about it so we don't prevent it's proper
implementation down
the line when we're ready to introduce it.

Well I'm sure you completely agree with my arguments by now :-)
>

:-)  Sorry I don't but I sure wish I did - it would cost much less.

but in case you don't :-D I wonder if we can move forward anyway?
>

Yes I think it's time now to move forward and do it the way I and others
seem to agree with.
Are you on board?

Alex

Re: [Triplesec] [AuthZ] Role Assignment

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

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

> Hi David,
>
> On 10/30/07, David Jencks <da...@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.

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
>

Re: [Triplesec] [AuthZ] Role Assignment

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

Hi David,

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

Re: [Triplesec] [AuthZ] Role Assignment

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

On Oct 24, 2007, at 10:36 AM, Alex Karasulu wrote:

> Role Assignment
> -------------------------
>
> Once an application is deployed, identities must be granted  
> permissions to be
> authorized to perform operations and access resources.  Assigning  
> permissions
> one at a time to users is unmanageable and prone to error.  Role  
> based access
> control arose primarily from this requirement to associate  
> permissions within
> roles and assign roles to identities rather than permissions  
> directly.  This way,
> identities that have roles assigned to them, are granted the  
> permissions associated
> with their assigned roles.
>
I completely agree.

> There are several benefits to RBAC which I won't go into in this  
> section but consider
> the impact of a change in the application which alters a role by  
> adding a new permission.
> Most administrators, I am sure, would prefer to add a new  
> permission to a role and
> have that trickle down to users, rather than modifying each user in  
> the system to have
> this new permission.
>
I agree.

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

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.  We certainly agree  
that we want to be able to associate users and 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.  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.  I don't think we  
need two names for the same concept.

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.

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.  Some people  
(well the NIST guys anyway) call this kind of constraint "separation  
of duty".  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.  Now you can have static  
separation of duty constraints which say a user can't be associated  
with all of some set of roles (in the more static, user-role  
association) or dynamic separation of duty constraints which say that  
a session can't have all of some set of roles in it at once.

Now its kind of a small point, but when I think of users being in  
groups, it seems to me that they are always in those groups, so when  
I start wondering where to put some kind of SOD constraint in it gets  
pretty hard to see where to put it.... are user-group assignments  
temporary?  Are group-role assignments temporary? Are role-permission  
assignments temporary?  None of these quite seem to feel right to  
me.  When I think of the role-permission association being fixed then  
putting the roles the user is currently in into a session feels like  
a very simple and natural solution to me.

Finally, I'm worried that we are in danger of lumping two kinds of  
relationships under one name.  We seem to agree that users and roles  
need to be associated, and I put this into my suggested role  
definition a couple emails back in this series.  If we have groups,  
then we also need group-role assignments.  Even if its possible to  
model two kinds of relationships with the same structure using a  
particular technology such as ldap object classes, if they have  
significant differences in meaning I think we should recognize that  
and avoid using the same name for them.  So to me it makes much more  
sense, assuming we do have groups, to have user-role assignments and  
group-role assignments, and to carefully distinguish which one (or  
both) we are talking about.

thanks
david jencks

> Alex