directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [Triplesec] [AuthZ] Applications and Roles
Date Tue, 30 Oct 2007 21:54:58 GMT

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

> Applications and Roles
> ---------------------------------
> Application designers devise security permissions and roles  
> specific to applications.  These
> roles represent a set of rights authorizing principals to perform  
> operations or access resources
> that must be allowed to fulfill a specific coherent function within  
> applications.  These rights to
> access resources are the permissions.  The set of these  
> permissions, needed for a logical
> function to be conducted in the application, is a role.
> To be concise we extract the following glossary definitions:
I think we should start with

Users:  People (or maybe systems) that need to use the system.  Often  
the term Principal is used but I find it extremely confusing because  
the principals I know about in java are only aspects of someones  
identity in the system.  A Principal might have started out as  
something that completely represents a single user but I think it is  
used in so many other ways now that we should avoid it to describe a  
single user.  Since I find "principal" so confusing I'm going to use  
"user" instead in what follows: we can always change it back.

  It's a minor point  and I really don't want to get anyone  
distracted but I tend to think of "systems" that need to use the  
system as "frozen identities" of the people who set them up.  In  
other words someone had to start the system and they had better have  
had the authorization to set it up to do whatever it is supposed to.   
So it seems to me as if they froze part of their identity into the  
system's authorizations.  I'd be interested to know if this seems  
like a reasonable point of view to others.

> Permission:
>    A right required by a system or application to authorize  
> principals to perform a
>    specific operation or access a resource in some manner.
This is kind of unclear to me and mentions the so-far undefined terms  
system and application.  Looking at permissions I know about they  
seem to specify one or more object of some kind and one or more  
operations of some kind.  For instance a file read permission  
describes a file (object) and operation (read).  A web permission may  
describe a set of urls and a bunch of http methods.  To me it is  
clearer to leave out who might want or use a permission or the  
context (application?) in which it is meaningful from its definition  
and say that we have a set of objects and a set of operations and a  
permission is a bunch of operations on a bunch of objects.

So for this to make sense we need a couple more categories:

Objects: "things" that can be operated on, such as program bits or  

Operations: stuff you can do to objects.

Now, objects usually show up in bunches such as applications.   
However applications sometimes have modules inside and sometimes  
themselves come in bunches.  For instance javaee ears have web and  
ejb modules inside, and people sometimes deploy large javaee projects  
as more than one ear, that use each other.  With many applications  
deployed, there can easily be hundreds or thousands of objects.  To  
make administering permissions on these objects manageable I think we  
may want to introduce a hierarchical scope concept.

Scopes: a tree of scope objects, where we assign each object to one  
scope.  For instance, a module, application, set of applications,  
division, enterprise...

> Role:
>    A set of permissions required by a principal to be authorized to  
> fulfill a logical function
>    within a system or application.

I think there are two ways of looking at roles and permissions.  One,  
used here, says that a role is a set of permissions.  The other says  
that a role is an entity with permissions associated to it.  They are  
really really close but I prefer the second for these reasons:

1. One of the characteristics of the roles I know about is that they  
have names.  Furthermore I think people like to think about assigning  
permissions to roles (or maybe roles to permissions).  Saying that a  
role is a set of permissions tends to suppress the roles' name and  
makes it impossible to distinguish a bunch of new roles that don't  
have any permissions assigned to them yet -- they are all the empty  
set of permissions, so identical.

2. I think its easier to think about role hierarchy with roles as  
entities.  Its certainly possible to do with sets -- role A contains  
or implies role B if B is a subset of A -- but it is hard to think  
about what this means if you assign or unassign a permission to B.   
Do you unassign it from A as well or does A no longer imply B?  With  
role entities you can assign permissions to B and make B a "junior"  
role to A and then A gets B's permissions without explicit assignment  
of permissions to A.

3. I don't see how to deal with denied permissions with the role-as- 
set-of permissions approach.  With the role-as-entity approach you  
just have more associations with permissions (and roles, for denied  
subsidiary roles).

On the other side, we need to associate roles and users.  (If we need  
groups in our model, we need to be able to associate roles and groups  
too).  Furthermore, we may want to restrict some roles to deal with  
permissions in some applications, so if we decide to use the scope  
idea we want to attach a role to a scope, and say it can only deal  
with permissions on objects in that scope.  So I propose:

Role: a named entity where
   1. permissions are associated to a role
   2. users are associated to a role
   3. there's a (multiple) inheritance relationship between roles.   
 From the point of view of permissions, if role A contains role B, A  
gets all of B's permissions from the "contains" relationship without  
direct assignment to A.  Note that from the point of view of users, B  
gets all of A's users, so B contains A.  (the fewer permissions you  
are talking about [B], the more people have them; the more  
permissions [A] the fewer people).
   4. If we need groups, groups are associated to a role.
   5. If we have scopes, roles are attached to a scope and all the  
permissions associated to the role (directly or through inheritance)  
have objects in the scope.

david jencks

> Thanks,
> Alex

View raw message