Abstract

The approach discussed here is based on experiences and lessons learned from the implementation of the authority management system at Stanford University between 2000-2003.

Terminologies used in this document

Authority

Authorization

Privileges

Permissions

1.1 Concepts

This document describes an approach to enterprise-wide privilege management within an institution. It separates the management of privileges from the interpretation or application of them. It does this through a central, shared repository of privilege information where privileges can be managed independent of any specific system or technology that needs it. Such an approach offers several key benefits:

• Simplification of authority policy implementation, management and interpretation.
• Consistent application of authority rules via middleware services and synchronization of authority data across systems.
• Bringing together all privilege information about an individual so that it can be viewed together.
• Integration of authority data with enterprise reference data to provide extended services such as automatic revocation of privileges based on status and affiliation changes.
• Role-based authority, that is, management of privileges based on institutional criteria like relationship to a department rather than attached to individuals.

The system described in this recipe is not a comprehensive authorization solution. It assumes institutions will have their own methods for managing security information based on centralized privilege information.

1.2 Organizational benefit and impact

In this section we explore what problems this approach fixes or improves, how centralized privilege management can suit your organization, and how will the world look afterwards if you adopt the methods described in this paper.

Problems addressed:

• Having to move across multiple security systems, multiple interfaces, multiple organization boundaries to establish privileges
• No easy way to package a set of privileges that requires the coordination of multiple access privileges
• No easy way to track those privileges -- current, historical, over time
• Revoking privileges in multiple systems is as hard as establishing them and requires complex coordination across systems

Benefits:

• Does not describe a single authority model, but rather offers an environment in which many authority solutions can be implemented
• Supports hierarchically distributed control of authority and privilege definitions and use
• Supports hierarchically distributed delegation of assigned privileges as well as centrally managed model
• Well suited to academic institutions because of these characteristics

1.3 System principles and concepts

This section describes several key principles underlying the design of a privilege management system.

• Abstract privileges away from specific systems and technologies for the user. Record WHAT it is a person can do, not HOW they do it.
• Have the consuming system translate that into specific technical terms for interpretation by systems.
• Assumes strong identity management that can reliably identify a person in such a way they can be understood across multiple systems.
• Sharing and reuse of authority components within and across domains (e.g. financials) of authority.
• Open environment for any user to implement privilege management, from individuals to projects to offices to schools.

2.1 Defining privileges

["building block" picture here]

Subsystem

The Authority system starts out empty, a place in which a user can define their own authority needs. Any defined authority is part of an authority subsystem, a separately defined and managed section of the privileges space.

One small subsystem is defined by the authority system itself to manage the privileges of the users who administer the system itself. Otherwise privileges must be defined for use. Subsystems not only provide high-level organization to authority information for the user, they also establish ownership domains each with their own rights.

Function

This is the basic unit of an authority assignment from the end-user's perspective. It can represent a discrete task or a collection of tasks that must be enabled together for a person to perform that function. A good design will define a function at such a level that a single assignment will suffice to activate all the privileges required for a majority of common needs, but not put too much together that it can't support the required granularity of control. So it lies somewhere between a job, which has many responsibilities, and a system permission to perform an operation, such as updating a table in a database.

Task

Tasks are more specific units of work that go together in support of a function. For instance, it might assure that someone with update privileges in one system also has parallel reporting privileges in another. In security systems, privileges will likely map more closely to tasks than to functions, but an authority assignment to a task alone would likely result in insufficient rights to complete an activity.

Entitlement

The atomic units of authority control, representing specific operations under authority control. Entitlements are expressed at the lowest level of resolution that applications and services need to determine whether a user can perform an operation. They are how the business language of authority (functions/tasks) get translated into a technical language for interpretation by applications or mapping into the subsystem's local security terms.

Limits

Something to which authority is bound, such as a department or budget, or constraints that can be applied to users with access to an entitlement, e.g., a dollar amount limit.

Authority definitions and assignments consist of several additional key features that help manage privileges...

Scope

All authority has some definition of scope, rules that determine how broadly authority can be granted and how broadly granted authority applies. Scope can be simple or complex, but will express some form of hierarchical context in which to understand levels of authority. Such hierarchies provide a structure so that authority can be narrowed to the appropriate levels of the institution, or choices, such as limits, reduced to meaningful subsets. It also provides a meaningful framework to a distributed model of authority control, where one can pass on only privileges one has or a subset.

The most useful scope is Organizational Scope -- assigning privileges at a specific location in an organizational tree. The hierarchical nature of the Administrative and Academic structures provide a natural scaffolding that supports the distribution of authority to successively discreet portions of the University.

Prerequisites

A pre-condition that must be met for authority to become active, e.g., "training required". This facility allows authority assignments to be managed ahead of a user's eligibility to receive the attendant privileges. Prerequisites support the automatic activation of privileges when specific criteria are met.

Conditions

Something that must be true for the authority to remain valid, e.g., "until date x" or "as long as in department y". Conditional authority supports the automatic revocation of privileges when the conditions are met. The most important manifestation of this feature is to withdraw access rights when a person is no longer associated with an institution.

2.2 Assigning privileges

An authority assignment is the association of a function, scope and the individuals or roles receiving the privileges. This section discusses the dynamics of making assignments plus related features.

Any assignment contributes new privileges to the overall privilege set of an individual, whether the assignment is directly to a person or indirectly via a role or group. The Authority system preserves the distinction between such person-specific and non-person-specific privileges, allowing an interpreting system to enable privileges altogether or support interactions confined to people acting "in a role" if so desired.

This section also covers these features related to assignments and privileges:

Delegation

This is the ability to extend privileges to others -- you can think of it as authority about authority. As part of the support for distributed authority management, assignments can be made with or without passing on the ability to further delegate authority to others. Delegation works hand-in-hand with scope to provide a chain of delegated authority along hierarchical lines of an organization.

Designated drivers

These features support temporary or specialized cases of having or granting authority:

• Granting proxy -- the ability for a person to designate another to act for them in all authority management activities. This is useful in two ways. It allows privileged people who actually possess some authority to designate someone who can act in their stead online. This is of practical benefit yet preserves the proper chain of authority in the system. The other case this is important is to permit the administrators of the authority system to seed initial authorizations.

• Acting proxy -- the ability for a person to temporarily extend the authority one has to another. The Authority system preserves the distinction between such direct and proxied privileges, allowing an interpreting system to enable privileges all together or treat them separately (e.g., for audit purposes).

The Authority system preserves the distinction between such direct and proxied privileges, allowing an interpreting system to enable privileges all together or treat them separately (e.g., for audit purposes).

Notification

An important aspect of privilege management is the notification to players about new or changing authority. This is particularly crucial the more one allows the distributed application of authority, or proxied or third-party actions. Feedback to both the grantors and recipients of authority is an important element of assuring the ongoing integrity of appropriate privileges and to reduce risk of intentional or accidental abuse. This section describes the circumstances in which email or other communications are provided.

2.5 User interface for assignments

This section describes the features of a Web application that supports user assignment and viewing of authority. It is a place to view all authority for an individual or for a department and to access history information about authority. It supports the granting of new authority through a guided wizard-style interaction.

The web application can support additional lookup requirements, such as examining a chain of authority to see who has privileges at different levels of the organization. The canonical Stanford example of this is the "who can sign" question, or the ability to determine who has sufficient authority, and the most specific authority, to approve certain transactions.

[screen shot of Stanford's UI as a use case]

2.6 Metadata management

This section describes the application to manage the authority metadata. This application will allow subsystem owners to create and modify the metadata used in the web application as described in section 2.5.

3.1 Automatic assignment controls

This section discusses mechanisms to support automated controls, specifically integration with Registry information -- the monitoring of status/affiliation/group events from person and workgroup. Integration with Registry information provides the following features:

• Auto activation -- the enabling of privileges for an assignment when a prerequisite is met.

• Auto revocation -- the withdrawal of privileges for an assignment when a condition becomes false.

• Auto notification -- standard notification associated with assignments that are automatically managed, as well as specialized notification for special conditions, such as assignments not activated in a specific timeframe.

The Stanford Authority System was able to introduce several important features with relative ease because it already had in place some critical information processes. Information about a person's affiliation and status (e.g., faculty, staff, student) is maintained in near real-time from source systems in a Person Registry, so supporting a condition like "this authority is good only as long as you are at Stanford" only required hooking into those signals. Similarly, the tracking of prerequisites utilizes the data from the Workgroup Registry.

3.2 Impact of organizational and policy/definition changes

This section describes how centralized authorization information that is based on external data must be aware of changes in that data and have policy about the responses to such change. For example, when a department reorganizes, under what circumstances do privileges move automatically? When institutional policy changes, e.g., new maximum spending limits, what is the impact of authority assignments that have values above or below such limits?

For some privileges, such as reporting authority, existing privilege assignments may remain intact to accommodate access to historical reporting data. While other privileges may be automatically revoked.

These types of bulk changes require the issuing of new privilege documents for target systems. To minimize the administration effort when these changes arise, the privilege management system needs facilities to unload/reload assignments on changed privilege definitions.

3.3 Processes to lifecycle management

This section concerns programs necessary to automate the update of privileges based on changing conditions.

Stanford has two general classes of software that it deploys across all of its Registry-based data stores: a regis, named for its intimate ties to "registry" maintenance. This is an always running daemon process that is responsible for all real-time interactions with a registry. It's outward face listens for signals of interest about changes to data it cares about, while the inward face is responsible for taking incoming data and integrating it with the registry in question. It always works through appropriate object layers to assure consistent application of business rules and policy to incoming data. The "authority_regis" is therefore that process that listens for data changes that can affect conditions of privileges. Tasks is the name given to all calendar-based processes. In this case it refers to the nightly processes that support date-based activation or termination of authority. It might also support a more scheduled approach to interpreting and responding to external changes like revised organizational hierarchies.

4.1 Provisioning privileges

This section describes the provisioning strategy in use at Stanford for integrating authority data with the major ERP systems: Student Administration, Human Resources, and Financials. A privileges XML document is made available through an HTTPS-based document service. Signals are posted through Stanford's proprietary event messaging system about changes in authority, and the consuming system fetches the privilege information and updates a person's privileges in its local security table accordingly.

[details about the Privilege document go here, including XML schema]

[Also enumerated components -- real-time events (messaging), doc service, event listener/handler]

The local systems are responsible for ensuring that the privilege information and the data in the local security tables are synchronized. As part of this integration strategy it has been recognized that there is a need for ongoing audits to guarantee that privilege information is being accurately reflected in the systems that provide access based on that information.

4.2 Provisioning alternatives

This section goes beyond the event-driven integration supported by the Stanford Authority system and discusses some of the desired outputs of a more generalized AuthZ-aware solution. Among these are:

• Data mapping to person directory entries using eduPerson isMemberOf and entitlement attributes (for LDAP based authorization)
• Web services
• Data to Shibboleth AA, e.g., SAML assertions
• Publish privileges XML to a message-oriented middleware
• Integration with Grouper
• Integration with XACML Policy Decision Point

4.3 Integration with middleware services

• Brief overview of basic registries deployed at Stanford, specifically Person, Organization and Workgroups...
• Technical details on Stanford's directories -- OpenLDAP, eduPerson, and suPerson attributes...Person
• Web services/document service -- This is a more technical look at Stanford's own document service -- Apache/Tomcat, how docs are defined and delivered, versioning, DTD management, etc?
• Asynchronous messaging using Stanford's event service

5.1 Roles

Here we discuss the added layers of roles and groups and how they differ. Membership in a role-population will be managed as groups, but the semantics of the Roles themselves lie outside group management per se. Some of the possible differences (there's grouper, workgroup, privileges boundaries yet to explore):

• Because of the added semantics and the close association of Roles with privilege assignments (roles are sometimes defined as "those who have been assigned this privilege"), use the Privilege Management UI to create and manage roles, using a group-membership API to manage a membership group underneath.
• The privilege management does not define the rules for role membership, rather it tracks the assignments to
• Conceptual support for rules-based policy support is a better fit for roles than for groups.

5.2 Groups

This section discusses processes that will help make a smoother implementation and acceptance of a centralized privilege management system. One of the first steps is to form a committee of system architects and representatives from business units such as:

• ERP system owners, e.g., Student Administration, HR, and Financials
• Internal audit
• Risk management
• Information security

Topics to discuss with the committee include:

• Benefits of a centralized privilege management system
• The value to the organization for consistent application of authority policies across systems
• Identify who is the privilege management system owner and the roles that participants will play. Business units "own" the metadata and central IT will support the system? A technical client support model to help other systems and projects use those authority solution?
• Establish review processes for adding new metadata to prevent creating duplicate privileges and how privileges should be organized in the UI to minimize data entry error
• Establish a change process for policy changes, e.g. how will privileges be reused/shared across systems
• Establish communication channels for notification of changes and impact of changes to target systems

This section will also include guidelines for defining consistent style and vocabulary for defining privileges, and for working with system owners to establish appropriate levels of control.