White Papers Identity Manager Product Literature Identity Manager White Papers
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Large Scale User Provisioning with Hitachi ID Identity Manager

arrowAbstract
This document introduces the business problems of user life-cycle management: slow and complex onboarding; redundant administration effort; slow and unreliable deactivation; excess security entitlements and inconsistent user profile data. It then describes how Hitachi ID Identity Manager addresses these problems using streamlined business processes built on integrated technology. Finally, the benefits of enabling automation and self-service to improve user and security management processes are described.

Introduction

This document introduces the business problems of user life-cycle management: slow and complex onboarding; redundant administration effort; slow and unreliable deactivation; excess security entitlements and inconsistent user profile data. It then describes how Identity Manager addresses these problems using streamlined business processes built on integrated technology. Finally, the benefits of enabling automation and self-service to improve user and security management processes are described.

Identity Manager is the user provisioning component of the Hitachi ID Identity and Access Management Suite.

The remainder of this document is organized as follows:

Business Challenges in Identity and Entitlement Management

Several factors combine to make management of users and their security entitlements a growing challenge for many organizations:

This complexity is illustrated in Figure [link].

figure

    Managing Each Application in its own Silo (1)

The impact of this complexity is straightforward business problems:

Shared Infrastructure for Identity Management

To resolve the business problems that arise from the complexity introduced in Figure (_label_fig:silo-processes), it makes sense to implement a shared infrastructure for managing users and security entitlements. This is illustrated in Figure [link].

figure

    Externalizing the Management of Users and Entitlements (2)

Using this approach, the links that connect every process to every system are severed, replaced with links between each process and a shared IDM system, plus links between that system and each integrated application. If before there were N processes, M applications and N x M links (chaos!), now there are just N + M links -- much more manageable.

A shared infrastructure for users and entitlements can take on different forms, each of which has merit and all of which can be combined.

Shared user directory (LDAP)

The first approach to consolidating identity and access management -- removing this function from application silos and moving it to a shared infrastructure -- is to use a directory. Applications should then be configured to externalize user identification, authentication and authorization information to the directory.

This approach has merit, hence the popularity of LDAP. It also has limitations:

Because of these limitations, LDAP has helped to slow the proliferation of user databases but organizations still have multiple systems to manage.

Shared management layer (IDM)

Where the physical user directory cannot be consolidated, it makes sense to at least consolidate the processes that create, modify and delete users and entitlements on multiple systems. This is the function of a user provisioning system -- to implement consistent processes which manage users and entitlements across multiple, heterogeneous directories of users and entitlements.

Identity Manager is designed to provide a shared set of processes and infrastructure to manage users and access across heterogeneous systems. It implements multiple processes that an organization can use to provision, update and deactivate user access to multiple systems.

Streamlined User and Entitlement Management Processes

User life-cycle

User movement through an organization is referred to as the user life-cycle. The processes involved vary from one classification of user to another and sometimes from one individual to another. For example, employees and contractors typically have different life-cycles. The process is referred to as a life-cycle, to emphasize that users who have left an organization may later return. The user life-cycle is illustrated graphically in Figure [link].

figure

    User Lifecycle Management (3)

In the context of an identity management system, the user life-cycle has external inputs and observable outputs. Inputs are typically business events: hire an employee or contractor, change departments, terminate a user, etc. Outputs are the changes made on integrated systems and applications to reflect changing needs: create a login ID, disable a login ID, add or remove security entitlement, etc.

Every user life-cycle begins with an on-boarding event -- a new-hire for employees, start-of-engagement for contractors, sign-up for customers and partners, enrollment for students, etc. This business event triggers creation of one or more login accounts and other objects for the user in question.

Over time, users will make routine password changes and may periodically forget or lock out their passwords, leading to a need for IT support (password reset or clear lockout).

As users move through an organization, they may change job functions, projects, locations, etc. These business events often trigger the need for changing access rights. In other words, their access rights need to be managed over time.

All users leave eventually and their access rights must be deactivated. In many cases, objects belonging to the user -- home directory with files, mail folder with archives messages, etc. -- may have to be retained for a period of time before they are permanently deleted. Some data about users, such as their unique identifiers, and whether it is OK to re-hire them, may be retained indefinitely, for future reference.

In some cases, a user who has departed will return to the organization and need to be re-activated, hence the cycle in the user life-cycle.

Without automation, each of the above processes is handled separately, with no link between processes and with unique processes implemented for each system and application, managed by different IT staff, using different access administration tools. This is what leads to the complexity illustrated in Figure (_label_fig:silo-processes).

Business Processes

Identity Manager implements several types of business processes when managing users:

Integrations and Manual Fulfillment

Once a business process has produced a change that should be applied to an application, one of several processes should push the change to the system in question. There are three ways to do this -- use a built-in connector, use a scripted integration or ask a human being to make the change.

Built-in Connectors

Identity Manager comes with built-in connectors for most common systems and applications, as illustrated in Figure [link].

(4)

Directories:

Servers:

Databases:

Any LDAP, AD, NDS, eDirectory, NIS/NIS+.

Windows 2000--2012, Samba, NDS, SharePoint.

Oracle, Sybase, SQL Server, DB2/UDB, ODBC, Informix.

Unix:

Mainframes:

Midrange:

Linux, Solaris, AIX, HPUX, 24 more variants.

z/OS with RAC/F, ACF/2 or TopSecret.

iSeries (OS400), OpenVMS.

ERP:

Collaboration:

Tokens, Smart Cards:

JDE, Oracle eBiz, PeopleSoft, SAP R/3, SAP ECC 6, Siebel, Business Objects.

Lotus Notes, Exchange, GroupWise, BlackBerry ES.

RSA SecurID, SafeWord, RADIUS, ActivIdentity, Schlumberger.

WebSSO:

Help Desk:

HDD Encryption:

CA Siteminder, IBM TAM, Oracle AM, RSA Access Manager.

BMC Remedy, BMC SDE, ServiceNow, HP Service Manager, CA Unicenter, Assyst, HEAT, Altiris, Clarify, Track-It!, RSA Envision, MS SCS Manager.

McAfee, CheckPoint, BitLocker, PGP.

SaaS:

Miscellaneous:

Extensible:

Salesforce.com, WebEx, Google Apps, MS Office 365, SOAP (generic).

OLAP, Hyperion, iLearn, Caché, Success Factors, VMWare vSphere.

SSH, Telnet, TN3270, HTTP(S), SQL, LDAP, command-line.

 

    Target system types supported by Identity Manager (5)

Scriptable Connectors

(6)Identity Manager includes a number of flexible connectors, each of which is used to script integration with a common protocol or mechanism. These connectors allow organizations to quickly and inexpensively integrate Identity Manager with custom and vertical market applications. The ability to quickly and inexpensively add integrations increases the value of the Identity Manager system as a whole.

There are flexible connectors to script interaction with:

API binding:

Terminal emulation:

Web services:

Back end integration:

Command-line:

  • C, C++
  • Java, J2EE
  • .NET
  • COM, ActiveX
  • MQ Series

  • SSH
  • Telnet
  • TN3270, TN5250
  • Simulated browser

  • SOAP
  • WebRPC
  • Pure HTTP(S)

  • SQL Injection
  • LDAP attributes

  • Windows
  • Power Shell
  • Unix/Linux

 

Organizations that wish to write a completely new connector to integrate with a custom or vertical market application may do so using whatever development environment they prefer (J2EE, .NET, Perl, etc.) and invoke it as either a command-line program or web service.

If Hitachi ID Systems customer develops their own integrations, an effort of between four hours and four days is typical. Alternately, Hitachi ID Systems offers fixed-cost custom integrations for a nominal fee.

Implementer Workflows

Identity Manager supports the notion of an "implementer-style" target system, where a human system administrator is asked to create, modify or delete a user object on the target system, in place of an automated Identity Manager connector.

Implementer-style target systems are useful in two main circumstances:

  1. A custom or vertical-market target system either has a very small or very static user population. In these cases, the level of effort required to deploy automated integration to manage users on the target system (typically on the order of several days) is not warranted given the small pay-back.
  2. There are many target systems (hundreds, thousands) in-scope for the project and it is desirable to give users a "one stop shop" experience for security change requests, using Identity Manager, at the start of deployment. This is preferable to asking users to refer to different request systems depending on what kind of access they require.

Identity Manager Technology

Auto-Discovery

(7) Identity Manager includes an auto-discovery engine, which typically extracts information about users and groups from target systems nightly.

Auto-discovery is incremental on systems that support this -- such as Active Directory and most other LDAP directories. A full extract is produced on systems where incremental listing is not supported, and a delta is calculated on the Identity Manager server before being loaded into the Identity Manager database.

ID Mapping / Reconciliation

Every enterprise identity management and access governance system, regardless of its features, must support login ID reconciliation. Users have login accounts and other records on various systems and these have to be attached to a single profile, in order to create a user-centric identity system. The process of attaching non-standard login IDs and other user identifiers to a single profile is called login ID reconciliation.

Identity Manager supports multiple options for login ID reconciliation, as follows:

When self-service login ID reconciliation is required, it works as follows:

Self-service reconciliation is inexpensive (about 5 minutes per user), reliable, fully automated (users are reminded to register until they actually do) and very secure.

Both self-service and administrative login ID reconciliation are logged. Other forms of login ID reconciliation are typically batch oriented and can be configured with logging if required.

Note that attempts to reconcile login IDs by matching on attributes of user profiles on target systems are often costly and/or insecure, especially when combined with a password management system:

Where self-service login ID reconciliation is required, the process is both inexpensive (25,000 users spending 5 minutes each costs nothing, while one consultant spending weeks or months is expensive) and error-free (since IDs are claimed with a validated password). This process is, to the best of Hitachi ID Systems knowledge, unique.

Unique Approach to Workflow

Identity Manager's workflow automation engine streamlines the process of requesting and authorizing the creation of new accounts, as well as other security changes such as adding/removing group membership, changing attribute values, renaming or moving accounts, deleting or deactivating accounts and so on.

The Identity Manager workflow engine accepts change requests from the Identity Manager web portal, the Identity Manager web services API or the auto-provisioning engine. Its main task is to validate change requests and manage authorization of changes by business users, who are invited to review requests via e-mail and provide approval via the web portal.

Workflow in Identity Manager is loosely coupled, in the sense that request input (API, automation, web portal) is separated from form validation, which in turn is separated from authorizer selection and related logic, which is separated from the process used to invite participants to respond to a change request. This loosely coupled architecture significantly simplifies configuration and maintenance by encouraging code reuse.

The workflow automation engine works as follows:

The built-in workflow engine is designed to get quick and reliable feedback from groups of business users, who may be individually unreliable. It supports:

Role Based Access Control and Segregation of Duties

Identity Manager includes a complete infrastructure for managing user entitlements using role based access control (RBAC).

(8)Identity Manager includes what is probably the most advanced segregation of duties (SoD) engine available. The Identity Manager SoD engine supports:

User Classes: Sets and Relationships

Identity Manager includes a mechanism for classifying users -- individually or as they relate to one another -- called user classes.

When applied to individual users, user classes can examine a user's accounts, identity attributes or security group memberships to decide whether a user is in a given class. For example, help desk users may be members of an Active Directory group called it_support. Linux administrators may be in an LDAP OU called ou=Admins and be members of an AD group called linux_experts.

User classes can also formalize relationships between users. For example, an organization may have a regional IT support model, such that a given help desk user can only provide assistance, such as password resets, to users in his region. This is supported by defining user classes that relate two users -- for example, the "helpdesk" user must be a member of an AD group called it_support and both users must have the same values in the Division and Country-Code attributes.

User classes have multiple uses:

  1. They are used in the Identity Manager operational security model, to assign rights for managing Identity Manager to users.
  2. In the delegated user administration security model, they determine what a given user can do on behalf of another given user.
  3. They are used to place users into Identity Manager user groups, which in turn are assigned access rights to managed systems.
  4. They are used to select users who will be invited to approve requests for exceptional access.
  5. They are used in the Identity Manager access control model, to determine who can see and who can modify what identity attributes, on whose profiles.
  6. They are used to select users who will be invited to approve requests for changes to user profiles or entitlements.
  7. They can be used by automated provisioning logic, to automatically assign roles or groups to users.
  8. They can be used to segment access certification rounds, by deciding which certifier should review which users and entitlements.

Network Architecture

Identity Manager is designed for:

Figure [link] illustrates the Identity Manager network architecture:

figure

    Network architecture diagram (9)

High-Performance, High-Availability Database Architecture

All Identity Manager components, including user interface screens, reports, service programs and command-line / batch processes access the database using the same architecture:

  1. A client component calls a client wrapper library.
  2. The client wrapper library communicates with a Identity Manager database service using an IPC. This may be shared memory (same server, very fast) or TCP/IP socket (remote server, encrypted communication using a shared key).
  3. The Identity Manager database service authenticates clients, checks what they are allowed to see/do and invokes stored procedures to read from and write to the database.
  4. Stored procedures, installed on the relational database back end (e.g., Microsoft SQL Server or Oracle Database Server), access data in the local schema and return results.
  5. Calls to stored procedures which insert, delete or update records are forwarded by the database service to its replicating peers, so that each database instance may be kept up to date.
  6. Data returned by stored procedures is passed back to the calling program.

This architecture is advantageous for several reasons:

  1. Built-in data replication makes it easy to configure Identity Manager in a high-availability, fault-tolerant architecture.
  2. Using stored procedures rather than direct SQL calls significantly improves performance while leaving open the possibility of future schema changes.
  3. Using a Identity Manager database service to front-end the physical database enables robust access controls and easy-to-manage database replication.
  4. Wrapping data calls in an encrypted protocol enables secure configuration in a distributed environment, over untrusted network segments.

Return on Investment

Identity Manager strengthens security by:

Identity Manager reduces the cost of managing users and security entitlements: