Moving Beyond Implementation Next Steps for Enterprise Directories

Moving Beyond Implementation: Next Steps for Enterprise Directories Tom Barton University of Chicago

Copyright Tom Barton 2004. 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 otherwise or to republish requires written permission from the author. CAMP Directory Workshop Feb 3 -6, 2004

Outline § § The granularization problem – use cases Lightweight authorization model Distributed groups management Heavyweight authorization CAMP Directory Workshop Feb 3 -6, 2004

¡ authorization != authentication ! § When all you have is a hammer, … § If applications can only use your core infrastructure for authentication, – how can you issue credentials and offer selective services to new constituencies? – how can you administratively deny access to some but not all services? – how can you customize a service to the user? § Somehow you need to manage the information necessary to enable appropriate, selective access to services – (and actually use it to implement access controls & customization) CAMP Directory Workshop Feb 3 -6, 2004

Uof. C hammer § Present enterprise directory service supports – Authentication via LDAP, Kerberos, AD – Posix. Account (PAM-LDAP shell login) – White pages – Account claiming & self-management – Email routing & mailbox access § Does not facilitate granular access to services! CAMP Directory Workshop Feb 3 -6, 2004

Illustrative list of services § § § Computer labs Remote library databases Accounts on clinical systems Network access (wireless, netreg, VPN, modems) IFS home dirs, collaborative spaces e. Reserves & LMS Web apps Messaging (distribution lists & authorization) Alumni community services Administrative systems & services … List goes on and on … CAMP Directory Workshop Feb 3 -6, 2004

Network access § Wireless & wireline are available to all who can authenticate … § … except for those whose computers are hacked, or who’ve been bad § In addition – VPN access won’t be provided to some populations (being determined) – Charge for modem use being considered CAMP Directory Workshop Feb 3 -6, 2004

Computer labs § “Student Eligibility Matrix” maintained by an authoritative policy group – 21 student statuses X 16 services – Some statuses are clear: enrolled-fulltime – Some are not: “pro forma” Students do not register for any credit courses. (May register for exams in absentia. ) Only approved for doctoral students in Scholastic or Advanced Residence who are away from University for dissertation research for duration of quarter. Four consecutive quarters in status may be extended by special approval to two calendar years maximum. NOTES: Still used for Lab School students Pro Forma in the College w/credit courses (@10 per quarter), BSD and PSD students in PF uniformly take credit courses for "R" grades. CAMP Directory Workshop Feb 3 -6, 2004

Computer labs § Also need to admit non-student people to the computer labs, with several cases of inclusion & exclusion by nature of affiliation – As determined by various authorities – Computer lab staff need to maintain their own list of additional admits and denies, beyond policy § May need to administratively disable someone otherwise entitled if they’ve been bad CAMP Directory Workshop Feb 3 -6, 2004

Remote library databases § Various categories of policy – Faculty/staff/student, without too much regard for the precise definitions § no alums § no guests not in the campus address space § VPN access might cause an issue – faculty/staff/student in specified professional school or graduate division – Research but not clinical use (impossible!) – Interaction with turnstile passage into (some) library facilities CAMP Directory Workshop Feb 3 -6, 2004

Clinical systems § Many systems supporting clinical & research uses of PHI (Protected Health Information) – Primarily ~10 departments, ~100 labs – Each system has “small” usership § Intended, anyway – Mix of UC and UCH personnel across userships – Much account crud built up over years of ad hoc administration CAMP Directory Workshop Feb 3 -6, 2004

Clinical systems § Solution under consideration – Leverage coordinated UC U UCH identity management being developed – Identify authorities for each clinical and research group – Manage group memberships signifying privilege to access associated clinical systems – Associate groups to departmental hierarchy to aid auditing and enforcement – Implement automation to directly manage account life cycles on clinical systems CAMP Directory Workshop Feb 3 -6, 2004

Other prospective use cases § Other areas within Uof. C might buy in to common management of posix accounts & posix groups § Consideration of using new sympa for mail list management, which brings groups for distribution lists and for access control into discussion § New Blackboard license includes Xythos web. DAV based file service, which offers the prospect of home directories/web sites for people and for groups and sharing among groups CAMP Directory Workshop Feb 3 -6, 2004

Abstracted access requirements, so far § Large constituencies or § broadly deployed technologies and § relationships with the organization (“affiliations”) are a principal determinant of access § but no single perspective is likely to be cognizant of all required affiliations. Ø Call these “lightweight” authorization requirements CAMP Directory Workshop Feb 3 -6, 2004

Administrative systems § Authorize by identity, not (just) by affiliation – – – Human judgment Delegation of authority Structure to authority (has limits & a declared scope) Designation of limited privileges Prerequisites Limited userships Ø Call these “heavyweight” authorization requirements CAMP Directory Workshop Feb 3 -6, 2004

Lightweight authorization model § Three channels of information – Major affiliations § Source of authority: admin systems + business logic in metadirectory processing. – Minor or ad hoc affiliations § Source of authority: mix of central business logic and decentralized manual and automated sources. – Per user per service positive or negative exceptions § Source of authority: select administrative access. Eg, Info security officer CAMP Directory Workshop Feb 3 -6, 2004

Major affiliation § 10 -20 values in a conservatively managed vocabulary – Widely understood semantics – Relatively static semantics – Satisfies 80% of access control needs for broadly used services – Stake will go deeply into the ground § Value syntax: type: subtype – type in {faculty, staff, student, hospital, associate, guest} – Subtypes of some of these. Eg, faculty: visiting, faculty: expected, staff: casual, staff: expected, … § uc. Affiliation LDAP attribute CAMP Directory Workshop Feb 3 -6, 2004

Minor affiliation § Maintained by distributed management of groups – Semantics are less widely understood or more dynamic – Satisfies 80% of needs for locally offered services § Group handles are reflected into is. Member. Of LDAP attribute – No value syntax beyond whatever convention for handles will apply – Handle identifier characteristics should be … ? § We’ll use Grouper! CAMP Directory Workshop Feb 3 -6, 2004

Per user per service exceptions § Vocabulary – Needs to be known only by select authorities and applications administrators – Grows as needed – Syntax is constrained only by the need to clearly reference the service and convey positive or negative semantics § Web application mediates access to uc. Priv LDAP attribute – Security managed within the person registry (Currently. Use groups later, of course!) – uc. Priv values are reflected in person registry for diagnostic purposes CAMP Directory Workshop Feb 3 -6, 2004

Lightweight authorization examples § Wireless (!(uc. Priv=no-wireless)) § Labs (&(| (uc. Affiliation=faculty) (uc. Affiliation=staff) (uc. Affiliation=student: enrolled) (is. Member. Of=student: pro. Forma) )(!(| (is. Member. Of=student: owes. Us. Too. Much. Money) (is. Member. Of=lab. Admin: keep. Em. Out) )) (is. Member. Of=lab. Admin: let. Em. In. Anyway) ) (! (uc. Priv=no-labs) )) CAMP Directory Workshop Feb 3 -6, 2004

Group management issues § Coordinating many sources of information § Supporting several styles of access to group membership information § Provisioning groups in multiple locations § Aging of groups and of memberships § Use of subgroups vs. effective membership § Referring to set theoretic combinations of groups § Maintaining referential integrity § Meeting security, privacy, & visibility requirements Ø Grouper will deal with much of this CAMP Directory Workshop Feb 3 -6, 2004

§ Simplified Grouper graphic… CAMP Directory Workshop Feb 3 -6, 2004

Grouper roadmap § Planning for building specified components and capabilities to be incorporated into Grouper v 1 is underway now – Development will occur in 3 phases § Basic management and export functions § Support for compound groups § Support for aging of groups and group memberships – Some elements & capabilities in the Group Tools Architecture will be contributed by I 2 schools, others will not occur in Grouper v 1 – An actual developer has joined the project! CAMP Directory Workshop Feb 3 -6, 2004

Grouper v 1 § In – Groups Registry, an RDBMS – Groups API supporting management and export of groups, but not extensive querying capability – One UI for manual groups management – Simple programs for batch loading and exporting of groups – Compound groups – Aging of groups and group memberships – Extensibility of group types and multiple membership fields will be capabilities of the data model in the Groups Registry not exposed in the public API CAMP Directory Workshop Feb 3 -6, 2004

Grouper v 1 § Contributed – LDAP & other provisioning connectors – Implementations of several abstracted interfaces within Grouper, such as member lookup and presentation § Out – maybe in a post v 1 release – Stream Loader and associated Rules infrastructure – Change log based provisioning § Articulation with Stanford Authority System – House aggregates to which authority can be attached – Compound groups in support of role management CAMP Directory Workshop Feb 3 -6, 2004

Back to heavyweight authorization § A system such as Stanford’s Authority Manager seems well suited to the need § Uof. C has begun internal discussions towards eventual incorporation of an authority management system – Likely to be a long row to hoe, and uncertain of the outcome for administrative applications – Conceivable that an authority system would be used for at least some clinical systems § Stay tuned for further activity on the heavyweight authorization front… CAMP Directory Workshop Feb 3 -6, 2004