Who s Who and What s What in the University

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 leonhardt@georgetown. edu

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 Brulee @ The Saloon Steakhouse

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

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

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

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

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

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

When are records updated? l Daily in batch – Record creation for new ‘traditional’ students, faculty, staff, and affiliates – Record updates and suspension for all l 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: l Public Web Searching l @georgetown. edu addresses for all l E-Mail and Calendar Address Books l Authentication and Authorization – GUMail, GUCalendar, GUNet Remote Access – Hoyasonline Alumni Community (general access for alumni and students; ‘special’ authorization in the application) l Authentication – Multiple Access+ Services (Web access to business systems) – Online One Card Services, Data Warehouse – Blackboard courseware; other Web services l Future Services – Portal, People. Soft, Others

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

Access + Alumni Services Bb 5 Server Dir DB Bb Courseware IMAP HR (2) LDAP Net. ID Database SIS Directory Search RADIUS Kerberos Alumni E-Mail Terminal Server VPN Server Dial-in Internet Connection Bb One Card People. Soft Maintenance Processes Service Requests Initial Infrastructure Deployment Calendar Data Warehouse Secure Web

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

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

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

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

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

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