IDM in Higher Education: It’s About Applications Mike Richichi E. Axel Larsson Drew University TTP...
-
Upload
mauricio-hedley -
Category
Documents
-
view
216 -
download
0
Transcript of IDM in Higher Education: It’s About Applications Mike Richichi E. Axel Larsson Drew University TTP...
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