life after implementation on-going directory management and governance sharing experiences jon...

Life After ImplementationLife After Implementation

On-going Directory Management and GovernanceOn-going Directory Management and Governance

Sharing ExperiencesSharing Experiences

Jon GiltnerDirector of IT Architecture and Security

Information Technology ServicesUniversity of Colorado at Boulder

[email protected]

CAMP Directory Workshop Feb 3-6, 2004

AgendaAgenda

CU Directory Project Background Directory Governance Directory Management Open Discussion / Q & A


University of Colorado SystemUniversity of Colorado System

www.cu.edu

www.colorado.edu

www.cudenver.edu

www.uccs.edu

www.uchsc.edu


University of Colorado SystemUniversity of Colorado System

CU System Office– Four campus PeopleSoft HR and GL System– Four campus Student Information System (Mainframe

Application)– Four campus Data Warehouse (Oracle DB)

Each Campus– Central IT Department– IT Governance varies– Numerous departments with autonomous IT staffing –

“voluntary” coordinated governance.


January 2000 – Launch of January 2000 – Launch of Directory Services ProjectDirectory Services Project

Motivated By:– Strong ties to Internet2, and specifically the I2 Middleware Initiative– Applications needing LDAP services starting to appear on campus– Unsatisfactory existing on-line white pages– Data distribution from PS and SIS getting unmanageable– Convergent vision of senior IT managers (effective evangelism or maybe just

astrological planetary alignment)

Solidified By: President Hoffman’s Vision 2010– Five Axioms:

A University Without Walls - enabling a multidisciplinary effort across all four CU campuses. A Culture of Excellence - targeting areas for national prominence on each of the four campuses. Increasing resources and using them wisely - building significant endowments for scholarships, chairs

and professorships. Diversity - bolstering diversity through aggressive recruitment and retention strategies for students,

faculty and staff. An integrated infrastructure - using technology to enhance the quality of services to CU

constituents across the entire system, and to expand online degree programs.

A Boulder campus initiative w/ cooperation from other campuses (esp. CU System)


CU Directory Services ProjectCU Directory Services ProjectProject goals:

– Trusted, authoritative source of data– Identity, data and relationship management– Usable by a variety of applications and services– Authentication services (LDAP AuthN via Kerb V pass-through

module)– Foundation for campus-wide AuthN and AuthZ services

Project commissioning statement:

Establish a framework for deploying and maintaining general purpose directory services for the University of Colorado at Boulder within the context of the University-wide environment.


Project StructureProject Structure

Big “Team”

ChampionPolitical conduit. Sustains momentum.

Steering Team

Key decision-makers. Communication thru monthly

meetings Technical Team

Provides analysis, design, development, testing.

Core Team

Provides detailed project work & conducts regular meetings

•Registrar•Mgr CU Benefits Svcs•Dir. of Housing•IT Architect•Director of HR•Asst. VP UMS•Dir. ITS•Dir. Enrollment Management•Dean of Libraries


November 2001 – Boulder Campus Directory November 2001 – Boulder Campus Directory Goes LiveGoes Live

Success Factors1. Decision that it is not a technical project – lead with policy and process issues

and establish on-going directory governance.2. Involvement from broad set of constituents 3. Leverage best practices and lessons learned from others (I2 MACE-Dir, The

Burton Group).4. Small initial implementation scope / Massive implication scope (see 1 & 2)

Measures of Success1. Technical & administrative silos engaged, not threatened.2. Representatives from all hierarchies ask to learn more.3. Community members ask to be involved.4. Application owners ask to use directory.5. Directory praises sung on the campus grapevine.

Small Hammers: Directory Policy and Identity Management Policy


Project TimelineProject Timeline

Jan 00 Jan 02

Project Commissioned;Goals Defined

Project Core Teamformed

Interviews;Requirements Defined

Project Steering Teamformed

Design andDevelopment

Technical and Policy Development

Fine Tune; Pilot; Fine Tune; Pilot;

Fine Tune!

Nov 5, 2001Go Live!

Jon BecomesCU Employee


Basic Directory ArchitectureBasic Directory Architecture

dc=colorado, dc=edu

CoreTeam

SteeringTeam

CampusSMEs

BusinessRules

SIS HR

4-CampusRegistry

(Oracle DB)

Eg. dc=cudenver, dc=edu

(SunONE Directory)


Other Boulder Campus DirectoriesOther Boulder Campus Directories

Registry

ad.colorado.edu

HR

SIS

Sponsored

MetaMerge

Campus Directory

Calendar Instance

OS X Instance


(OK, A Little Reality)(OK, A Little Reality)

Distinct sources for distinct roles (students, employees, faculty, electronic accounts, etc.)

Unique identifiers for each system Blending together to build a cuEduPerson

HRfac/staff;

empID

SISstudent;

SID

FISfaculty;

SSN

Uniquidaccounts;

unix ID

IDcardphotos;

ISO

Telecomphone locn

phone #

cuEduPersonuuid

SponsoredAffliate;

SSN?


CU Directory Project SummaryCU Directory Project Summary

Boulder campus project with some 4-campus scope

Goal from outset was to be an authoritative source of identity data for a wide variety of applications

Steering team established to make hard decisions relating to use and manipulation of data

Managed to succeed without Jon


AgendaAgenda



Directory Governance ScopeDirectory Governance Scope

Jon’s Postulate:

Directory Governance = Enterprise Identity Management

(At the Policy Level)


Project Steering TeamProject Steering Team

Established early during implementation to address issues such as:– Data precedence / reconciliation– Affiliation (role)– Visibility of data beyond FERPA– Appropriate uses of data– Giving the project clout (example: incremental

updates from PS and SIS)– Championing across University

Challenge: Thinking bigger than “white pages”


Steering Team Member CriteriaSteering Team Member Criteria

Policy maker at the campus or University level

AND / OR

Knowledge expert in how the University conducts business (non technical)


Issue: AffiliationIssue: Affiliation

Affiliation describes an individual’s relationship with the university.

Affiliation is used for two primary purposes:

To determine whether services

should be granted to the user (check performed via a directory-enabled system)

To determine what information should be displayed and/or made public for the individual associated with the entry.

Affiliation

DISPLAY/QUERY

Admitted Student Confirmed Student Parent?

Student Staff Faculty Student Employee Retiree

Employee Spouse Alum Sponsored

vendor? contractor? visiting faculty?

Directory-onlyConference Attendee

SERVICE


More on AffiliationMore on AffiliationThe primary factor for determining access entitlements are a person’s

affiliations with the University. Affiliation (i.e. Role) is determined from a combination of directory attributes:

eduPersonAffiliation – Multi valued; Controlled Vocabulary

eduPersonPrimaryAffiliation – Single value; Controlled Vocabulary

cuEduPersonCampus

cuEduPersonHomeDepartment (faculty / staff)

cuEduPersonMajor (student) (also minor and class)

description – Multi valued; “predictable” values


Affiliation/Services MatrixAffiliation/Services Matrixdir list

email idkey lab AD modem dhcp Webhost

acct ememo library idcard RTD recctr other special conditions

ContEd noncredit[1]

no no no no[2] no no no? no? no no yes[3] no[4] no[5] yes PLUS;web ct[6]

current enrollment

campus ministries

no yes/no yes/no

no no yes/no yes/no

yes/no

no no no yes no no special id card

clubs/orgs[7] no yes/no yes/no

no no yes/no yes/no

yes/no

no no no no no yes ucsu-reg if stdent org. Expire date

conference attendee[8]

no yes/no yes/no

yes/no[9] yes/no

yes/no yes/no

no no no yes yes[10] no yes web CT, wshc

short term service

vendor/contractor no yes/no yes/no

yes/no yes/no

yes/no yes/no

no no no no yes/no(special)

no no svcs vary by ven.; expire per vendor.

CU Agency list[11]

yes/no

yes/no yes/no

yes/no yes/no

yes/no yes/no

yes/no

no yes/no yes/no

yes/no no yes/no

alumni no (addr) no no no no no no no no yes[12] no no yes[13] PLUS

Foundation Staff yes no no no no no no no no yes yes yes no yes


Issue: Directory PolicyIssue: Directory Policyhttp://www.colorado.edu/its/directoryservices/documents/policy.html

Establishes

– Directory Governance ;

– Official Data Sources (the information systems from which the Directory will extract its data, create entries, and update entries, and upon which it will base its reconciliation) ;

– Directory Inclusion (categories of people who will be included in the CU-Boulder Directory) ;

– Directory Use (privacy requirements; who may have authenticated access to the Directory; who may pull data from the directory and for what purposes; and who must use the Directory)


Policy: Mandatory UsePolicy: Mandatory Use

Mandatory Directory UsageAll CU-Boulder campus-specific systems implemented after the advent of the Directory must be directory-enabled if affiliation-check, authorization or enterprise data is required by the newly implemented campus system. “Directory enablement” means using the Directory for determining affiliation, authentication, authorization, or for data reference.


Steering Becomes GovernanceSteering Becomes Governance

Post-deployment Issues

– Prioritization of new development (if needed)

– Review data use requests and requests for new data (eg. Class photo rosters)

– End-user (application) access to Registry database

– But mostly: Identity Management


Identity Management PolicyIdentity Management Policy

Establishes

– Trusted sources of identity data ;

– “Sponsored” affiliation type ; (Note: difference from “sponsored” identity)

– Acceptable protocols for managing identity data ;

– Triggers for removal of identity ;

– Operational procedures related to identity


Identity ManagementIdentity Management

Other Identity Management Issues Contemplated by the DGB:

– “Local” vs. “Enterprise” identity data: application specific extensions to the directory

– Groups, roles, and delegated administration

– Services for expanded sets of affiliates: e.g. applicants and retired faculty

– Non person identities


Governance: What’s AheadGovernance: What’s Ahead

More and Bigger Identity Management Issues:

– Reversing the data flow: getting new or changed directory data back into source system

– Large classes of potential service consumers who aren’t in source system: Alumni (vanity e-mail address), Former Students (transcript requests), Faculty/Staff Spouses (calendar viewing)

– Better processes for removing/changing affiliation (Which can have a profound effect on access to services).

– Multi-campus identities and federated management between campuses and external to the University


What We Would Do DifferentlyWhat We Would Do Differently

A Mistake:

– The DGB does not have any direct control over funding


Governance SummaryGovernance Summary

Early is good; Elevates important issues out of technical realm

Ensure authority to establish policy and generate action by including those who already have authority

Embrace Massive Scope of Identity Management


AgendaAgenda



Management?Management?

Is it a product, a project, or a mature, operational service?

– No opportunity to have controlled releases

– No finite set of objectives

– Minimal ability to create a routine “service fulfillment” process


Management vs. OperationsManagement vs. OperationsOperations

– Monitoring for availability and performance

– Backups and replication

– Log file monitoring

– Deal with exceptions generated during various load processes (may require escalation)

– Upgrading and patching software and platform components

Management

– Prioritization and oversight of directory related projects

– Primary interface to DGB

– Consulting with customers

– Policy compliance

– Data stewardship

– Communication and promotion

– Contribute to, but not ultimately accountable for, strategic positioning and architecture


Directory Management PitfallsDirectory Management Pitfalls

By nature, it becomes reactionary

– Source systems or data subject to change due to drivers unrelated to the directory or identity management

– New laws and regulations to comply with

– Requests for new data or new uses of data come with twists and at a rate much faster than the DGB can properly address them

– Multiple competing business drivers make prioritization difficult


The Solution: Pass the BuckThe Solution: Pass the Buck

Use the DGB for prioritization when appropriate

Make it the duty of the DGB to resolve even tough issues in a timely manner

Integrate authN/authZ tools with delegated administration into directory services: e.g. commercial identity and access management software

The Directory is too flexible a framework: Build a Portal; or even two


Oh Yeah, and a Competent ManagerOh Yeah, and a Competent Manager

Job requirements:

– Ability to fully grasp complexities of the data and systems involved

– Ability to influence DGB

– Skilled project manager

– Skilled customer manager

– Willing to carry the weight of the world

And try not to burden with a lot of operational details


Management: What’s AheadManagement: What’s AheadLaundry List of Projects from our

Directory Manager

faculty welcome basket – rosters, course lists, key requests, ITS account requests, etc.

ISO number included for business school integration self-update birthday message add physical location to dir directory-enable legacy applications –

– athletics ticketing– faculty information system– ASPupload– mailing services– iVote– parking services– housing– norlin– rec center– wardenburg– math mods– applied math

replace Metamerge sponsored entry – individual and batch entry direct update to AD directory-enable email for life directory-enable account (de)provisioning process on-going involvement: WebCal, WebCT,

cuConnect, IFS, EFL, Account provisioning grace periods / deprovisioning multiple uuid programming – correct duplicate

entries dir-enable chinook electronic reserves integrate UCD integrate CS, HSC employee privacy policy more robust directory logging and stats include departmental listings in directory develop archiving plan email / send mail system registration ? printed directory


What We Would Do DifferentlyWhat We Would Do Differently

Better separation of directory management and operations functions. Clearly defining role of Directory Manager.

(We are in the process of fixing this)


Directory Management SummaryDirectory Management Summary

Management and Operations are different functions

Understand the importance of having a good directory manager and keeping the DGB engaged

Directory management issues are often identity management issues. Address the source of the issue.


AgendaAgenda


life after implementation on-going directory management and governance sharing experiences jon...

Documents

camp directory workshop

cu system slide

ldap services

cu campuses

quality of services

cu constituents

campus central

gl system