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.
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:
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.
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.
This section describes several key principles underlying the design of a privilege management system.
2. Privilege building blocks
["building block" picture here]
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.
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.
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.
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.
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...
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.
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.
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.
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:
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.
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).
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.
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]
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. Automated lifecycle 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:
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.
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.
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. Provisioning strategy and services
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.
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:
5. Roles / Policy
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):
6. Organization culture and processes
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:
Topics to discuss with the committee include:
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.