Enterprise Directories: Design, Implementation, and Operational Strategies Dr. Tom Barton

19 February 2003EDUCAUSE SW Regional 2 Copyright Statement Copyright Thomas J. 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.

19 February 2003EDUCAUSE SW Regional 3 What we’re trying to accomplish Simplify what users must know to access to online services. Enable IT organization to efficiently provide multitude of online services. Increase security. Enable online service for our constituents earlier in their affiliation with us, wherever they are, and forever. Participate in new, inter-organizational, collaborative architectures.

19 February 2003EDUCAUSE SW Regional 4 Terminology Identity: set of attributes about a person. Operationalized as a “person object”. Authentication: process used to associate a user with an identity. Often a login process. Authorization: process of determining if policy permits an intended action to proceed. Customization: presentation of user interface tailored to user’s identity. Subsumes personalization.

19 February 2003EDUCAUSE SW Regional 5 Comparative service architectures StovepipesiloStovepipe (or silo): Service performs its own authentication and consults its own database for authorization and customization attributes. service authNattributes

19 February 2003EDUCAUSE SW Regional 6 Comparative service architectures Stovepipes are run by separate offices. –Environment is more challenging to users, who may need to contact each office to arrange for service and remember several sets of credentials. –Any life cycle management of service specific resources must be undertaken by service specific office. –Per-service identifiers and security practices make it more difficult to achieve a given level of security across the enterprise.

19 February 2003EDUCAUSE SW Regional 7 Comparative service architectures IntegratedIntegrated: Suite of services refer authentication to and obtain attributes for authorization and customization from enterprise infrastructure services. Service 1 authentication service attribute service Service N

19 February 2003EDUCAUSE SW Regional 8 Comparative service architectures Enterprise authentication & attribute services are provisioned by a central office. –All attributes known by the organization about a person can be integrated and made appropriately available to services. –Automated life cycle resource management across the enterprise is facilitated. –Common identifiers across integrated services enables an easier and more secure user environment. –Lower marginal cost to implement a new service.

19 February 2003EDUCAUSE SW Regional 9 Core middleware for an integrated architecture

19 February 2003EDUCAUSE SW Regional 10 Examples Common “basket” of services: (reading & sending), calendar, shell & cluster accounts, network access services, myriad web apps, LMS, library databases, home directories,…. Remote account initialization & admitted students Academic Personnel Records –Leverages common security & data architecture

19 February 2003EDUCAUSE SW Regional 11 Identifiers Preceding slides sketched the overall technical architecture. Now we’ll dig into the identifiers that are fundamental to providing integration…

19 February 2003EDUCAUSE SW Regional 12 Source system identifiers Affiliations: –Which source systems define which major affiliations? How? –How do constituents become engaged in their various affiliations with the U? How disengaged? Associated attributes: –What other attributes of value to online services are maintained in which source systems? –How are they maintained, for what purposes? Are they reliable? Metadata: –(De-)Assignment process; persistence; visibility; versions;… –What encumbrances/obligations/policies pertain? –Updatable (in source system)? Forever iterate over these considerations

19 February 2003EDUCAUSE SW Regional 13 Registry identifiers Fundamental IDs –Permanent, unreleased guid. –Permanent pvid? –Versions? –Source join & consumer crosswalk. Derived identifiers –username(s). –Attributes for provisioning processes. –Consumer specific? Affiliations Derived. Course, program, org related identifiers & objects. Group memberships. Namespace issues Multiple namespaces? For registry objects? For consumer systems? Overloading. Format. All is hidden from view

19 February 2003EDUCAUSE SW Regional 14 Consumer identifiers Fundamental IDs –Persistence, visibility, opacity, … Potential interaction with privacy policy –Store/use pvid? –Choice of naming components (LDAP only). Representation of attributes –Application use cases –Overloading & namespace collision. E.g.s: cn: name of person, name of group, name of … uid: orthogonal sets of usernames? –Consumer specific selection & transformation All is potentially exposed

19 February 2003EDUCAUSE SW Regional 15 Service identifiers Ability to use or be provisioned with a user identifier derived in the metadirectory is a requirement for integration into this architecture. Attribute schema –Conventions for syntax & semantics Stresses on a common username space: –Least common denominator format requirements. –Number of persons assigned one (alums?, parents?, sibs?, patrons?, donors?). –Duration of assignment: forever? –Potential for shared administration of portions of username space might drive creation of orthogonal namespaces. Eg, OS usernames, uids, gids w/ nss-ldap. University “guest” registration. Username & related namespace issues

19 February 2003EDUCAUSE SW Regional 16 Stateful Provisioning

19 February 2003EDUCAUSE SW Regional 17 The Problem Unclear process for lifecycle management of accounts & other IT resources –Seat of pants policy determination Inconsistent operational practices –Done differently by different people at different times Common business logic forced to reside in applications to determine eligibility –Eg. Is this user “currently a member of community”? –Inconsistent service levels for users results.

19 February 2003EDUCAUSE SW Regional 18 Automated stateful provisioning Basic account provisioning is guided by a finite state machine. Managed resources include –shell accounts –IMAP/POP/HTTP mailbox service –campus-wide computing cluster access –variety of directory enabled application and web services that use an LDAP directory for access control, or that use the LDAP directory to determine eligibility for service.

19 February 2003EDUCAUSE SW Regional 19 States embody levels of service Provisioning profiles –Full access to basic services Faculty, staff, enrolled student – & identity management, including PIN maintenance for access to administrative web applications Accepted student, registered student –Identifiers maintained for continued support for outsourced services Alum, id retained Steps between these and oblivion –Notification of impending doom –Access denied –Resources deleted

19 February 2003EDUCAUSE SW Regional 20 Independent variables for state transitions state substate date the present state was reached date by which the present state might end (expiration date) major affiliation (faculty, staff, enrolled student, accepted student, registered student, alum, id retained) multivalued attribute holding the identifiers of resources being managed for this account.

19 February 2003EDUCAUSE SW Regional 21 Not shown: transitions to prospective state from grace, limbo, slide, IDonly.

19 February 2003EDUCAUSE SW Regional 22 Benefits Smooth over issues with feeds from source systems (grace state). Provide continuity of service to persons who temporarily drop out of source systems. –Absence from a source system need not imply absence from University community. Avoid deletion of resources for persons not in fact departed (limbo state). Organizing principle for business logic that determines provisioning.

19 February 2003EDUCAUSE SW Regional 23 Benefits Authorization policy in applications can leverage knowledge of user’s “state”. –Details of how to determine “standing” of a person from data in source systems is only instantiated once. –Administrative exceptions need only be represented once, in the metadirectory. Source of IT resource management policy. Increases value of integrated architecture (cf. “Middleware Business Case” – middleware value proposition)Middleware Business Case