the roles database at mit jim repa ([email protected]) scott thorne ([email protected]) september 21, 2000...
TRANSCRIPT
The Roles Database at MIT
Jim Repa ([email protected])
Scott Thorne ([email protected])
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