MIT's Roles Database: Parts of an Authorization

I. Authorizations and their parts

I.a. Authorization = Person + Function + Qualifier

The main object used in MIT's Roles Database is the Authorization, which consists of three parts:

Person	Function	Qualifier
The person who is authorized to do something (identified by the person's Kerberos principal)	The action the person is permitted to do (also could be a role the person has or a collection of actions or responsibilities)	The unit or area within which the person can perform the Function. This could be an HR org unit, financial object, or some other unit

Note that these 3-part structures bear some similarity to the 3-part structures in RDF or the Symantic Web:

Subject + Verb + Object

I.b. Explicitly-created authorizations

Authorizations can be explicitly created. Each of these authorizations is explicitly created by an individual to apply to another individual.

• We control who has the authority to create or maintain explicitly-granted authorizations, i.e., who decides who has access to departmental or central resources. This authority is distributed to administrators in each department, who have control over access to their department's resources. These administrators can grant appropriate authorizations to anyone within the broader MIT community, not limited to employees of the department that owns the resources).
• To create an (explicit) authorization, you pick a Person, a Function, and Qualifier from pre-existing lists, i.e.,
  • Pick a person from the list of all employees, students, and "affiliates" at MIT.
  • Pick a function from a pre-existing list of functions. You will be limited as to which functions you can pick, depending on your authorization-granting permissions
  • Once you've picked a function, pick a qualifier from a pre-existing list. The Qualifier must be of the appropriate type to match the Function. You may be limited as to which Qualifiers you can pick.

I.c. Implied authorizations

We are currently developing an extension to the Roles Database to accommodate "implied" authorizations, i.e., authorizations derived from rules and attributes about people. These authorizations will have the same Person + Function + Qualifier format, but they will be derived automatically from other sources.

Explicit and implied authorizations are partitioned in the Roles Database so that they can be maintained separately. Batch runs that generate implied authorizations will not wipe out explicitly-authorizations, and automatically-generated implied authorizations cannot be removed manually or overridden. A person's list of permissions is the union of explicit and implied authorizations.

I.d. Functions

A function, as previously described, is the component of an Authorization that describes the action (or role or group of actions) that the person is allowed to do. Note that

• Each function belongs to a "Category", or application area
• Each function must be interpreted by downstream applications (those that use the Roles Database for access control) to represent some action or set of functionality within the application. Thus, the creation of functions must be coordinated with the application developer.
• Some functions can apply to more than one application, e.g., financial reporting authorizations apply both to the financial system and the data warehouse.
• Functions can have parent/child relationships; an authorization for a parent function implies authorizations for all child functions as well.

I.e. Qualifiers

One of the most important characteristics of MIT's Roles Database is that each Authorization clearly separates the Function (action, role, or group of actions) from the area or group of objects for which the person is allowed to perform that Function.

Qualifiers are organized into hierarchies (or more strictly, into webs, since qualifiers can, on rare occations, have more than one parent). There are several types of Qualifiers. Examples of types of Qualifiers are (i) HR Org units, (ii) financial profit centers and account numbers that exist in a single hierarchy, and (iii) research-related laboratory spaces and rooms. Qualifiers of most types are extracted from data in other systems by nightly data feeds. Other Qualifier types can be maintained manually by specifically-authorized individuals via a web-based user interface.

If the Qualifier within an Authorization is a node within a hierarchy rather than a leaf, then the Authorization applies to all child, grandchild, etc. Qualifiers as well.

II. Qualifiers and Authorizations examples

II.a. Example Qualifier hierarchy: Library materials

To help us understand how People, Functions, and Qualifiers go together to make up Authorizations, let us examine a sample hierarchy of Qualifiers, representing online library materials that are available to authorized individuals.

Each node and leaf in the diagram represents a Qualifier, each with a code (e.g., LIB_ALL, or LIB_GROUP1) and a name ("All library materials", or "Library materials group 1").

II.b. Explicit authorizations related to Library materials

Suppose that there are two different Functions for actions related to Library materials:

Function name	Description
ACCESS LIBRARY MATERIALS	Allows a person to view specified online library materials
ADMIN ACCESS TO LIB MATERIALS	Allows a person to set or change access permissions to Library materials

Further, suppose that the following Authorizations for access to Library materials have been explicitly created:

Person	Function	Qualifier
JOEUSER	ACCESS LIBRARY MATERIALS	LIB_GROUP1
FREDUSER	ACCESS LIBRARY MATERIALS	LIB_GROUP1
RMURDOCK	ACCESS LIBRARY MATERIALS	LIB_BOSGLOBE
RMURDOCK	ACCESS LIBRARY MATERIALS	LIB_MJMO
EINSTEIN	ACCESS LIBRARY MATERIALS	LIB_LNS
NBOHR	ACCESS LIBRARY MATERIALS	LIB_LNS
LTHUROW	ADMIN ACCESS TO LIB MATERIALS	LIB_SLOAN_A
BSMITH	ADMIN ACCESS TO LIB MATERIALS	LIB_LNS

II.c. Hierarchy of Library materials, showing explicit authorizations

We can display the same set of authorizations shown in the previous table within the hierarchy of Library materials.

In the diagram below, notice that

• Under a given qualifier (such as LIB_GROUP1), there may be a function name shown in green and a list of one or more usernames of people with authorizations for the given Function and Qualifier.
• The hierarchical diaplay of qualifiers makes it easy to see the implications of a given Authorization. For example, note that JOEUSER can ACCESS LIBRARY MATERIALS for node LIB_GROUP1 and all of its descendents, i.e., LIB_NO_RESTRICT, LIB_NYT, LIB_BOSGLOBE, LIB_BIO_CATALOG, LIB_RESTRICT_A, LIB_BRIT, and LIB_OED.

II.d. Virtual groups

We think that most Authorizations (permissions) are better described as triplets (Person, Function, Qualifier) rather than 2-part group memberships (Person, Group). The Function+Qualifier components better describe what people actually have access to than a group name, and there are several technical advantages to using 3-dimensional authorizations.

However, we could think of each (Function, Qualifier) pair as a virtual group, and there can be members of this virtual group. For example, the pair ("ACCESS LIBRARY MATERIALS", LIB_GROUP1) can be thought of as a virtual group. There are two members of the virtual group: JOEUSER and FREDUSER.

Membership in the virtual group ("ACCESS LIBRARY MATERIALS", LIB_GROUP1) also implies membership in the following virtual groups:

• ("ACCESS LIBRARY MATERIALS",   LIB_NO_RESTRICT)
• ("ACCESS LIBRARY MATERIALS",   LIB_NYT)
• ("ACCESS LIBRARY MATERIALS",   LIB_BOSGLOBE)
• ("ACCESS LIBRARY MATERIALS",   LIB_BIO_CATALOG)
• ("ACCESS LIBRARY MATERIALS",   LIB_RESTRICT_A)
• ("ACCESS LIBRARY MATERIALS",   LIB_BRIT)
• ("ACCESS LIBRARY MATERIALS",   LIB_OED)

Within the Roles Database, there are no actual objects corresponding to pairs of Functions and Qualifiers. But, one could think of these pairs as representing virtual groups, and they could be used to export lists of (person, group-name) pairs to systems that expect to see permission information in this format.

III. Implied authorizations and rules

So far, we have only given examples of explicitly-granted Authorizations. But access to Library materials would be an area where implied authorizations, derived from other information, could be generated for thousands of people.

III.a. Format of data about people used as conditions for rules

If we're going to use rules to generate implied data about people, we need some source data to tell us something about the people. We also need to organize the source data in a way that makes it practical to apply rules to it.

We will organize the source data about people as triplets of information as well, not Authoriizations, but triplets of information we call "Relations". Each Relation consists of three parts, for example:

Examples of "Relations" - data about people

Person or agent	Relation-function	Object
aka Subject	aka Verb	aka Object
REPA	STAFF - ADMINISTRATIVE	IS&T
FRED	STUDENT - GRAD	CHEM
JIMB	FACULTY - RETIRED	EECS
LTHUROW	FACULTY - MIT	SLOAN
AJJONES	HAS COMPLETED CLASS	8.232 Relative Quantum Field Theory I

III.b. Grouping Relation-functions

Now, we can arrange Relation-functions into groups, which will later allow us to create rules based on either a single Relation-function or a named group of them.

Groups of relation-functions related to people's student or staff status

Function Group Name	Description	Qual type	Linked Function name
CURRENT MIT PERSON SET L1	Current MIT people statuses for access to most Library materials	DEPT	FACULTY - MIT
			FACULTY - VISITING
			NON-MIT CROSS-REGISTERED
			STAFF - ACADEMIC
			STAFF - ADMINISTRATIVE
			STAFF - POSTDOC
			STAFF - SUPPORT
			STAFF - VISITING RESEARCHER
			STUDENT - GRAD (CONF)
			STUDENT - GRADUATE
			STUDENT - UNDERGRAD (CONF)
			STUDENT - UNDERGRADUATE
RETIRED FACULTY/STAFF	Retired faculty and staff members	DEPT	FACULTY - RETIRED
			STAFF - RETIRED

III.c. The format for one type of rule

Finally, we can formulate rules that takes takes the input "Relations" about people and generates implied authorizations. We're working on 4 types of rules. Only one type is applicable to access to Library materials. This type of rule can be represented as a row in a database table with 4 columns:

Columns in a definition of a Rule of type 2b

Condition function or function-group	Condition object		Implied auth function	Implied auth qualifier
If a person has a "Relation" with this function...	...and this object, or a child/grandchild/etc. of this object		...then the person gets an implied authorization for this Function...	...and this Qualifier

III.d. Examples of rules

Rule ID	Rule name	Where a person has a role/relation for function shown below and the qualifier is either the object shown below or a descendant of the object...			...give the person an implied authorization for the function and object shown below.
		Cond Function	Cond obj type	Cond obj code	Result function	Result obj type	Result obj code
19	People (set L1) can access lib materials (Group 1)	CURRENT MIT PERSON SET L1	Depart- ment	D_ALL	ACCESS LIBRARY MATERIALS	Library material	LIB_GROUP1
20	Retired faculty/staff can access limited lib materials	RETIRED FACULTY/STAFF	Depart- ment	D_ALL	ACCESS LIBRARY MATERIALS	Library material	LIB_NO_RESTRICT
21	Sloan School people can access special set of lib materials	CURRENT MIT PERSON SET L1	Depart- ment	D_SLOAN	ACCESS LIBRARY MATERIALS	Library material	LIB_SLOAN_A

III.e. Results of the rules

Person has this "Relation"...			...and after applying the rules, the person gets this implied authorization.
Person	Relation-function	Relation Object	Person	Resulting Authorization Function	Resulting Authorization Qualifier
REPA	STAFF - ADMINISTRATIVE	IS&T	REPA	ACCESS LIBRARY MATERIALS	LIB_GROUP1
FRED	STAFF - ADMINISTRATIVE	IS&T	FRED	ACCESS LIBRARY MATERIALS	LIB_GROUP1
JIMB	STAFF - ADMINISTRATIVE	IS&T	JIMB	ACCESS LIBRARY MATERIALS	LIB_NO_RESTRICT
LTHUROW	STAFF - ADMINISTRATIVE	IS&T	LTHUROW	ACCESS LIBRARY MATERIALS	LIB_NO_RESTRICT
LTHUROW	STAFF - ADMINISTRATIVE	IS&T	LTHUROW	ACCESS LIBRARY MATERIALS	LIB_SLOAN_A