UCB Enterprise Directory February 7, 2002

History Refresher – 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.

History Refresher – Goals Develop and implement an enterprise directory service for UCB Status: –UCB enterprise directory initial phase was implemented November 5 th, –iPlanet Directory Server, running on Solaris 450 at the CC with a replicated directory instance running on a Solaris 450 at Tele.

History Refresher – Goals Trusted, authoritative source of data Status: The Enterprise Directory blends data from SIS, HR and Uniquid using business rules, processes and policies agreed upon by campus-wide representatives.

History Refresher – Goals Identity, data and relationship management Status: –The Enterprise Directory offers a single entry per person reflecting all CU-related roles. –Identity verification using Employee ID, SID, SSN, Previous SID, Name, DOB, gender –Data population logic is based upon Steering Team- established business rules and policies –Process determines Affiliation, Primary Affiliation and corresponding privileges.

History Refresher – Goals Usable by a variety of applications and services Status: –Built upon LDAP standards, maximizing its potential for subsequent use. –Apps/services currently using the directory: White Pages (in production) Printed Directory (produced Fall, 2001 edition) address source for various applications Calendar (pilot) Affiliation Verification (local to Service Center) Radius (proof of concept) Mac OS authentication (proof of concept) Attribute load into Active Directory (as needed)

History Refresher – Goals Authentication Services Status: –Framework established based upon LDAP standards, eduPerson standards, and affiliation definition. –Solution option testing is in process

Directory Structure Today UCB Directory Registry Central (pilot) Identity Recon. Uniquid SIS H/R Directory Build Recon report White Pages (Nov.5, 2001) Authentication testing Calendaring pilot Radius concept MacOS AuthN pilot Addresses Affiliation Check Printed Directory

Directory and Data Distinct sources for distinct roles (students, employees, faculty, electronic accounts, etc.) Unique identifiers for each system Blending together to build a CU Person HR fac/staff; empID SIS student; SID FIS faculty; SSN Uniquid accounts; unix ID IDcard photos; ISO Telecom phone locn phone # CU Person

Student Data For Identity Matching: - Student ID, Previous ID - Name, Birth date, Gender For Affiliation Logic, Authorization & Data Access -Enrollment Status, Withdraw Code, Expected Return -Fees Paid Indicator -Privacy Flag For Directory Publication - Name - Local Address and Telephone - Major(s), Minor(s), College(s) - Class Level SIS Registry/ Directory (java)

Faculty and Staff Data For Identity Matching: - Employee Number, SSN - Name, Birth date, Gender PS HR Registry/ Directory For Employee and Job Selection - Job status - Employment end date For Directory Publication - Name - Campus Box and Campus Phone - Job Department(s), Home Department - Job Class Title(s) - Business Title(s) sql via db link

Campus-Specific Data or Systems Registry/ Directory Telecom Office building/room data FIS Faculty Research and Degree data ID Card ISO and jpeg Uniquid Account & data (person) (Java)

Registry person au job seealso pw cert activities research degree org unit given name surname cn job code affiliation org college major ucb exceptions campus

Registry Logic Affiliation Building - Students Enrollment status code = E Withdraw code null or Expected return date in the future Type of student affiliation is based upon Academic Unit –Student (= “Student” affiliation) –Continuing Ed Credit Student (= “Student” affiliation) –Continuing Ed Non-Credit Student (= “Affiliate” affiliation) Campus Affiliation based upon first character of AU

Registry Logic Affiliation Building - Employees Appropriate employment status code Appointment end date in the future Type of employee affiliation is based upon Job Code –Faculty, Clinical Faculty, Research Faculty, Medical Resident, Fellowship/Trainee = “Faculty” –Student Faculty = “Student” and “Faculty” –Officer/Exempt Professional = “Officer/Professional” & “Staff” –Student Employee = “Affiliate” or “Employee” –Retiree = “Retiree” or “Affiliate” –Staff = “staff” Campus Affiliation based upon first character of department code

Registry Logic Name Building LastName, FirstName MiddleName  FirstName MiddleName LastName FirstName LastName LastName FirstName Watch for II, III, IV, Jr., Sr. Remove spaces in the last name; build another variation Purpose: To facilitate name searching Build displayName use name associated with primaryAffiliation (employee = HR; student = SIS) use most current version

Directory Build Logic Find people in Affiliation Table Find corresponding records in Job Table –Select the job data related to affiliation Find corresponding records in AU Table –Select the academic unit data related to affiliation Find all other tables/data related to the affiliation people (person, name(s), , etc.) Is person in directory? –If yes, modify. If no, create Is person in directory no longer affiliated? –If so, delete from directory.

Directory cn description seeAlso sn telephoneNumber userPassword uuid au activities & research alternateContact campus degreeInstitution & Year employmentStartDate Expertise feesIndicator highestDegree homeDepartment ISO major, minor, class Privacy SID, SSN cuEduPerson organizational Person person inetOrgPerson o & departmentNumber displayName, givenName employeeNumber employeeType homePhone,homePostalAddress jpegPhoto & labeledURI mail, uid mobile & pager roomNumber userCertificate eduPerson affiliation jobClassification nickName orgDN orgUnitDN primaryAffiliation principalName schoolCollegeName facsimileTelephoneNumber ou physicalDeliveryOfficeName postalAddress street, st, postsalCode, l postOfficeBox preferredDeliveryMethod title

Directory Uses – Queries Directory Anonymous query controls: -Search based on name & variations (cn) -Server controls “max” returns (80) -Access Controls to ensure: No display of privacy-enacted students No display of employee home phone/address -Public data displayed: Student local phone/address Student major, minor, college, class Faculty/staff office phone/address, title, department address, URL Tomcat/ cocoon White Pages Address Book LDAP query Apache

Directory Uses – Applications Directory Directory and application extensions: -Authenticated application -Currently login ID and password -Moving to identikey authN, application-based authZ. - Access to directory based on application rights - Use standard directory attributes (name, ) - Extend directory attributes (preferences) - Use application-specific attributes (schedule) Cal db Calendar

Directory Uses – Authorization Directory and authorization for services/resources: - Request resource - Authenticate (you are who you say you are) - Authorize (you can do what you want to do) - Determine affiliation (faculty, staff, student, etc.) - Pass affiliation to requested service/resource - Pass additional attributes as needed by application Login server authN User Request Digital Service/Resource Directory

ID Card (ISO/jpg) Tele (bldg/rm) Directory Structure Phase 2 Data verification Birthday Message Account Mgt Project Initiate Send Mail project Sponsor Create Attribute update Radius pilot Identity Recon. Directory Build UCB Directory Calendaring pilot White Pages Registry Uniquid SIS H/R Recon report Central (pilot) Printed Directory Authentication test Authentication Implementation Central Dir. Affil Ck Addresses

Project Contacts Project Manager, Paula Vaughan Directory Manager, Melinda Jones Project Web Page or from the UCB - ITS home page (“About ITS”  “Projects & Initiatives”  “Architecture and Infrastructure Initiatives”)

Directory and Data