The Roles Database at MIT Scott Thorne Jim Repa December 12, 2001 See also:

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

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

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

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

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

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

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