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

2. 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

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

4. ¡ 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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, faculty:visiting, faculty:expected, staff:casual, staff:expected, …
ucAffiliation LDAP attribute
CAMP Directory Workshop Feb 3-6, 2004

18. 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

19. 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

20. 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

21. 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

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

23. 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

24. 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

25. Grouper v1 Contributed Out – maybe in a post v1 release
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

26. 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…
CAMP Directory Workshop Feb 3-6, 2004