Who’s Who and What’s What in the University Directory at Georgetown Common Solutions Group Spring Meeting University of Chicago May 9, 2002 Charles F. Leonhardt

An Opening Limerick For the group that acts like a zoo This May into Chi Town we blew Two guys named Charles and Gavin Planned well the meeting we’re havin’ ‘Twas all for naught as everyone sought To peek at Mark Bruhn’s tattoo Scott Allen, Jim Bruce, Tracy Futhey, Charlie Leonhardt, Larry Levine, Joel Smith Over Crème The Saloon Steakhouse

Outline WHO: is now and is *not yet* in the directory? WHAT: attributes are in the directory for people? other objects are in the directory? WHEN: are records created, updated, suspended? WHY: are we using the directory? HOW: is the directory updated? may users control data access and privacy? The Good, the Bad, and the Ugly –Business rules in use today and those that should be

Who is in the directory? All Students: all campuses since 1998 All Faculty & Staff: all campuses since 1998 All affiliated non-employees (vendors, consultants, non-paid researchers, volunteer or sponsored faculty, retired faculty, etc.) who have requested accounts since 1999 All Georgetown Hospital (now owned by MedStar Health) employees since ,000+ Georgetown Alumni: –All campuses since 1998 –25,000+ real time NetID claims

Who is not yet in the directory? Applicants to any of the schools or programs with no other University affiliation (using Apply Yourself for graduate and professional program web-based applications) Alumni prior to 1998 –with no other University affiliation –who have not claimed a NetID online Affiliated individuals with undefined or unapproved requirements –Local community members for portal access –Others –

What attributes in the directory? Faculty, Staff, Affiliates, Hospital Staff –Name, Dept, Job Class/Title, Location, Telephone Students –Name, School, Class, Degree, Major Alumni –Name (non public unless another affiliation) For Everyone –Public/Private IDs: NetID, SSN, University ID – addresses: primary and delivery addresses –Primary and Other Affiliations –Some Application Authorizations –Display Restrictions

What attributes in the directory? Use standard LDAP attributes when possible Use GU* attributes that are specific to Georgetown –High correlation with eduPerson –eduPerson not yet implemented Some application specific attributes –For example, CT* attributes for Corporate Time

What other objects in directory? Secondary Accounts Lists Reserved Words Special Distinguished Names (DNs) Special Groups One Very Ugly Photo (DN=gettes) –many more to come for special uses 105K+ Objects in Directory Only 20% are ‘public’

When are records updated? Daily in batch – Record creation for new ‘traditional’ students, faculty, staff, and affiliates – Record updates and suspension for all Online, real time (near 24 x 7) –Record creation or reactivation for alumni and non-credit or professional development students

Why are we using the directory? Universal database for: Public Web addresses for all and Calendar Address Books Authentication and Authorization –GUMail, GUCalendar, GUNet Remote Access –Hoyasonline Alumni Community (general access for alumni and students; ‘special’ authorization in the application) Authentication –Multiple Access+ Services (Web access to business systems) –Online One Card Services, Data Warehouse –Blackboard courseware; other Web services Future Services –Portal, PeopleSoft, Others

How is the directory updated? Daily Batch –5 “balance line” programs that compare and reconcile the Enterprise Identity Management (EIM) database (aka NetID database) and the Student, HR, Hospital staff, Alumni and ‘beautiful’ Directory databases –1 program to calculate primary affiliation and assign unique identifiers (NetID, University ID) for ‘new’ records –1 “balance line” program to do two way reconciliation of NetID database and LDAP directory

NetID Database Initial Infrastructure Deployment Dir DB HR (2) SIS Alumni LDAP Kerberos RADIUS Terminal Server VPN Server IMAP Directory Search Dial-in Internet Connection Access + Alumni Services Bb Courseware Bb One Card PeopleSoft Service Requests Maintenance Processes Calendar Data Warehouse Bb5 Server Secure Web

How is the directory updated? Real Time –Alumni Claim process allows alumni (with no other affiliation) to enter their name, Alumni ID, School/Class to claim a NetID real time if they need one –Non-Credit and continuing professional education students may claim a NetID, enroll in courses, and pay by credit in real time –Both processes update the EIM or NetID database and the LDAP directory in one integrated process

How may users update data? Students –May invoke FERPA rights (or non-publish rights for ) in Student Access+ or in writing Faculty, Staff, Affiliates, Hospital Staff –May invoke non-publish rights via departmental directory coordinators (who use Access+ to change data) Alumni –May invoke publish / non-publish rights via hoyasonline; “alumni only” are non-public Everyone –May update and calendar attributes (e.g. delivery addresses)

Good Things Almost all constituents in the directory Real time creation via specialized services Basic business rules created by NetID team with minimal ‘buy in’ from process owners Biographic updates fully automated from all data sources Directory is a stable platform and able to adapt quickly to delivery of new services Conceptualized a language to standardize business rule and group processing

Bad Things Update of service delivery attributes (mail, calendar, remote access) defined well at record creation but NOT defined well for changes in status (state changes) Significant work needed to create business rules to automate status change suspension or reactivation of services Bringing the conceptual business rules / group processing language into reality has been challenging

Ugly Things Suspension of records are done by populating a ‘delete’ flag which is respected by some applications (but not integrated into ACLs) Security by obscurity is a reality until true inactivation (and reactivation) processing is in place Inactive processing is dependent upon business rules development Some service affecting attributes are updated manually for individuals with affiliation status changes

Bottom Line The Good Things far outweigh the bad and the ugly A single directory has provided a unified name space, centralized authentication, and specialized authorization services with data supported from core systems The directory is a springboard for new and innovative services including Kerberos and W2K integration (mid-term strategy is to stop using LDAP authentication)