1 / 29

MIT’s Roles Database: Our Model for Authorizations

MIT’s Roles Database: Our Model for Authorizations. Jim Repa (repa@mit.edu) 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

maina
Download Presentation

MIT’s Roles Database: Our Model for Authorizations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MIT’s Roles Database:Our Model for Authorizations Jim Repa (repa@mit.edu) Common Solutions Group January 11, 2002 See also: http://web.mit.edu/rolesdb/www/educause/educause.html

  2. 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 arbitrarily complex structure (Function, Qualifier) elemental attribute

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

  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

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

  20. SAP Financial Data Warehouse Warehouse views Roles DB Admissions System Current implementation at MIT: Data flow 1 3 2 Power Builder Appl. • Supporting information is fed nightly from data warehouse to Roles DB • Front-end application is used to create “authorizations” in Roles DB • 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.

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

  25. 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 be Person or System or Service or List-name + Function can be part of a hierarchy of funtions + Qualifier can be part of a hierarchy of qualifiers Agent + Function + Qualifier can be stored in Roles DB or can be dynamically looked up from external systems according 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)?

More Related