IDM in Higher Education: It’s About Applications Mike Richichi E. Axel Larsson Drew University TTP EMEA Conference 2007

IDM Strategy and Philosophy Single sign-on  All end-user applications now support single identity and single password Ease of administration  Automate as many account creation, provisioning, and deletion processes as possible, instrument the rest Accuracy  IDM system should reflect current state of identities and entitlements Integration  Any new software or system must consume same identities from IDM system

Near Term Goals IDM system is neutral arbitrator between administrative systems and end-user applications and network environment Parts can be replaced strategically with less disruption as long as IDM linkages can be recreated effectively Reduces dependence on single vendor’s integration solutions, facilitates upgrade to best-of-breed technologies

Drew Directory Services History First NDS tree implemented 1995 (DREW— still in use today) Used as only network authentication system until 2003 Complete NOS file/print environment (drive mappings, printers, ZENworks, etc.) Always saw value of directory as centralized authentication store

Drew IDM History DirXML 1.1a (Spring )  AD Sync w/ Password Sync 1.0  Single eDirectory tree (main file/print/auth) syncing to a single AD domain. IDM implementation ( )  Add identity vault eDirectory tree.  Added interface to legacy SIS/HR system for account provisioning.  Added GroupWise driver.  Add JDBC driver and several applications (Campus Card, print accounting, etc.) Upgrade to IDM 3 (Fall 2006)

Drew’s Legacy Administrative System - AIMS AIMS - Academic Institution Management System  Deployed in the early 1980s  PICK-derived multi-value database Currently supported on IBM UniVerse on Linux  No standard SQL/ODBC access to data Graphical query capability supported by a proprietary Windows application for MV databases. Primary means of getting data in/out is by custom programmed text file dump/import.

AIMS (cont’d) Presently manages all aspects of University business and all Drew identities:  Human Resources  Admissions  Student Information  Alumni/Development (migration in progress)  Purchasing / Vendor Information Maintains a single flat identity namespace.  All modules link back a PEOPLE file. Keyed with 7-digit ID numbers for all identities.  Global PEOPLE file search facilitates non-duplication of identities when they appear in more than one module (I.e. person is a student and an employee)

Identity Vault Design Server configuration  2 SLES 9 servers  eDir  IDM Engine  iManager 2.6 eDirectory tree layout  Logically divided into two segments Person Registry / Staging Area Accounts Area

Key System Components Identity Vault  Person Registry  Accounts Area Entitlement Engine Provisioning Driver  Connects registry “side” of the ID vault tree to the accounts “side”.

Person Registry Designed to mirror AIMS identity data  Object names according to Drew ID number.  Hashed in containers by last 3 digits of ID number.  Objects may or may not correspond to active computer accounts.  Supports a complex schema Over 75 custom aux-class attributes in 6 aux classes Encompasses HR data, student information including course registration and programs, etc.

Maintenance of Registry Interface between AIMS and the identity vault.  LDAP-based, real-time updates from AIMS. Triggers installed on underlying AIMS files. Based upon existing AIMS change-tracking and auditing code. Changes aggregated to a single change-tracking table. Updates sent using ldapmodify by a daemon process that monitors the change tracking table.  Limitations One-way only (AIMS to ID vault) Only maintains a subset of identities in the ID vault.  Criteria decided by Administrative Computing department. Assumes AIMS will continue to be the primary authority for identity.

Entitlement Engine MS SQL 2000 database  Connected to Registry with the IDM driver for JDBC databases.  Solves the problem of schedule-driven entitlement changes… Future-dated HR transactions (start/termination dates) Term-tied student registration information. Takes overlaps into account.  Updates Real-time -- When entitlement affecting attrs. are updated. Nightly -- For future-dated actions.  Output - drewPersonEntitlement attribute in ID vault Provisioning driver acts upon this to create/update Registry objects in the Accounts area of the ID vault.

Applications and Directories File/print eDir tree  GroupWise driver in file/print tree Active Directory domain Uniprint print accounting (via JDBC driver) vBulletin discussion forums (via JDBC driver) Fan-out driver (for Linux account provisioning) CS Gold campus-card system (via JDBC) Mailman list manager (via UNIX/Linux bi-directional driver) -- coming soon

IDM As a Centerpiece for Migration AIMS is a legacy system Less of a question of if we replace it but how or when Raiser’s Edge project is a test case for migration strategies IDM system can’t just replicate AIMS. One possible strategy is to use IDM infrastructure as glue for best of breed apps to replace AIMS module by module Political/personal/financial issues are involved

Changing Assumptions The Raiser’s Edge project meant a change of several assumptions  AIMS isn’t in control of all identities. Identities created/maintained outside of AIMS Two-way data exchange with AIMS needed.  Wanted to preserve single-identity namespace Identities created outside of AIMS (I.e. Raiser’s Edge) will still need Drew ID numbers. Need to implement global PEOPLE file search that works across systems.

Expanding the Registry Registry will serve as the repository for the global PEOPLE search.  LDAP based search app to be built and integrated with the RE client.  Will support other apps as they are broken away from AIMS.  Need to expand registry to include all AIMS IDs: Some 500,000 PEOPLE records in AIMS

Bi-directional communication with AIMS Maintain the existing LDAP-based process for ID vault updates.  Well established. Need to minimize changes to AIMS code. Use the IDM UNIX/Linux driver and scriptable framework to facilitate updates to AIMS.  Will directly call UniVerse applications to perform updates. Best fits with Administrative Computing department’s skillsets and project timetable.  Create new IDs and update existing. AIMS PEOPLE file will remain authoritative for Drew ID numbers until it is completely replaced.

Raiser’s Edge Integration RE provides a COM-based API for integration with external apps  Supports subscription and publication  Direct database access not supported by the vendor Options we’re considering  JDBC driver to an intermediate staging DB with custom scripting to talk to RE.  Creating a SOAP web service for the RE APIs and using the SOAP shim  IDM scripting driver (if it is available in time this spring) UNIX/Linux driver scriptable framework built for Windows. Supposed to be available sometime in Spring 2007

Future Plans Discussion about future of administrative systems Success of RE project will define scope of future plans Migration to AM3 and new IDM versions will define terms and plans.