MIT’s Roles Database: Our Model for Authorizations Jim Repa Advanced Campus Architecture Middleware Planning Meeting July 9, 2003 See also: Copyright, Jim Repa, 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 elemental attribute arbitrarily complex structure (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 PERSONFUNCTIONQUALIFIER JoeReview SalariesDept. of Biology SallyCreate RequisitionsAcct FredApprove Reqs.Accts. in Biology AnnGrade StudentsCourse 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 $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 Supporting information is fed nightly from data warehouse to Roles DB 2.Front-end application is used to create “authorizations” in Roles DB 3.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. ( - 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 - 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 be Person or System or Service or List-name Qualifier can be part of a hierarchy of qualifiers Function can be part of a hierarchy of functions ++ Agent + Function + Qualifier can be stored in Roles DB or can be dynamically looked up from external systems according to “External Function” rules.