The Roles Database at MIT

1. The Roles Database at MIT Scott Thorne (thorne@mit.edu) Jim Repa (repa@mit.edu) December 12, 2001 See also: http://web.mit.edu/rolesdb/www/educause/educause.html

2. Benefits • Business Terms • Distributed Maintenance • Multiple Systems using same Rules • Hierarchies Reduces Maintenance

3. Tuple • Joe User can do Business Function in some Context • Subject, Verb, Predicate sentence structure • Makes business rules easy to document • Generic enough to express many things • Two part expression can’t describe scope • Business Functions should hide implementation details

4. Hierarchies • Changes to Hierarchy don’t require Authorization Maintenance • Allows fewer explicit Rules to be maintained • Avoids single decision on “grain” of authorization • Alternate hierarchies over the same objects • Negation or exceptions not allowed

5. Application Responsibilities • Design Stage • Define Business functions • Define Context or Qualifier • Ongoing Maintenance • Maintain Hierarchies • Set individual authorization rules • Checking Authorizations • Interprets authorization rules • Enforces authorization rules

6. Authorization Service Responsibilities • Stores & Retrieves Information only • No Interpretation of Authorization • No Predefined Terms, only structure • Hierarchy Traversal

7. MIT ROLES DB • More Details • Where we are today • Future Plans

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

9. Why a Qualifier? • Often a person is authorized to perform a Function only within an org. area (school, dept., lab, etc.) or within a financial area

10. Why not more than one Qualifier? • 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 10

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

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 • If the Auth. specifies the root or a node, then the Auth. applies to all descendent objects under the node

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. Enforcing Authorizations • Each application enforces its authorizations • Authentication is a separate step. (We use Kerberos tickets or an X.509 certificate • In this model, certificates are used only for authentication, e.g., getting the person’s Kerberos username? • Then, the application answers the question Can user X do function Y with qualifier Z? by looking at Auths. from the Roles DB 14

15. System in production at MIT • Put into production in early 1998 • Our system is used by SAP (financial), NIMBUS (Budget System), Graduate Admissions, Labor Distribution System, with other systems planned • Maintenance of financial auths. is distributed to departments, with a framework in place to expand to other areas 15

16. 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. • Perl scripts for data feeds of supporting info • Java API under development

17. SAP Financial Data Warehouse Warehouse views Roles DB Admissions System Current implementation at MIT: Data flow 1 3 2 Power Builder Appl. • Supporting information is fed nightly from data warehouse to Roles DB • Front-end application is used to create “authorizations” in Roles DB • Authorization information is converted and sent to various applications 17

18. Looking up Auth. information • 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.

19. Java API under development • Will support • Lookups of Authorizations • Real-time maintenance of Functions and Qualifiers • Tentative schedule • First implementation of minimal functionality planned for late January • Additional reporting features added later

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