Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

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", (e.g. 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, 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. 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
  • Look for opportunities to capture policy decisions around access management into access management infrastructure rather than individual applications

...

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

Overview

Applications have various access control needs to control which subjects have access to what.  This is generally for applications which require authentication, though the authorization could also apply to anonymous subjects (who would get privileges from an anonymous role). 

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 an 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 Useruser, etc.  Note that the set of roles varies across applications as needed.  Within applications, roles tend to be named and managed within that applicationinternally.  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 However this is done, 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 the 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.

...

If there is no access control framework or central system, then hard-coding the privileges in the application might be the easiest way to code an applicationassign access. This would require the application to maintain its own privilege-to-subject map.  This is actually the current "state of the art" in most applications. Some  Some are able to read ldap directories for attributes  attributes or group memberships. You often   You often see the terms "coarse-grained" authorization and "fine-grained" authorization used to describle this kind of situation.

...

When using externalized privileges, there are caching considerations.  Caching can improve the performance of the application and reduce the dependencies of middleware components.  If there are not real-time updates from the authorization system, then the privileges can become stale.  When there are a lot of privilege resources and assignments which need to be checked, it is a good idea to cache the application's privileges for the entire user population, or for one user when they authenticate.  If there are reports or queries which need to join available data with the allowed record types, the authorization information might need to be cached directly in the application's database.  If there are limits on the authorizations, then it is more complicated than just a list of allowed action/resource pairs.

Naming

...

Considerations

The grouper project has collected some best practices in naming groups and privileges.  These practices can be found at Group and folder design ideas

...

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

...

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

  • From a directory that provide provides attributes from well understood schemas via LDAP
  • Derived from a SCIM or a SAML attribute assertion
  • From a an XACML Policy Information point Point or as a result of a call to a XACML authorization API

...

Provisioning Peoplesoft at Madison

The NCState NC State Peoplesoft use case.

Penn Groups

...