Implementing Novell Identity Management at Drew University - PowerPoint PPT Presentation

Loading...

PPT – Implementing Novell Identity Management at Drew University PowerPoint presentation | free to download - id: 4be326-ZTUyM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Implementing Novell Identity Management at Drew University

Description:

Implementing Novell Identity Management at Drew University E. Axel Larsson Drew University ACM SIGUCCS Fall 2005 Conference Monterey, CA Agenda. Background. – PowerPoint PPT presentation

Number of Views:156
Avg rating:3.0/5.0
Slides: 29
Provided by: E158
Learn more at: http://users.drew.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Implementing Novell Identity Management at Drew University


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

2
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.

3
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 Drews CLA became the first liberal arts
    college to include a standard computer as part of
    tuition.

4
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.

5
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.

6
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.

7
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).

8
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

9
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.

10
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.

11
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.

12
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.

13
Single-sign-on with Novell iChain (2003).
  • Single-sign-on for home grown and third party web
    applications.
  • More flexible than Drews 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.

14
Issues to be addressed.
  • Largely manual administration of accounts.
  • Unaffiliated users.
  • 4,000 accounts for lt 3,000 people?
  • Error prone.
  • Just in time provisioning
  • New hires waiting in the Telecom office.
  • Lack of support for applications that couldnt
    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?

15
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

16
Getting stuff out of AIMS isnt 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.

17
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.

18
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.)

19
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.

20
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.

21
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.
  • Theres a problem.
  • Provisioning actions occur in response to
    changes.
  • What about future events?

22
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 users 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.

23
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).

24
(No Transcript)
25
Challenges.
  • Provisioning policies dont 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.

26
The future.
  • Supplementing the meta-directory.
  • Right now, we have whats 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.

27
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.

28
Questions?
  • E. Axel Larsson
  • Enterprise Integration Specialist
  • Computing and Network Services
  • Drew University
  • elarsson_at_drew.edu
  • users.drew.edu/elarsson
  • 1 (973) 408-3048
About PowerShow.com