MIT’s Roles Database:Our Model for Authorizations

Jim Repa (repa@mit.edu)

Common Solutions Group

January 11, 2002

See also: http://web.mit.edu/rolesdb/www/educause/educause.html

System in production at MIT

• Put into production in early 1998• Our system is used by SAP (financial), NIMBUS

(Budget System), Grad. Admissions, Labor Distribution System, Data Warehouse, with other systems planned

• Maintenance of financial auths. is distributed to departments, with a framework in place to expand to other areas

2

3

Components of our system

• Oracle Database with PL/SQL stored procedures• PowerBuilder front-end for distributed

maintenance of authorizations• Web front-end for more wide-spread viewing of

authorizations and related info. (http://rolesweb.mit.edu - some pages are public)

• Perl scripts for data feeds of supporting info• Java API under development

4

Benefits of our model

• Describe authorizations in business terminology, not arcane terminology of each application

• Distribute maintenance of auths. to departments

• Multiple systems use same rules

• Use of hierarchies reduces maintenance

5

Auth. complexity continuum

• Imagine representing an authorization as a Person + a simple or complex attribute

elementalattribute

arbitrarilycomplexstructure

(Function, Qualifier)

Our Authorization is a Triplet

• Authorization = Person + Function + Qualifier– (for OKI, a “person” will be generalized to an “agent”)

• Lets someone do something somewhere:– Who? = Person– What? = Function– Where? = Qualifier

• Qualifier is picked from a hierarchy and may be a node or a leaf

• (Also, optional expiration date, and a flag that says whether you can grant this and subordinate auths.)

6

7

Why a Triplet?• Often a person is authorized to perform a

Function only within an org. area (school, dept., lab, etc.) or within a financial area

PERSON FUNCTION QUALIFIER

Joe Review Salaries Dept. of Biology

Sally Create Requisitions Acct. 12345

Fred Approve Reqs. Accts. in Biology

Ann Grade Students Course 6.001

8

Why bother to separate Function and Qualifiier?

• Example:– Joe is in list Read_course_1234– Sally is in list Give_grades_5678

• Problems:– Need to store logic or mapping info externally– You might have 250K different lists (e.g. 50K account

nos. X 5 business functions)– If you distribute maintenance of lists (or attributes) to

non-technical people, how are you going to explain this?

9

Yes, but...

• Can’t you make Joe a member of a class and then set attributes to indicate what he can do (read materials, update materials, set grades, etc.)? Can’t you use two or more list memberships instead of a triplet?

• Example:– Joe is member of class 1234

– Joe is also a member of class 4321

– Joe has the “read materials” attribute

10

No, you still need triplets

• What happens if Joe is a student in two courses, but teaches a third course? The attribute (“can read course materials”, “can set grades”, etc.) must be individually tied to each course of which Joe is a “member”

• Thus, we’re back to 3-part authorization objects

11

Can we derive auths. from job title?

• Sometimes, but not in general case

• There are cross-departmental projects

• There students and outside contractors who have authorizations but no job title

• A job title does not mean the same thing in every department, or even for 2 people with same title in the same department

Why not more complex entities? – Why not more than one Qualifier?

• Keep it simple and we can distribute maintenance• Our experience is: You don’t need more than one.

– Define a few simple roles and secondary “qualifiers” may drop out

– You may need a few extra Functions, (e.g., Create Requisitions < $1K, Create Requisitions < $5K, Create Requisitions > $5K)

• Describing auth. needs in the P + F + Q model helps you to separate the business roles from the arcane technobabble of your software

12

13

Is there always a Qualifier?

• Some Functions are associated with the special QualifierType “NULL”.

• Authorizations for these Functions are not restricted by a Qualifier

14

Creating an Authorization

• To create an Authorization, pick a Person, a Function, and a Qualifier from existing tables

• Each Function has an associated QualiferType (e.g., “Spend Funds” might require an acct. no. or group of acct. nos.)

• Your authority to create authorizations will be restricted to certain Functions and Qualifiers

15

Qualifiers are organized into hierarchies

• Qualifiers of a given QualifierType start at a root node, and include 2 or more levels

• The Qualifier component of an Authorization can be the root, a node, or a leaf within the tree

• If the Auth. specifies the root or a node, then the Auth. applies to all descendent objects under the node

16

Advantages of hierarchies

• Allows fewer explicit Authorizations to be maintained

• Changes to hierarchy don’t require Authorization maintenance

• Avoids single decision on “grain” of authorization

• Alternate hierarchies over the same objects• Negation or exceptions not allowed

17

Maintained vs. expanded auths.

• Example 1: Spending by account no.– No. of maintained auths: ~10,600

– No. of expanded auths: ~630,000

• Example 2: Reporting by account no.– No. of maintained auths: ~8,300

– No. of expanded auths: ~886,000

• (Note: There are ~5,400 unique people with financial auths, and ~46,000 account numbers)

18

Authentication vs. authorization

• Authentication: Identify a person– Kerberos tickets

– X.509 certificates (find person’s Kerberos username in the certificate, and use only that field)

• Authorization: What is a person allowed to do?– Store Person + Function + Qualifier in Roles DB

– Each application interprets and enforces

19

What about cross-domain authentication?

• (We don’t have this in place yet, and we might debate this further, but here’s what we’re leaning toward)

• Does person need a distinct username at MIT for auditing purposes or extensive detailed authorizations? – If so, then give him/her an MIT Kerberos username– If not, then “authenticate” as a generic outside user, e.g.,

“StanfordStudent”

• Authorizations could be based on real username or one of several generic outside usernames

Current implementation at MIT: Data flow

Data Warehouse

Roles DB

Power Builder Appl.

Warehouse views

Admissions System

SAP Financial

1

2

3

1. Supporting information is fed nightly from data warehouse to Roles DB2. Front-end application is used to create “authorizations” in Roles DB3. Authorization information is converted and sent to various applications

20

21

Division of labor: Central service vs. the various applications

• Central service– Stores and retrieves information

– Handles traversal of hierarchy

• Each application– In design stage: defines business functions and

qualifiers (context for each function)

– Sets individual auths. (or distributes work to depts.)

– Interprets auth. rules

– Enforces auth. rules

22

Looking up Auth. information – “Can user X do function Y with qual. Z?”

• Some applications pull extract of Authorizations from Roles DB and save in local cache

• Others do real-time lookups via Oracle stored procedures or (soon-to-be-released) Java API

• In one case (SAP), we convert and push Auth. information to the external app.

Audit trail and historical data

• We have an audit trail that shows every change made to every Authorization

• It would be possible to reconstruct a person’s auths. on any day in the past – but we haven’t coded this yet.

23

24

Some statistics

• No. of authorizations (non-expanded): 57131

• No. of people who have at least one authorization: 6965

• No. of people who have created at least one authorization: 220

What’s new or under development?

• Java API (OKI)

• Planned major new release: Roles Version 2

25

26

Java API under development

• Will support– Lookups of Authorizations

– Real-time maintenance of Functions and Qualifiers

• Implementation planned for this year (exact schedule TBD)– See http://blue-goose.mit.edu/roles_api_docs.html

(later, you can get info from the OKI site)

– Warning: These API documents are volatile

27

Roles Version 2

• More sophisticated hierarchies– Multiple views – the same “Qualifiers” can be grouped

differently depending on the context– A Qualifier can be have more than one QualifierType

• Functions can be grouped into hierarchies as well• Better control over who can view what auths.• A facility to support querying/checking of

authorizations that are implied by data in other systems, i.e.,where Roles DB is not the system of record (back-end database link to other systems)

28

Future auth. model (Roles V2)

Agent

can bePerson orSystem orService orList-name

Qualifier

can bepart ofa hierarchyof qualifiers

Function

can bepart ofa hierarchyof funtions

+ +

Agent + Function + Qualifier can be stored in Roles DBor can be dynamically looked up from external systemsaccording to “External Function” rules.

29

Half-baked ideas

• In addition to Java API, would it be useful build an interface that uses XML or more-specifically SOAP?

• Would it be useful to build an LDAP interface (where attributes are generated “on-the-fly” from Roles Database)?