The Roles Database at MIT Jim Repa repa mit

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

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 as Authorization = Person + Function + Qualifier • Local department administrators maintain authorizations for their dept. ’s resources

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

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

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

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

Function Categories Category Description SAP Financials No. of functions 31 GRAD Graduate Admissions 33 META Roles DB – related (create/view auths, etc. ) Budget system (NIMBUS). . . 9 NIMB. . . 7. . .

Qualifiers Type FUND COST SPGP BAGS ORGU AORG DEPT Description Fund Centers and Funds Profit Centers and Cost Objects Spending Groups Budget Auth. Groups Org. Units (Payroll) Org. Units (Admissions) Consolidated Dept. (with links) Count 41961 44275 1845 264 519 91 894

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

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.

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

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

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

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, Department hierarchy – to be maintained by IS

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)

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.

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 person average authorizations/user = 9. 1 maximum authorizations/user = 195 no. of users with > 100 authorizations = 11 (Better grouping of qualifiers could eliminate extremes. )

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

What we have accomplished • Working system supports our model, and is 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

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

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

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