The Roles Database at MIT

1. The Roles Database at MIT Jim Repa (repa@mit.edu) Scott Thorne (thorne@mit.edu) September 21, 2000 CSG Conference Boulder, Colorado See also: http://web.mit.edu/rolesdb/www/educause/educause.html

2. Roles DB: Main Principles • Enter authorization info into a central DB, then send it to various target systems • Define auths. in understandable business terms, then convert for target systems • Define each authorization asAuthorization = Person + Function + Qualifier • Local department administrators maintain authorizations for their dept.’s resources

3. SAP Financial Data Warehouse Warehouse views Roles DB Admissions System Creating and disseminating authorizations 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

4. Enforcing Authorizations • Each application enforces its authorizations • First, a user must be authenticated via Kerberos or an X.509 certificate • In this model, certificates are used only for authentication: What is the person’s Kerberos username? • Then, the application answers the question Can user X do function Y with qualifier Z? using cached (usually) authorizations

5. Person + Function + Qualifier model: Does it always work? • So far it has worked – people must be convinced • System administrators may not be used to thinking about high-level roles (Roles V 2 enhancements will help) • For some business functions in SAP, a less than optimum set of Roles authorizations must be used to mirror SAP model • e.g., CAN SPEND OR COMMIT FUNDS plus REQUISITIONER and/or CREDIT CARD VERIFIER

6. Notes on Person/Function/Qual model • “Groups” are not appropriate for some types of authorizations • One could try a kluge where Groupname = Function + Qualifier, but we prefer keeping Function and Qualifier separate • Keeping Qualifiers in a hierarchy and doing dynamic auth checking gives advantages

7. Function Categories

8. Qualifiers

9. Sending Roles authorizations to various systems (non-SAP) • Each system “pulls” authorizations periodically and caches them in a local database • Systems designed with Roles model in mind need to do little or no conversion of auths. • Simple stored functions can handle checking of a user’s authority to do a function with a given qualifier

10. Mapping Roles authorizations to SAP objects • Conversion programs, written in Perl with Oracle DBI, do mapping before data are sent to SAP • Programs are partly table-driven. Some new functions can be handled without programming changes.

11. Can a person change their Kerberos username? • Yes, but we discourage it • Old userid is deleted in Athena’s database and Roles notices that the userid is gone • Authorizations can be transferred to a new username • Feeds act as if old username disappeared and a new one was created with similar authorizations

12. A word about politics • This is a new model for system administrators – some have fears about loss of control • There are advantages for departmental administrators and end-users – some “grassroots” movement • Auditors have been allies after they understood the model

13. Organizational Units • There were similar, but different hierarchies for different applications (examples) • Trying to consolidate at high level • Qualifiers can have more than one parent – not a strict hierarchy

14. Org. Units and other qualifiers • Different people are responsible for various qualifier types, maintained in other systems and fed into Roles • Proposal for new, universal, Departmenthierarchy – to be maintained by IS

15. Issues with nightly feeds • Currently feeds are nightly • More frequent feeds are possible, planned • Worst-case scenario (day 1 request Kerberos username, day 2 username gets into Roles DB and auths are created, day 3 auths are sent to other systems and become effective)

16. Audit trail and historical data • We have an audit trail that shows every change 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.

17. Statistics • How many authorizations have been created? ~40,000 for SAP and ~3,000 for other areas • How many people have been granted an authorization? ~5,000 • How many authorizations per person average authorizations/user = 9.1 maximum authorizations/user = 195 no. of users with > 100 authorizations = 11(Better grouping of qualifiers could eliminate extremes.)

18. Effort to design and maintain • Development and ramping up:Between 1996 (prototype) and present, we’vehad 1 to 2 FTEs doing software development,maintenance, evangelizing, and assistancefor target systems • Steady-state rough estimate: • 1-2 FTEs for helpdesk, training, assistance, checkingexception reports, etc. • ½ FTE technical support, maintenance

19. What we have accomplished • Working system supports our model, andis used by SAP, NIMBUS (Budget System),Graduate Admissions, Labor Distribution System, with other systems planned • Department-based authorization maintenance for SAP, with a framework in place to expand to other areas

20. Problems we’ve encountered • Who is in charge? Who owns what? After two committees and two reports, we’re still trying to clarify this • Some managers for target systems are reluctant to allow authorization maintenance to be distributed • Policies for auditing, cleanup, terminating or transferring employees, etc. should be global, but we’re still saddled with application-specific policies

21. Plans for the future: Technical • Support more versatile hierarchy of qualifiers (simple views of a complex web of objects) • Support groups of business functions • Improvements to user interface - better editing assistance and better exception checking • Better integration between HR, Athena users database, and Roles DB (simplicity, less latency) • Maybe add an API, other than current Oracle stored-procedure based interface

22. Plans for the future - operational • Consolidated department hierarchy, with central oversight • Central oversight committee should clarify the rules about Who owns what • Include more systems’ authorizations in departmental distributed maintenance