1 / 12

Plans for authz, groups, roles

Plans for authz, groups, roles. 09/18/2002 Computing Services Carnegie Mellon University. Current Situation. Groups via AFS PTS Central Directory Dialup, email delivery Software download Application directory Web publishing Self defined groups Network registration

slade-farrell
Download Presentation

Plans for authz, groups, roles

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. Plans for authz, groups, roles 09/18/2002 Computing Services Carnegie Mellon University

  2. Current Situation • Groups via AFS PTS • Central Directory • Dialup, email delivery • Software download • Application directory • Web publishing • Self defined groups • Network registration • Lots of authz based on successful authn

  3. Work in Progress • AFS PTS groups mapped to LDAP • Programming API for manipulating LDAP groups and Apache module • http://nil.andrew.cmu.edu/ldap/groups/

  4. LDAP Groups • Personal (static) • Users can create and manipulate • Associated with individual • behaves similar to PTS • System (Dynamic) • Dynamic grouping based on “roles” • e.g. faculty, staff, students, computer science, english, etc. • Adhoc – can be statically stored or calculated dynamically • A combination group derived from a white list group, a black list group and a ldap query • White list : administratively included • Black list : administratively excluded • ldap URL

  5. Roles and Entitlements • Roles • High level definition about the person • e.g. student/staff/faculty, pgh/west coast/greece campus, full/part time, etc. • Entitlements • List of services to be allowed or disallowed • DialupAbility, loginAbility, email quota, sponsor another account • Roles set/update Entitlements

  6. Representing Roles • Flat list, e.g. UNDERGRAD-FT-PGH? • Hierarchical – roots of faculty, staff student? • Union of characteristics: (UNDERGRAD & PART_TIME & GREECE_CAMPUS)

  7. Representing Entitlements • Entitlements may have “consumables” (quotas); value of the consumable may also be affected by the role • State of Entitlements are • no -> {Administratively disabled, not entitled, entitled but exhausted consumable} • yes -> {Administratively enabled, entitled by role & sufficient consumable}

  8. Role Transitions • More interested in the change of roles to enable and disable functionality, e.g. student -> alumnus; student -> staff; etc. • Entry and exit changes on entitlement of the roles?

  9. Open Issues – Accounts vs. People • Object associated with the person that is independent of the computer account. • Person may have multiple accounts or instances of the account (e.g. user@ANDREW.CMU.EDU, user/admin@ANDREW.CMU.EDU • Accounts may be equivalent (user@CS.CMU.EDU, user@ANDREW.CMU.EDU) • Accounts may not be equivalent (user@CS.CMU.EDU, user/admin@ANDREW.CMU.EDU)

  10. Open Issues – Roles/Entitlement Maintenance • How are they defined and advertised • How can they be added and deleted • How are they understood and the semantic meaning not changed or overloaded

  11. Open Issues – Using authz • Replication latency • Application caching • Managing multiple roles / authz theft

  12. Comments/Questions? • Project Lead: Tom Dopirak <tgd@cmu.edu>

More Related