Implementing Novell Identity Management at Drew University E. Axel Larsson Drew University ACM SIGUCCS Fall 2005 Conference Monterey, CA

Agenda. Background. The evolution of Directory Services at Drew. Challenges – The need for a real identity solution. The formation of identity management project. Technical implementation overview. Remaining obstacles. The future.

Drew in Brief. Located in northern New Jersey. 2,200 FTEs (faculty, staff, and students). Three schools: College of Liberal Arts. Theological School. Graduate School. The Computer Initiative: In 1984 Drew’s CLA became the first liberal arts college to include a standard computer as part of tuition.

Computer Initiative impact on University Technology. The CI encompassed the entire CLA. Centralized IT support developed around the CI. All services centralized. No individual departmental support. No fragmentation. User expectation of centralized services and support. Seamless and consistent user experience. Standard desktops. One login, one password for everything.

University Technology at Drew. Administrative Computing (5 FTEs): Student Information System. Human Resources. Financials. Computing and Network Services (16 FTEs): Helpdesk, computer store, computer deployment. All systems administration. Campus networking. Directory services and authentication. and other enterprise applications. Telecommunications.

University Technology at Drew. Instructional Technology Services (9 FTEs): Faculty development, faculty technology lab. Staff development, staff technology lab. Student computer training. Media resources and classroom support.

Supported platforms. PC Support: Windows clients only for full support. Limited support for Macs, Linux systems, etc. Server platforms: Windows. NetWare. Linux (SuSE and RedHat).

Administrative computing system. The Academic Institute Management Systems (AIMS): Legacy PICK (MultiValue) system. Installed in the early 1980s. Very few remaining customers. Limited connectivity and integration options.  IBM UniVerse database provides a JDBC driver.  Requires significant database changes. Considered impractical to implement.  Proprietary Windows query tool. (MVQuery)  Not useful for back-end integration.  Flat text files… Custom code…

Directory Services and identity at Drew (before 2003). Novell eDirectory (formerly NDS): First NDS tree (DREW) created in Initially for supporting NetWare based file/print for faculty/staff in 1996, students in Web-based apps began using the directory for authentication (via LDAP) starting in ATTIC – Home grown directory enabled course management.  First app at Drew to take advantage of identity information in the Directory. Session Manager – Home grown web single-sign-on in ZENWorks Application Launcher – directory enabled application distribution.

Active Directory rollout (late 2002). Needed to support authentication for Windows XP workstations. Previously had skipped Windows NT/2000 for the most part. Win9x only. No workstation account issues, ZENWorks Dynamic Local User was too limiting. Desired to retain eDirectory as the primary campus directory. Sync eDir and AD. Existing investment in home grown account management tools and procedures. User convenience. Single password for AD and eDir. Most apps on campus would continue to use eDir.

Active Directory rollout (late 2002). First attempt with Novell Account Management 3 (NAM 3): Designed for one way sync only for accounts and groups. Bi-directional password sync. “Fan-out” design. Account sync to many individual systems without individual configuration. Many components. Moderately complex configuration. Insufficient flexibility.

Active Directory rollout (late 2002). DirXML 1.1 driver for Active Directory. Single server deployment. Installed eDir on one of the Windows DCs with DirXML. Very flexible policies. Somewhat complex if you need to do anything unusual. (XSLT code) Bi-directional data and password synchronization. We did bi-directional password sync but eDir remained authoritative for accounts and groups. Very reliable – almost zero unplanned downtime for over three years.

Single-sign-on with Novell iChain (2003). Single-sign-on for home grown and third party web applications. More flexible than Drew’s home grown Session Manager application. Reverse proxy based, non-invasive integration. Supports basic auth, HTTP header auth, forms based auth. First implemented to support SSO to Blackboard 6 Basic Edition. Completely replaced home-grown solution by Summer 2004.

Issues to be addressed. Largely manual administration of accounts. Unaffiliated users. 4,000+ accounts for < 3,000 people? Error prone. “Just in time” provisioning… New hires waiting in the Telecom office. Lack of support for applications that couldn’t use the existing directories as an identity store. Breadth and freshness of data in the directory. Limited attributes added when accounts were created. Manual role assignments and changes. How do we keep this data up to date?

Supporting applications. Everything needs identity data. Course Management (Blackboard, etc.). Helpdesk (customer database). Campus card system. Library. Portal. … and many more. Where do we get this data from? AIMS (HR and SIS). Identity is 95%+ of what we need…

Getting stuff out of AIMS isn’t easy… Inefficiencies Lots of flat text files. Not real time. Duplicated work. Slow to develop. Non-technical issues Lack of transparency. Bureaucracy. Turf. Result Frustration. Stalled projects.

What do we need? Fix account management. Automated provisioning based upon policies. Support applications better. A more complete directory with fully specified people. Affiliations, roles, status information. Support directory-enabled and non directory- enabled apps alike. Connectors to a variety of directories, databases, and application specific APIs. Do it in real time. Do it more efficiently.

The project. Build a University meta-directory. Support standard (inetOrgPerson, eduPerson) and Drew specific schema. This becomes the central identity repository. Only one bridge to AIMS. Do it once.. Do it right. Develop an application to manage accounts and roles. Apply business rules to identity data and make provisioning decisions. Support real-time and scheduled actions. Connect the meta-directory to other directories and non-directory applications. Production eDirectory tree. Active Directory domain. Application specific databases. (Helpdesk, etc.)

Drew meta-directory. Central repository for all identity data. “Identity Vault” – The Novell term for a central meta-directory. Using Novell eDirectory (8.7.3) Separate from the enterprise file/print/auth tree. Novell Identity Manager 2 (DirXML) to connect the Identity Vault to the other enterprise directories and apps. Synchronization “hub” for other applications and directories. Client apps do not access it directly.

Connecting the meta-directory to AIMS. Do it once. Do it right. IDM system will replace all of the individual integrations that had been built between AIMS and other software. Real-time updates of HR and Student data to the meta-directory. Hooks into existing AIMS auditing code. Uses LDAP to push changes to eDirectory. AIMS auditing code outputs LDIF. OpenLDAP Project slurpd program pushes changes to eDir.

Automating account and role provisioning. Novell Identity Manager support for role- based provisioning. Policy Builder – Script provisioning actions in response to changes in the directory. Role-Based Entitlements – Assign entitlements based upon the state of attributes on a user. Recomputed automatically when changes occur. There’s a problem. Provisioning actions occur in response to changes. What about future events?

The Entitlement Engine. A home-grown MS SQL Server application for managing entitlement policies. Connected to the meta-directory with an Identity Manager driver. Subscribes to: Changes to meta-directory attributes that affect entitlement. i.e. Hire/Term dates, Course Registrations, etc. Publishes: A single mutli-valued attribute that specifies a given user’s entitlement for accounts and roles. Other IDM policies act in response to changes to this attribute to create, delete, enable, disable, or change group memberships for accounts. Caches information about entitlement time spans. Emits “synthetic events” for future dated items.

Provisioning accounts in and providing identity data to campus systems. Novell Identity Manager drivers connect the meta-directory to all other campus systems. eDirectory. DREW tree. Active Directory. GroupWise. Driver for JDBC applications. CS Gold (Campus card system). Helpdesk (Hornbill Supportworks). vBulletin (discussion boards). Text files. Sirsi Unicorn (Library system).

Challenges. Provisioning policies don’t cover every case. Unregistered students. The Adjunct Faculty problem. Sponsored accounts. Workarounds. Wide grace periods. Advance notification. Failure to keep records up to date now has real consequences. Short term pain, long term benefit.

The future. Supplementing the meta-directory. Right now, we have what’s in AIMS. AIMS SIS is mostly sufficient. HR is very lacking.  Too many assumptions, workarounds, in provisioning policies. Allow HR staff to provide the missing data directly to the directory service. User self-service applications. User created groups and roles.

The future. Supporting “public” web applications. Customized portal apps for perspective student, admitted student, alumni, parents, and friends of the University. Identity infrastructure to support these apps. New eDirectory tree to support iChain (web application) authentication.  Drew “uLogin” accounts.  External identities. Self service account creation and password reset. Associating web identities with real Drew IDs (admitted students, alumni). Identity lifecycle – Perspective, Admitted, Enrolled, Student, Alumni.  Seamless transition of identity information.

Questions? E. Axel Larsson Enterprise Integration Specialist Computing and Network Services Drew University users.drew.edu/elarsson +1 (973)