Transcript Implementing Novell Identity Management at Drew University

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.
 Email 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 1996.
 Initially for supporting NetWare based file/print for
faculty/staff in 1996, students in 1997.
 Web-based apps began using the directory for
authentication (via LDAP) starting in 1998.
 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 2000.
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.


Support directory-enabled and non directoryenabled apps alike.



Affiliations, roles, status information.
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.




Active Directory.
GroupWise.
Driver for JDBC applications.




DREW tree.
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
[email protected]
users.drew.edu/elarsson
+1 (973) 408-3048