[Triplesec] [AuthZ] Introduction

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

Introduction
-----------------

This series describes the circumstances resulting in the need for a
centralized
authorization policy management system.  In doing so, it defines a subset of
the
problems that must be solved by Triplesec's Authorization Manager.  These
problems
and the various use cases described here resonate the goals of the Apache
Triplesec
Project with respect to authorization policy.

We're going to talk about applications, identities, permissions, roles,
groups, and the
assignment of roles to individual identities as well as to groups of
identities.  This will
lead us into discussions regarding what these entities are with clear
definitions we can
agree on and use as the nomenclature for this aspect of Triplesec.

Let us try to be as exacting as possible when speaking about these concepts
and
defining them eventually for use in a glossary section of our Triplesec
documentation.

Thanks,
Alex

Re: [Triplesec] [AuthZ] Introduction

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

Alex pointed out that it wasn't all that useful when in my previous  
comments I broke all the threads and glommed all of his descriptions  
together.  So I'm re-commenting on the individual definitions.

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

> Introduction
> -----------------
>
> This series describes the circumstances resulting in the need for a  
> centralized
> authorization policy management system.  In doing so, it defines a  
> subset of the
> problems that must be solved by Triplesec's Authorization Manager.   
> These problems
> and the various use cases described here resonate the goals of the  
> Apache Triplesec
> Project with respect to authorization policy.
>
> We're going to talk about applications, identities, permissions,  
> roles, groups, and the
> assignment of roles to individual identities as well as to groups  
> of identities.  This will
> lead us into discussions regarding what these entities are with  
> clear definitions we can
> agree on and use as the nomenclature for this aspect of Triplesec.
>

My main problems with this is that to me roles and groups are the  
same thing, and that applications aren't really a basic category.   
Alex and I have been discussing whether groups and roles are  
different aspects of the same thing for quite a while and there's  
more discussion elsewhere.  Applications I can discuss in this series  
of emails.

> Let us try to be as exacting as possible when speaking about these  
> concepts and
> defining them eventually for use in a glossary section of our  
> Triplesec documentation.

OK but by asking for me to be exacting.... I get to be pretty picky :-)

thanks
david jencks
>
> Thanks,
> Alex

Re: [Triplesec] [AuthZ] Comments on alex's proposed definitions

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

I've collected all of the definitions from Alex's posts into one  
place.  I'm going to compare these definitions with the ones in my  
alternate definition post and provide some comments.



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

> Introduction
> -----------------
>
> This series describes the circumstances resulting in the need for a  
> centralized
> authorization policy management system.  In doing so, it defines a  
> subset of the
> problems that must be solved by Triplesec's Authorization Manager.   
> These problems
> and the various use cases described here resonate the goals of the  
> Apache Triplesec
> Project with respect to authorization policy.
>
> We're going to talk about applications, identities, permissions,  
> roles, groups, and the
> assignment of roles to individual identities as well as to groups  
> of identities.  This will
> lead us into discussions regarding what these entities are with  
> clear definitions we can
> agree on and use as the nomenclature for this aspect of Triplesec.

My main problems with this is that to me roles and groups are the  
same thing, and that applications aren't really a basic category.   
More later.
>
> 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:
>
> 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, application, and principal.  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, i.e. a  
subset of the cross product of objects and operations.
>
> Role:
>    A set of permissions required by a principal to be authorized to  
> fulfill a logical function
>    within a system or application.

Mentioning principals here doesn't make the definition clearer for  
me.  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 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).

>
> Environments and Groups
> -------------------------------------
>
> When releases are ready for deployment, systems and applications  
> must be put into
> some operating environment.  Within any environment identities will  
> exist; some
> will be users, some services and some will be specific hosts. These  
> principals for
> the sake of manageability are often categorized together into  
> logical associations.
> By grouping identities together, administrators can handle them as  
> a single entity
> where the same set of tasks may apply to the group whatever those  
> management
> operations may be.
>
> Although groups are designed by administrators to simplify and  
> reduce their workload,
> it's no coincidence that these groups are highly dependent on an  
> organization's structure
> or the processes within an organization.  General groups may exist  
> for the entire
> organization.  More specific groups will exist for the departments  
> of an organization.
> When processes drive the creation of groups, membership is a based  
> on similar functions
> required of a group's members.  Sometimes processes are isolated to  
> a division, but more
> often than not, processes span across divisions leading to the  
> creation of cross
> divisional groups.

I think this says that there's a set of Users (or principals?) we  
need to keep track of and that if there are more than a few users we  
will want to treat lots of them the same way.  Since we are  
discussing authorization here I think this means that there are sets  
of users we want to grant the same permissions with a single simple  
operation.
>
> We extract more glossary definitions:
>
> Group:
>    A set of distinctly identifiable entities which are  
> categorically alike within an
>    organization, organizational unit or with respect to some  
> organizational process.

I'm not sure what this means beyond "a group is a set of  users".
>
> 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.

We've mentioned applications but not really described much about  
them.  Earlier I mentioned the set of objects involved in the  
permissions.  I think the idea of applications is that applications  
are a partition of the set of objects.  However this is IMO too  
restrictive.  For instance, Javaee ears have modules inside, and JACC  
deals with the sets of permissions on a per modules basis.  Many  
people divide large javaee applications into multiple ears with ejbs  
that call each other.  So I think we need a scope concept  where we  
divide the objects into a set of trees of scopes.  Roles would be  
associated with a single scope and would be constrained so all the  
permissions and roles assigned to them are within their scope: all  
objects in the permissions are in the scope, and all "child" roles  
are in the scope.  We could consider supporting directed acyclic  
graphs of scopes but I'm afraid this will be too confusing.  On the  
other hand I haven't tried to set up an example, so it might be just  
as easy to understand as roles.  To summarize this paragraph I'm  
suggesting we have hierarchical scopes rather than applications in  
our model.

>
> Authorization Managers
> ----------------------------------
>
> Medium to large scale application deployments within complex  
> environments occur
> often within the enterprise.  Several divisions, processes and  
> applications require
> the management of authorization policy for many groups and  
> identities.  Centralizing
> the access and administration of authorization policy improves  
> several aspects of
> management:
>
>   o centralized policy stores enable a standard mechanism for  
> representing
>      and accessing policy information rather than having each  
> application
>      devise it's own representation and backing store
>
>   o policy backup and restoration operations are simplified when  
> several
>      instances of the same application or different applications  
> use a centralized
>      policy store
>
>   o there is a reduced learning curve for administrators who use  
> the same tools
>      across applications to manage policy rather than having to  
> learn how to use
>      a specific tool for a each application
>
>   o policy audits are greatly simplified when a principal's policy  
> across all
>      applications resides in (what appears to be) a single  
> centralized location
>
>   o policy provisioning is also greatly simplified when policy  
> information is
>      centralized
>
>   o advanced capabilities in the policy store like snapshoting and  
> versioning
>      can be extended to all applications leveraging the centralized  
> store
>
>   o the authority to manage policy across divisions and  
> applications can be
>      parceled out to different administrators when the policy store  
> is centralized;
>      this is benefit is referred to as delegation of authority
>
>   o additional policy enhancing services benefit all applications  
> using a centralized
>      policy service
>
> Several products have emerged to centralize access to policy  
> information.  These
> products usually come bundled with programing APIs, tools, and  
> adapters to integrate
> with common existing systems which increases their uptake, and  
> usability for an
> immediate return to customers investing in the product.  Products  
> of this type, are
> often referred to as Authorization Managers and usually they are  
> included in a larger
> suite of services composing an identity solution.
>
> More glossary terms:
>
> Delegation of Authority:
>     The term given to the assignment of administrative operations  
> to specific authorities within
>     different jurisdictions to facilitate a division of management.

I don't disagree with this, but wonder if this is an authorization  
question for users of the authorization manager application itself?
>
> Authorization Manager:
>      A class of products found in identity management suites which  
> enables the centralized
>      management of authorization policy across applications.

I like this description of authorization managers.

Quite possibly I could be more clear about all this but its already  
been several days so I think it best if I post this now and see what  
happens.

many thanks
david jencks