Enterprise Directories: Design, Implementation, and

Operational Strategies

Dr. Tom Barton

19 February 2003 EDUCAUSE SW Regional 2

Copyright Statement

Copyright Thomas J. Barton, 2003. 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 2003 EDUCAUSE 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 2003 EDUCAUSE 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 2003 EDUCAUSE SW Regional 5

Comparative service architectures

• StovepipeStovepipe (or silosilo): Service performs its own authentication and consults its own database for authorization and customization attributes.

service

authN attributes

19 February 2003 EDUCAUSE 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 2003 EDUCAUSE 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 1authenticationservice

attributeservice Service N

• •

•

19 February 2003 EDUCAUSE 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 2003 EDUCAUSE SW Regional 9

Core middleware for an integrated architecture

19 February 2003 EDUCAUSE SW Regional 10

Examples

• Common “basket” of services: email (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 2003 EDUCAUSE 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 2003 EDUCAUSE 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 2003 EDUCAUSE 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 2003 EDUCAUSE 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 2003 EDUCAUSE 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 2003 EDUCAUSE SW Regional 16

Stateful Provisioning

19 February 2003 EDUCAUSE 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 2003 EDUCAUSE 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 2003 EDUCAUSE SW Regional 19

States embody levels of service

• Provisioning profiles–Full access to basic services

• Faculty, staff, enrolled student

–Email & 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 2003 EDUCAUSE 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 2003 EDUCAUSE SW Regional 21

Not shown: transitions to prospective state from

grace, limbo, slide, IDonly.

19 February 2003 EDUCAUSE 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 2003 EDUCAUSE 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)