Date post: | 13-Jan-2016 |
Category: |
Documents |
Upload: | carol-roberts |
View: | 221 times |
Download: | 0 times |
Moving Beyond Moving Beyond Implementation: Next Steps for Implementation: Next Steps for
Enterprise DirectoriesEnterprise Directories
Tom Barton
University of Chicago
CAMP Directory Workshop Feb 3-6, 2004
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
OutlineOutline
The granularization problem – use cases Lightweight authorization model Distributed groups management Heavyweight authorization
CAMP Directory Workshop Feb 3-6, 2004
¡ ¡ authorization != authentication !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 hammerUofC hammer
Present enterprise directory service supports– Authentication via LDAP, Kerberos, AD– PosixAccount (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 servicesIllustrative 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 accessNetwork 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 labsComputer 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 labsComputer 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 databasesRemote 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 systemsClinical 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 systemsClinical 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 casesOther 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,Abstracted access requirements,so farso 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 systemsAdministrative 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 modelLightweight 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 affiliationMajor 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
Minor affiliationMinor 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 exceptionsPer 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 examplesLightweight 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 issuesGroup 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 roadmapGrouper 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 v1Grouper 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 v1Grouper 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 authorizationBack 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…