Page History

Introduction Image Added

  Identity and Access Management are the two major areas of what is often referred to as core middleware by the Internet2  community.  Access Management is the set of policy-based and technology based  practices for controlling the access to resources.  Access management is in the early stages of its maturity. Its evolution will likely follow the path followed by the more mature area of identity management. "Single sign-on" (SSO) began to take shape in the 1980s with MIT's Project Athena and Carnegie Mellon's Andrew Project. Before then it was standard practice for each application to manage its own set of username and password. In the 1990s Sun Microsystems introduced the Network Information Service which was that vendor's attempt to provide a single sign-on across a common managed set of UNIX systems. Eventually the number of services and applications grew and SSO became  a requirement in most enterprises. Today Kerberos, Active Directory, CAS and others fill this technology space to provide "single sign-on" in one enterprise. Shibboleth is now enabling SSO to cross enterprise boundaries and enable virtual organizations. 

...

7. A centralized XACML-like service which essentially grants or denies access

On Roles and Privileges

The definition of role is a common debate in access management.  There are good definitions for role, but many identity management and access management technologies have used the term for their own purposes, thus adding to the confusion. In the Apache Shiro project, a role is a collection of privileges.  However, there are two differentiators between that definition and the definition used in this document.  A collection of privileges is not necessarily a role.  Privileges can have inheritance, so a privilege that implies other privileges might not be a role.  Roles generally describe the subjects' affiliation, job function, or responsibility.  Roles can inherit privileges from other roles.

...

• Start out using a single user attribute "affiliation", in a campus enterprise directory and let applications make authorization decisions.  See the eduPerson definitions at  http://middleware.internet2.edu/eduperson/
• Enrich centralized access management using groups determined from "systems of record" such as course memberships, chargers those that can charge against financial accounts, department membership
• Empower departments and application owners to create and maintain groups for their own purposes and unburden central IT of this responsibility
• Support other deeper integrations with access management, support access decisions via web services, provide access to predefined roles and privileges  and privileges . Examine opportunities for provisioning privileges and group assignments into applications that cannot reach out to supporting infrastructure
•  

Further we recommend:

• Examine your environment for high-value access management use cases that cannot be solved simply by using groups or roles and relatively static attributes

Definitions 

General Definitions

• Look for opportunities to capture policy decisions around access management into access management infrastructure rather than individual applications

Definitions 

General Definitions

The Action is the verb of the privilege assignment which allows a resource to be assigned to a subject in various ways without creating more resources .  For example SubjectA can view (action) the Math department data (resource).

...

A Rule  is computation done on attributes by either a resource or a Policy decision point  to grant or deny access to a resource.

A Subject  is a person, a software component ( service) acting on behalf of a person or a set of subjects and/or services.

Inheritance Definitions

Many of the parts of the privilege model can have inheritance from other objects.  The privilege management system might require the inheritance to be a hierarchy, or maybe it is required to be acyclic, or maybe it could be a directed graph. 

...

Access Control Decisions (groups, roles, privileges, and external authorization)

...

There are several decisions for access control for applications including: 

- groups vs roles
- roles vs privileges vs hybrid
- hard-coded privileges vs externalized authorization
- for externalized authorization: centralized or not
- caching

...

When applications protect resources by checking if the authenticated user is in a group, they are essentially using a group as if it were a role.  For example, if the application code checks if the authenticated user is in the institution's "student" group, in order for them to see the main screen of the application, then there is an implicit hard-coded privilege resource of "main-screen", and action "view", assigned to the role "studentUser", which is assigned to the group "student".  Though it is referred to as security by group, it is actually a role. 

Roles vs Privileges vs Hybrid

Generally an application will have a handful or up to a couple of dozen roles.   These application roles are used as a security template that multiple subjects can be assigned to for common access.  These roles are generally mapped to job function or affiliation.  For example there could be roles for student, staff, instructor, admin, billing administrator , anonymous User, etc.  Note that set of roles varies across applications as needed.  Within applications roles tend to be named and managed within that application.  Yet these application specific roles are often derived from larger definitions that have an enterprise scope. "Student" defined via the eduPerson attribute with its global meaning is likely to lead to the assignment of application specific derived roles which may or may not contain the word student. 

If not all subjects in a role have the exact same access, then they need personalized privileges assigned to them.  The authorization system might assign privileges directly to the subject, or in the context of an application, or in the context of a role.  Either way, the subject will have privileges that are different from other subjects assigned to the same role.  An example is to specify which data-sets the subject has access to when searching for data or running reports. 

If the authorization system supports applications with subjects that select one role at a time to use the application, then individual privileges should be able to be assigned in context of one role.  The subject will not need to have elevated privileges at all times, and thus will be less likely to accidentally perform tasks that only the elevated role can perform.

...

- Claims based Approach (What someone says about you)

- Group/Role based Approach (What you belong to)  

...

The process of transporting attributes, privileges, groups, roles, and subjects etc. to a resource that does not participate in the central identity and access management solution. For applications that rely on hard-coded privileges as described above, provisioning these privileges can be an acceptable compromise to make the application more dynamic.

Getting Your Attributes

At a conceptual level there are many places where attributes can be obtained

• From a directory

...

• that provide attributes from

...

• well understood schemas via LDAP
• Derived from a SCIM or a SAML attribute assertion

From a SAML assertion to a programming environment

Environmental variables

...

• From a XACML Policy Information point or as a result of a call to a XACML authorization API

Different programming and application environments may hide these details from a resource programmer much like the CGI variables are presented to a web programmer even though they are passed via HTTP. Most application environments  have the ability to utilize LDAP apis or make web service calls via SOAP or REST Point

Are there different attribute types?

Maybe.   Some attributes are part of a subject's identity and we refer to as intrinsic attributes. These attributes can be used to identify a subject and differentiate subjects from one another. These attributes are normally mastered at  a system of record, usually an HR system or a student system.   Authorization attributes Applied  attributes are generally based on "claims" as mentioned about and are attributes asserted about a subject. These attributes are  generally derived from some sort of workflow where a sequence of people assert within where  people make claims  within a auditable proces    that a subject can have access to a resourceprocess  . The distinction can be subtle. As for  example eduPersonAffiliation can be either  . The attributes  isMemberOf and eduPersonEntitlement fall more clearly into authorization attribute class. Some attributes of course fall into neither class or at least shouldn't e.g. eduPersonMobile.is intrinsic and is determined by a system of record and is a byproduct of an identity proofing process. The attributes  isMemberOf and eduPersonEntitlement are more clearly  applied  attributes . 

A XACML Perspective on Access Management

...

The Grouper Perspective on Access Management

...