Transcript IDM In Higher Education: It's About Applications

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


Ease of administration


Automate as many account creation, provisioning, and
deletion processes as possible, instrument the rest
Accuracy


All end-user applications now support single identity and
single password
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)



IDM 2.0.1 implementation (2005-2006)





AD Sync w/ Password Sync 1.0
Single eDirectory tree (main file/print/auth) syncing to a
single AD domain.
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 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…




Updates



Future-dated HR transactions (start/termination dates)
Term-tied student registration information.
Takes overlaps into account.
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.