MIT’s Roles Database:Our Model for Authorizations

Jim Repa (repa@mit.edu)

Advanced Campus Architecture

Middleware Planning Meeting

July 9, 2003

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

Copyright, Jim Repa, 2003. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate or otherwise to republish requires written permission from the author.

System in production at MIT

• Production in early 1998 (idea from Scott Thorne)• Our system is used by SAP (financial), NIMBUS

(Budget System), Grad. Admissions, Labor Distribution System, EHS (Environmental Health & Safety), HR, and the Data Warehouse

• Maintenance of financial auths. is distributed to departments, and soon maintenance of HR auths. will be distributed as well

• Scope: Authorizations for internal MIT people to business functions in administrative systems

2

3

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

4

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

5

6

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

7

Functions are grouped into Categories

• Functions are organized into general business areas or “Categories”, e.g., – financial– HR– graduate admissions– Environmental Health and Safety

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

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

11

12

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

• The QualifierType (i.e., which hierarchy of qualifiers) is related to the Function

13

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• Permits alternate hierarchies over the same objects• Negation or exceptions not allowed

14

Hierarchies for Functions, etc.

• We plan to allow Functions to be organized into hierarchies as well, in a future version

• For Person, OKI spec substitutes “agent”, which could be a list or group, and we will add this in future– In our first release of Roles, we deliberately prohibited

the notion of groups.

– We thought people would ignore the richness of the 3-part authorization and use groups too much

15

Is there always a Qualifier?

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

• Authorizations for these Functions are not restricted by a Qualifier

16

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) - iterative

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

– Interprets auth. rules

– Enforces auth. rules

17

Why do we avoid thinking of Attributes?

• An Authorization is P + F + Q

• What is an attribute of what?

• You could say:– F + Q is an attribute of P– P + Q is an attribute of F– P + F is an attribute of Q (which might make

the most sense)

18

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

19

What about policies?

• One could imagine this scenario: (a) tell system about a person, (b) tell system general rules for who is authorized, (c) system decides if person is authorized. But it usually wouldn’t work.

• This works: Decide what person gets to decide who is authorized. “Policies” are their business and out of scope of Roles Database

20

Why policies do not work for us• For administrative systems, there is no information

that is already known that is sufficient to determine who should be authorized to do something

• There are so many exceptions, it is better to create brand new, unambiguous roles and assign specially

• It is not sufficient to say “Most people with attribute XYZ can perform function ABC” – it would only work if we can say “All people with attribute XYZ without exception will automatically have authority to do ABC”.

21

Primary Authorizers

• There is one or more Primary Authorizers per department

• Primary Authorizers are chosen by the department head. In steady state, there is little maintenance work

• Primary Authorizers decide who is authorized for resources in their department

22

More on Primary Authorizers...

• The PA in Biology can grant authorizations to– Spend, report, approve, etc. on account nos.

within the Dept. of Biology– Do reporting at various levels or do HR

transactions for HR data for people in the dept.

• We will be enhancing Roles DB to allow different Financial and HR PAs.

23

The players

• Central Authorizer group – group that gives support to PAs for granting authorizations

• Primary Authorizers – people in each department who can grant auths. to do business functions against their resources

• CA Oversight Committee – committee of reps from Auditing, Financials, HR, IT, academic depts., etc. who review how everything works and work toward expanded use of Roles DB

24

When people leave a dept. or MIT...

• The Central Authorizer group can run a report at will to see what people, who have one or more auths. in the Roles DB, have changed dept. or left MIT

• CA group generally runs this report every week or two

• They then notify PAs that auths. might need to be reviewed

25

Stop here.

• Save the rest of the slides for tomorrow.

26

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

• You can optionally specify (a) start date, (b) end date, (c) grant flag

27

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

• In future, some apps may 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.

28

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?– Roles DB stores (Person + Function + Qualifier) and

“expands” the auth. according to the hierarchy if requested

– Each application interprets and enforces

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

29

…

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.

30

31

Components of our system

• Oracle Database with PL/SQL stored procedures• PowerBuilder front-end (planned to be replaced)

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 planned

32

What our system does well

• Handles authorizations for internal people where each user is individually known

• Controls access to sensitive or high-consequence transactions

• Handles auths for people wearing multiple hats across department boundaries

• Allows each department to grant authorizations based on their local “policies”

• Gives rapid response to queries, even when hierarchies are involved

33

What our system does not currently do

• Support authorization for anonymous users

• Support “attribute-driven” auths

• Support authorization for external users (except those who have their own Kerberos ID at MIT)

34

Some statistics

• No. of authorizations (non-expanded): 58,217• No. of people who have at least one authorization:

5572• No. of people who have created at least one

authorization: 195

35

Maintained vs. expanded auths.

• Example 1: Spending by account no.– No. of maintained auths: ~11,900– No. of expanded auths: ~714,000

• Example 2: Reporting by account no.– No. of maintained auths: ~9,600– No. of expanded auths: ~1,198,000

• There are ~5,300 unique people with financial auths, and ~ 46,000 account numbers. (Numbers as of July, 2003.)

What’s new or planned?

• Roles DB used for new systems in the process of implementation:– New HR system being phased in

– Environmental Health & Safety System phased in

• Java API (OKI)• Planned major new release: Roles Version 2 -

timing depends on budget issues

36

37

OKI: Java API• Supports

– Lookups of Authorizations– Real-time maintenance of Authorizations, Functions

and Qualifiers

• Official specification and reference implementation to be completed by end of the summer

• For more info: See Source Forge, or OKI team (contact Peter Wilkins - pwilkins@mit.edu)

• Univ.of Mich. has written an application using an early version of the API, and a simple database on the back end

38

MIT Roles DB and Java

• Proof-of-concept API using Roles DB was done in 2002

• When will MIT implement official API over its Roles DB using current OKI specs? This depends on budget and staffing issues.

39

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)

• Timetable also depends on budget, staffing

40

Future auth. model (Roles V2)

Agent

can bePerson orSystem orService orList-name

Qualifier

can bepart ofa hierarchyof qualifiers

Function

can bepart ofa hierarchyof functions

+ +

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