MIT’s Roles Database:Our Model for Authorizations
Jim Repa ([email protected])
Common Solutions Group
January 11, 2002
See also: http://web.mit.edu/rolesdb/www/educause/educause.html
System in production at MIT
• Put into production in early 1998• Our system is used by SAP (financial), NIMBUS
(Budget System), Grad. Admissions, Labor Distribution System, Data Warehouse, with other systems planned
• Maintenance of financial auths. is distributed to departments, with a framework in place to expand to other areas
2
3
Components of our system
• Oracle Database with PL/SQL stored procedures• PowerBuilder front-end for distributed
maintenance of authorizations• Web front-end for more wide-spread viewing of
authorizations and related info. (http://rolesweb.mit.edu - some pages are public)
• Perl scripts for data feeds of supporting info• Java API under development
4
Benefits of our model
• Describe authorizations in business terminology, not arcane terminology of each application
• Distribute maintenance of auths. to departments
• Multiple systems use same rules
• Use of hierarchies reduces maintenance
5
Auth. complexity continuum
• Imagine representing an authorization as a Person + a simple or complex attribute
elementalattribute
arbitrarilycomplexstructure
(Function, Qualifier)
Our Authorization is a Triplet
• Authorization = Person + Function + Qualifier– (for OKI, a “person” will be generalized to an “agent”)
• Lets someone do something somewhere:– Who? = Person– What? = Function– Where? = Qualifier
• Qualifier is picked from a hierarchy and may be a node or a leaf
• (Also, optional expiration date, and a flag that says whether you can grant this and subordinate auths.)
6
7
Why a Triplet?• Often a person is authorized to perform a
Function only within an org. area (school, dept., lab, etc.) or within a financial area
PERSON FUNCTION QUALIFIER
Joe Review Salaries Dept. of Biology
Sally Create Requisitions Acct. 12345
Fred Approve Reqs. Accts. in Biology
Ann Grade Students Course 6.001
8
Why bother to separate Function and Qualifiier?
• Example:– Joe is in list Read_course_1234– Sally is in list Give_grades_5678
• Problems:– Need to store logic or mapping info externally– You might have 250K different lists (e.g. 50K account
nos. X 5 business functions)– If you distribute maintenance of lists (or attributes) to
non-technical people, how are you going to explain this?
9
Yes, but...
• Can’t you make Joe a member of a class and then set attributes to indicate what he can do (read materials, update materials, set grades, etc.)? Can’t you use two or more list memberships instead of a triplet?
• Example:– Joe is member of class 1234
– Joe is also a member of class 4321
– Joe has the “read materials” attribute
10
No, you still need triplets
• What happens if Joe is a student in two courses, but teaches a third course? The attribute (“can read course materials”, “can set grades”, etc.) must be individually tied to each course of which Joe is a “member”
• Thus, we’re back to 3-part authorization objects
11
Can we derive auths. from job title?
• Sometimes, but not in general case
• There are cross-departmental projects
• There students and outside contractors who have authorizations but no job title
• A job title does not mean the same thing in every department, or even for 2 people with same title in the same department
Why not more complex entities? – Why not more than one Qualifier?
• Keep it simple and we can distribute maintenance• Our experience is: You don’t need more than one.
– Define a few simple roles and secondary “qualifiers” may drop out
– You may need a few extra Functions, (e.g., Create Requisitions < $1K, Create Requisitions < $5K, Create Requisitions > $5K)
• Describing auth. needs in the P + F + Q model helps you to separate the business roles from the arcane technobabble of your software
12
13
Is there always a Qualifier?
• Some Functions are associated with the special QualifierType “NULL”.
• Authorizations for these Functions are not restricted by a Qualifier
14
Creating an Authorization
• To create an Authorization, pick a Person, a Function, and a Qualifier from existing tables
• Each Function has an associated QualiferType (e.g., “Spend Funds” might require an acct. no. or group of acct. nos.)
• Your authority to create authorizations will be restricted to certain Functions and Qualifiers
15
Qualifiers are organized into hierarchies
• Qualifiers of a given QualifierType start at a root node, and include 2 or more levels
• The Qualifier component of an Authorization can be the root, a node, or a leaf within the tree
• If the Auth. specifies the root or a node, then the Auth. applies to all descendent objects under the node
16
Advantages of hierarchies
• Allows fewer explicit Authorizations to be maintained
• Changes to hierarchy don’t require Authorization maintenance
• Avoids single decision on “grain” of authorization
• Alternate hierarchies over the same objects• Negation or exceptions not allowed
17
Maintained vs. expanded auths.
• Example 1: Spending by account no.– No. of maintained auths: ~10,600
– No. of expanded auths: ~630,000
• Example 2: Reporting by account no.– No. of maintained auths: ~8,300
– No. of expanded auths: ~886,000
• (Note: There are ~5,400 unique people with financial auths, and ~46,000 account numbers)
18
Authentication vs. authorization
• Authentication: Identify a person– Kerberos tickets
– X.509 certificates (find person’s Kerberos username in the certificate, and use only that field)
• Authorization: What is a person allowed to do?– Store Person + Function + Qualifier in Roles DB
– Each application interprets and enforces
19
What about cross-domain authentication?
• (We don’t have this in place yet, and we might debate this further, but here’s what we’re leaning toward)
• Does person need a distinct username at MIT for auditing purposes or extensive detailed authorizations? – If so, then give him/her an MIT Kerberos username– If not, then “authenticate” as a generic outside user, e.g.,
“StanfordStudent”
• Authorizations could be based on real username or one of several generic outside usernames
Current implementation at MIT: Data flow
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
20
21
Division of labor: Central service vs. the various applications
• Central service– Stores and retrieves information
– Handles traversal of hierarchy
• Each application– In design stage: defines business functions and
qualifiers (context for each function)
– Sets individual auths. (or distributes work to depts.)
– Interprets auth. rules
– Enforces auth. rules
22
Looking up Auth. information – “Can user X do function Y with qual. Z?”
• Some applications pull extract of Authorizations from Roles DB and save in local cache
• Others do real-time lookups via Oracle stored procedures or (soon-to-be-released) Java API
• In one case (SAP), we convert and push Auth. information to the external app.
Audit trail and historical data
• We have an audit trail that shows every change made 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.
23
24
Some statistics
• No. of authorizations (non-expanded): 57131
• No. of people who have at least one authorization: 6965
• No. of people who have created at least one authorization: 220
What’s new or under development?
• Java API (OKI)
• Planned major new release: Roles Version 2
25
26
Java API under development
• Will support– Lookups of Authorizations
– Real-time maintenance of Functions and Qualifiers
• Implementation planned for this year (exact schedule TBD)– See http://blue-goose.mit.edu/roles_api_docs.html
(later, you can get info from the OKI site)
– Warning: These API documents are volatile
27
Roles Version 2
• More sophisticated hierarchies– Multiple views – the same “Qualifiers” can be grouped
differently depending on the context– A Qualifier can be have more than one QualifierType
• Functions can be grouped into hierarchies as well• Better control over who can view what auths.• A facility to support querying/checking of
authorizations that are implied by data in other systems, i.e.,where Roles DB is not the system of record (back-end database link to other systems)
28
Future auth. model (Roles V2)
Agent
can bePerson orSystem orService orList-name
Qualifier
can bepart ofa hierarchyof qualifiers
Function
can bepart ofa hierarchyof funtions
+ +
Agent + Function + Qualifier can be stored in Roles DBor can be dynamically looked up from external systemsaccording to “External Function” rules.
29
Half-baked ideas
• In addition to Java API, would it be useful build an interface that uses XML or more-specifically SOAP?
• Would it be useful to build an LDAP interface (where attributes are generated “on-the-fly” from Roles Database)?