1. 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

2. 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. 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. 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. 5 Auth. complexity continuum Imagine representing an authorization as a Person + a simple or complex attribute elemental attribute arbitrarily complex structure (Function, Qualifier)

6. 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. 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 PERSONFUNCTIONQUALIFIER JoeReview SalariesDept. of Biology SallyCreate RequisitionsAcct. 12345 FredApprove Reqs.Accts. in Biology AnnGrade StudentsCourse 6.001

8. 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. 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. 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. 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

12. 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 12

13. 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. 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. 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. 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. 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. 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. 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

20. 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 DB 2.Front-end application is used to create “authorizations” in Roles DB 3.Authorization information is converted and sent to various applications 20

21. 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. 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.

23. 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. 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

25. What’s new or under development? Java API (OKI) Planned major new release: Roles Version 2 25

26. 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. 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. 28 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 funtions ++ Agent + Function + Qualifier can be stored in Roles DB or can be dynamically looked up from external systems according to “External Function” rules.

29. 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)?