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

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.


OutlineOutline

The granularization problem – use cases Lightweight authorization model Distributed groups management Heavyweight authorization


¡ ¡ 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)


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!


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 …


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


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.


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


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


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


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


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


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


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


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


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


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!


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


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


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


Simplified Grouper graphic…


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!


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


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


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…

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

Documents

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