Roles CSG Talk

The Roles Database
at the
Massachusetts Institute of Technology

Jim Repa

repa@mit.edu

September 18, 1998

Additional information available at http://web.mit.edu/rolesdb

Provides a central facility for maintaining information on people's roles or authorizations for (some) computer-based applications.
Disseminates authorization information to the systems that need it.
Supports an environment where there are many people with similar roles but in different departments.
can distribute role/authorization maintenance to local department people who understand their departments.

After authorization information is converted and sent to each application system, the Roles DB is out of the picture.
For each system, users connect (authenticate) using their Kerberos username (or for Web applications, a certificate containing their username)
Each system checks authority to perform each transaction by comparing the username and desired function and "qualifier" against its locally stored table of authorizations

Often, people are authorized to do a function only within an organizational unit (school, dept., lab, etc.) or an account number. Functions are similar in different departments, but we need a way to differentiate between them.
With qualifiers, we only need a small number of functions, and can keep the logic simple for processing them.

One qualifier is a good compromise between simplicity and understandability vs. versatility.
We think most useful authorizations will only need one qualifier.
If the "2nd qualifier" only has a few possible values, we can build them into the function definition, e.g.,
- Anne can do reqs. for < $5K for account #34512.
- Bob can do reqs. for < $10K for account #34512.
- Chris can do reqs. for any amt. for account #34512.

Organizational units are hierarchical:
Account numbers are also grouped. Their structure is a "web" rather than a strict hierarchy, ie., an account number can be a member of mor than one group.

Each authorization has a "grant" switch that determines whether the owner of that authorization can grant it to others
If the "grant" switch is turned on, the owner can grant a new authorization where:
- Person is anybody at MIT (with a Kerberos username)
- Function is the same function as that in the original authorization
- Qualifier is the either the same qualifier or one of its descendents in the hierarchy
- Grant-switch is either ON or OFF

SAP financial system
- Roles DB used for maintaining auth. information since June, 1998
- There was initial resistance, but now most people "like it"
- School of Management and a group of Engineering administrative officers are using Roles DB directly
- Most maintenance is still done centrally by a small group of SAP administrators plus a few "school coordinators"
- More distribution to departments planned for January, 1999
Graduate Admissions system
- Central maintenance today.
- Plans for distribution in future
Data warehouse
- Will soon share SAP authorizations for control of viewing financial data
- Roles DB will soon control auths. for viewing of personnel data; authorizations maintained by Personnel Department
- Converted authorizations used as a joined table for VIEWs of data
Other systems under development likely to use Roles DB:
- Web-based budget planning system
- More Registrar-sponsored systems
- More central IS infrastructure systems
- Who knows what else?

Last modified by sbjones@mit.edu on October 2, 1998.