MIT ROLES DB Internet 2 Authority Architectures CAMP, June 2004

2 Notice Copyright Paul B. Hill, 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 otherwise or to republish requires written permission from the author.

3 What is the MIT ROLES Database? The MIT ROLES database is not a Roles Based Access Control (RBAC) system Centrally manages and maintains a user’s (or object’s) authorizations for a variety of applications and systems Is it a meta-authorization management system?

4 Characteristics Applications and services do not query or update ROLES in real time. Data is extracted from the database and transformed into native, legacy, format for consumption We do not define a “role” that is then applied to a number of users The Roles-DB does provide for inheritance of authorizations

5 Authorization in the ROLES-DB context Define authorizations or roles in understandable business terminology, then have the system automatically convert them to the arcane format required by each application. An Authorization = PERSON + FUNCTION + QUALIFIER But the system also provides for starting and ending dates In the future, an Authorization = object + FUNCTION +QUALIFIER

6 Example authorizations Person FunctionQualifier FredFlynCreate RequisitionsF (Bioengineering PhD Program) JaneDoeApprove Requisitions SG_BIOLOGY (Spending group for dept. of Biology) pbhLogin as rootfinn.mit.edu JonClerk Assign employee ID numbers NULL (no qualifier needed)

7 The ROLES DB can be used to form Tables in other databases Access Control Lists LDAP groups LDAP attributes (or a Shibboleth AA) populating configuration files such as.k5login It could be used to help formulate policies within rule based systems.

8 Additional attributes of an Authorization effective_date – when the authorization goes into effect expiration_date – when the authorization will cease to be effective Grant – flag to grant, change, or delete authorizations do_function – flag to perform or deny the function

9 Obstacles to usage Current access is via SQL*NET and Oracle No APIs to ease access from native code Benefits accrue to departmental administrators Benefits do not accrue to system developers, system integrators, most of central IS&T

10 Another obstacle No support for real-time or programmatic updates of qualifiers There are OKI OSIDs to address this issue but they have only been used against a test instance at this time

11 MIT Systems using ROLES SAP financials Data Warehouse Human Resource systems NIMBUS budget system Graduate Admissions MIT ID database access to student information in data warehouse Environmental Health and Safety miscellaneous administration tasks

12 Notable MIT systems not using ROLES at this time AFS PTS Moira web publication OCW central Active Directory Help desk tools including Casetracker, RT, Stock Answers and OLC Stellar any Library systems COEUS Student Information Systems MIT Events Calendar TechTime (Corporate Time) access to buildings, parking lots, machine rooms, hazardous labs,

13 Some Statistics (May 2004) The number of authorization functions defined: 185 The number of individual authorizations currently defined: The number of authorizations that have defined boundary dates: 1159, of these 980 created by department of Dean for Student Life The number of AFS and NFS groups defined in Moira: The number of other ACLs defined in Moira: 43215

14 Previous Presentations Talk given by Jim Repa at EDUCAUSE Conference (Long Beach, CA, Oct. 29, 1999) – Talk given by Jim Repa to Common Solutions Group (Chicago, Sept. 18, 1998) – Slides from Jim Repa's presentation of October 7, es_ / es_ /