1 / 11

MIT ROLES DB

MIT ROLES DB. CSG, May 2004. Previous Presentations. Talk given by Jim Repa at EDUCAUSE Conference (Long Beach, CA, Oct. 29, 1999) http://web.mit.edu/rolesdb/www/educause/educause.html Talk given by Jim Repa to Common Solutions Group (Chicago, Sept. 18, 1998)

ira-levy
Télécharger la présentation

MIT ROLES DB

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 ROLES DB CSG, May 2004

  2. Previous Presentations • Talk given by Jim Repa at EDUCAUSE Conference (Long Beach, CA, Oct. 29, 1999) • http://web.mit.edu/rolesdb/www/educause/educause.html • Talk given by Jim Repa to Common Solutions Group (Chicago, Sept. 18, 1998) • http://web.mit.edu/rolesdb/www/csg/csg.html • Slides from Jim Repa's presentation of October 7, 1997 http://web.mit.edu/is/integration/presentations/roles_10071997/

  3. A new perspective • The MIT ROLES database is not a Roles Based Access Control (RBAC) system • It is a meta-authorization management system • An RBAC system could be built using the MIT ROLES system

  4. Characteristics • Applications and services do not query or update ROLES in real time. • Data is extracted from the database and transformed into native, legacy, format for consumption • We do not define a “role” that is then applied to a number of users • Roles does provide for inheritance of authorizations

  5. A Reminder • An Authorization = PERSON + FUNCTION + QUALIFIER • But the system also provides for starting and ending dates • In the future, an Authorization = object + FUNCTION +QUALIFIER

  6. The ROLES DB can be used to form • Tables in other databases • Access Control Lists • LDAP groups • LDAP attributes • or populating configuration files such as .k5login • It could even be used to help formulate policies within rule based systems.

  7. Obstacles to usage • Current access is via SQL*NET and Oracle • No APIs to ease access from native code • Benefits accrue to departmental administrators • Benefits do not accrue to system developers, system integrators, most of central IS&T

  8. Another obstacle • No support for real-time or programmatic updates of qualifiers • There are OKI OSIDs to address this issue but they have only been used against a test instance at this time

  9. Systems using ROLES in production • SAP financials • Data Warehouse • Human Resource systems • NIMBUS budget system • Graduate Admissions • MIT ID database • access to student information in data warehouse • Environmental Health and Safety • miscellaneous administration tasks

  10. Notable systems not using ROLES at this time • AFS PTS • Moira • web publication • OCW • central Active Directory • Help desk tools including Casetracker, RT, Stock Answers and OLC • Stellar • any Library systems • COEUS • Student Information Systems • MIT Events Calendar • TechTime (Corporate Time) • access to buildings, parking lots, machine rooms, hazardous labs,

  11. Some Statistics • The number of authorization functions defined: 185 • The number of individual authorizations currently defined: 63997 • The number of authorizations that have defined boundary dates: 1159, of these 980 created by department of Dean for Student Life • The number of AFS and NFS groups defined in Moira: 20955 • The number of other ACLs defined in Moira: 43215

More Related