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 2003 - 2005) AD Sync w/ Password Sync 1.0 Single eDirectory tree (main file/print/auth) syncing to a

single AD domain. IDM 2.0.1 implementation (2005-2006)

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 AdministrativeSystem - 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 8.7.3.8 IDM Engine 3.0.1 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.