mit’s roles database: our model for authorizations jim repa ([email protected]) advanced campus...
Post on 20-Dec-2015
224 views
TRANSCRIPT
MIT’s Roles Database:Our Model for Authorizations
Jim Repa ([email protected])
Advanced Campus Architecture
Middleware Planning Meeting
July 9, 2003
See also: http://web.mit.edu/rolesdb/www/educause/educause.html
Copyright, Jim Repa, 2003. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate or otherwise to republish requires written permission from the author.
System in production at MIT
• Production in early 1998 (idea from Scott Thorne)• Our system is used by SAP (financial), NIMBUS
(Budget System), Grad. Admissions, Labor Distribution System, EHS (Environmental Health & Safety), HR, and the Data Warehouse
• Maintenance of financial auths. is distributed to departments, and soon maintenance of HR auths. will be distributed as well
• Scope: Authorizations for internal MIT people to business functions in administrative systems
2
3
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
4
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
5
6
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
7
Functions are grouped into Categories
• Functions are organized into general business areas or “Categories”, e.g., – financial– HR– graduate admissions– Environmental Health and Safety
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 for 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
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
11
12
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
• The QualifierType (i.e., which hierarchy of qualifiers) is related to the Function
13
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• Permits alternate hierarchies over the same objects• Negation or exceptions not allowed
14
Hierarchies for Functions, etc.
• We plan to allow Functions to be organized into hierarchies as well, in a future version
• For Person, OKI spec substitutes “agent”, which could be a list or group, and we will add this in future– In our first release of Roles, we deliberately prohibited
the notion of groups.
– We thought people would ignore the richness of the 3-part authorization and use groups too much
15
Is there always a Qualifier?
• Some Functions are associated with the special QualifierType “NULL”.
• Authorizations for these Functions are not restricted by a Qualifier
16
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) - iterative
– Sets individual auths. (or distributes work to depts.)
– Interprets auth. rules
– Enforces auth. rules
17
Why do we avoid thinking of Attributes?
• An Authorization is P + F + Q
• What is an attribute of what?
• You could say:– F + Q is an attribute of P– P + Q is an attribute of F– P + F is an attribute of Q (which might make
the most sense)
18
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
19
What about policies?
• One could imagine this scenario: (a) tell system about a person, (b) tell system general rules for who is authorized, (c) system decides if person is authorized. But it usually wouldn’t work.
• This works: Decide what person gets to decide who is authorized. “Policies” are their business and out of scope of Roles Database
20
Why policies do not work for us• For administrative systems, there is no information
that is already known that is sufficient to determine who should be authorized to do something
• There are so many exceptions, it is better to create brand new, unambiguous roles and assign specially
• It is not sufficient to say “Most people with attribute XYZ can perform function ABC” – it would only work if we can say “All people with attribute XYZ without exception will automatically have authority to do ABC”.
21
Primary Authorizers
• There is one or more Primary Authorizers per department
• Primary Authorizers are chosen by the department head. In steady state, there is little maintenance work
• Primary Authorizers decide who is authorized for resources in their department
22
More on Primary Authorizers...
• The PA in Biology can grant authorizations to– Spend, report, approve, etc. on account nos.
within the Dept. of Biology– Do reporting at various levels or do HR
transactions for HR data for people in the dept.
• We will be enhancing Roles DB to allow different Financial and HR PAs.
23
The players
• Central Authorizer group – group that gives support to PAs for granting authorizations
• Primary Authorizers – people in each department who can grant auths. to do business functions against their resources
• CA Oversight Committee – committee of reps from Auditing, Financials, HR, IT, academic depts., etc. who review how everything works and work toward expanded use of Roles DB
24
When people leave a dept. or MIT...
• The Central Authorizer group can run a report at will to see what people, who have one or more auths. in the Roles DB, have changed dept. or left MIT
• CA group generally runs this report every week or two
• They then notify PAs that auths. might need to be reviewed
26
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
• You can optionally specify (a) start date, (b) end date, (c) grant flag
27
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
• In future, some apps may 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.
28
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?– Roles DB stores (Person + Function + Qualifier) and
“expands” the auth. according to the hierarchy if requested
– Each application interprets and enforces
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
29
…
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.
30
31
Components of our system
• Oracle Database with PL/SQL stored procedures• PowerBuilder front-end (planned to be replaced)
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 planned
32
What our system does well
• Handles authorizations for internal people where each user is individually known
• Controls access to sensitive or high-consequence transactions
• Handles auths for people wearing multiple hats across department boundaries
• Allows each department to grant authorizations based on their local “policies”
• Gives rapid response to queries, even when hierarchies are involved
33
What our system does not currently do
• Support authorization for anonymous users
• Support “attribute-driven” auths
• Support authorization for external users (except those who have their own Kerberos ID at MIT)
34
Some statistics
• No. of authorizations (non-expanded): 58,217• No. of people who have at least one authorization:
5572• No. of people who have created at least one
authorization: 195
35
Maintained vs. expanded auths.
• Example 1: Spending by account no.– No. of maintained auths: ~11,900– No. of expanded auths: ~714,000
• Example 2: Reporting by account no.– No. of maintained auths: ~9,600– No. of expanded auths: ~1,198,000
• There are ~5,300 unique people with financial auths, and ~ 46,000 account numbers. (Numbers as of July, 2003.)
What’s new or planned?
• Roles DB used for new systems in the process of implementation:– New HR system being phased in
– Environmental Health & Safety System phased in
• Java API (OKI)• Planned major new release: Roles Version 2 -
timing depends on budget issues
36
37
OKI: Java API• Supports
– Lookups of Authorizations– Real-time maintenance of Authorizations, Functions
and Qualifiers
• Official specification and reference implementation to be completed by end of the summer
• For more info: See Source Forge, or OKI team (contact Peter Wilkins - [email protected])
• Univ.of Mich. has written an application using an early version of the API, and a simple database on the back end
38
MIT Roles DB and Java
• Proof-of-concept API using Roles DB was done in 2002
• When will MIT implement official API over its Roles DB using current OKI specs? This depends on budget and staffing issues.
39
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)
• Timetable also depends on budget, staffing
40
Future auth. model (Roles V2)
Agent
can bePerson orSystem orService orList-name
Qualifier
can bepart ofa hierarchyof qualifiers
Function
can bepart ofa hierarchyof functions
+ +
Agent + Function + Qualifier can be stored in Roles DBor can be dynamically looked up from external systemsaccording to “External Function” rules.