The Roles Database at MIT Jim Repa Scott Thorne September 21, 2000 CSG Conference Boulder, Colorado See also:

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

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 CategoryDescriptionNo. of functions SAPSAP Financials31 GRADGraduate Admissions33 METARoles DB – related (create/view auths, etc.) 9 NIMBBudget system (NIMBUS) 7...

Qualifiers TypeDescriptionCount FUNDFund Centers and Funds41961 COSTProfit Centers and Cost Objects44275 SPGPSpending Groups1845 BAGSBudget Auth. Groups264 ORGUOrg. Units (Payroll)519 AORGOrg. Units (Admissions)91 DEPTConsolidated Dept. (with links)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 are 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 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.)

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