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

CAMP Directory Workshop Feb 3-6, 2004 Copyright Tom Barton 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 UofC hammer  Present enterprise directory service supports –Authentication via LDAP, Kerberos, AD –PosixAccount (PAM-LDAP shell login) –White pages –Account claiming & self-management – 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  eReserves & 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 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 UofC 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 webDAV 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  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, faculty:visiting, faculty:expected, staff:casual, staff:expected, …  ucAffiliation 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 isMemberOf 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 ucPriv LDAP attribute –Security managed within the person registry (Currently. Use groups later, of course!) –ucPriv values are reflected in person registry for diagnostic purposes

CAMP Directory Workshop Feb 3-6, 2004 Lightweight authorization examples  Wireless (!(ucPriv=no-wireless))  Labs (&(|(&(| (ucAffiliation=faculty) (ucAffiliation=staff) (ucAffiliation=student:enrolled) (isMemberOf=student:proForma) )(!(| (isMemberOf=student:owesUsTooMuchMoney) (isMemberOf=labAdmin:keepEmOut) )) (isMemberOf=labAdmin:letEmInAnyway) ) (! (ucPriv=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 v1 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 I2 schools, others will not occur in Grouper v1 –An actual developer has joined the project!

CAMP Directory Workshop Feb 3-6, 2004 Grouper v1  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 v1  Contributed –LDAP & other provisioning connectors –Implementations of several abstracted interfaces within Grouper, such as member lookup and presentation  Out – maybe in a post v1 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  UofC 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…