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

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

Creating and disseminating authorizations

Data Warehouse

Roles DB

Power Builder Appl.

Warehouse views

Admissions System

SAP Financial

1

2

3

1. Supporting information is fed nightly from data warehouse to Roles DB2. Front-end application is used to create “authorizations” in Roles DB3. 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 No. of functions

SAP SAP Financials 31

GRAD Graduate Admissions 33

META Roles DB – related

(create/view auths, etc.)

9

NIMB Budget system (NIMBUS)

7

... ... ...

Qualifiers

Type Description Count

FUND Fund Centers and Funds 41961

COST Profit Centers and Cost Objects 44275

SPGP Spending Groups 1845

BAGS Budget Auth. Groups 264

ORGU Org. Units (Payroll) 519

AORG Org. Units (Admissions) 91

DEPT Consolidated 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, Departmenthierarchy – 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’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, checking

exception reports, etc.– ½ FTE technical support, maintenance

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

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