White Papers Identity Management Best Practices Enterprise IdM: Suite vs. Best-of-breed
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Enterprise IdM: Suite vs. Best of Breed

Introduction

Growing awareness of a variety of different types of enterprise identity management applications, combined with consolidation of identity management software vendors, are leading many organizations to wonder whether they would be best served by either a suite of products from a single vendor, or a combination of best of breed products from multiple vendors.

This is an important decision, which would be well served by a deeper understanding of the benefits and drawbacks of each approach: suite vs. best of breed.

The remainder of this document differentiates suite from best of breed approaches, and strives to shed light on the business variables that should drive a decision to pursue one or the other.

Executive Summary

In this document, the set of possible integrations between IdM components is reviewed, in terms of business value and implementation difficulty.

The conclusion of this analysis is that:


Background

Enterprise Identity Management

Enterprise Identity and Access Management (IAM) is defined as a set of processes and technologies to effectively and consistently manage modest numbers of users and entitlements across multiple systems. In this definition, there are typically significantly fewer than a million users, but users typically have access to multiple systems and applications.

Typical enterprise identity and access management scenarios include:

Enterprise identity management systems leverage basic identity infrastructure, such as directories.

Some identity management applications are relevant to both enterprise and B2C deployments. This includes web single sign-on (WebSSO), extranet access management (EAM) and single-directory administration.

Enterprise IAM presents different challenges than identity and access management in Extranet (B2C or B2B) scenarios:

Characteristic Enterprise IAM (typical) Extranet IAM (typical)
Number of users

under 1 million

over 1 million
Number of systems and directories

2 -- 10,000

1 -- 2
Users defined before IAM system is deployed

Thousands

Frequently only new users
Login ID reconciliation

Existing accounts may have different IDs on different systems.

Single, consistent ID per user.
Data quality

Orphan and dormant accounts are common. Data inconsistencies between systems.

Single or few objects per user. Consistent data. Dormant accounts often a problem.
User diversity

Many users have unique requirements.

Users fit into just a few categories.

 

In short, Enterprise IAM has fewer but more complex users. Extranet IAM has more users and higher transaction rates, but less complexity.

Enterprise IdM Infrastructure Components

As mentioned above, there are several primary components of an enterprise IdM system, beyond the underlying user databases and directories:

Enterprise IdM Technical Components

(1)

Enterprise IdM products, while they may be different in function, can share some technical components:


A Best of Breed Approach

Best of breed vendors include Hitachi ID Systems for user provisioning and password management functions, Microsoft for meta directories, Oblix for WebSSO/EAM and Citrix for E-SSO.

These vendors typically provide significantly greater functionality in their segment of the IdM functionality, as well as easier deployments and lower TCO. These advantages stem from:

Pure-play vendors cannot rely on huge sales and marketing teams to deliver revenues. They must make customers happy.

A Suite Approach

Suite solutions from vendors such as IBM, Novell, CA and Sun tend to include most or all of the enterprise IdM components described in (1).

Each of the suite vendors also offer a directory, however as directories are all standards-compliant using LDAP, directory integration does not present any integration risks.

The suite vendors largely built their suites through a combination of in-house development and acquisitions, so the fact that a single vendor sells the entire suite does not mean that all the components integrate smoothly, or even at all.

Some components of each suite may be limited, as well. For example, the password management component may have no facility for access to self-service from the login prompt, and the suite may have no actively managed user enrollment process or distributed entitlements audit capability.

Suites do tend to provide a consolidated management console, and in some cases a consolidated logging system, useful for troubleshooting.

The quality and total cost of ownership of the components of each suite varies:


Points of Integration

Not every organization needs every identity management function. This reduces the number of integrations between separate IdM functions in a given organization.

For those IdM functions that are deployed, there are clear points of integration as illustrated in the following table:

    Points of Integration between Enterprise IdM Functions (2)

System

Password Management

User Provisioning

Meta Directory

Enterprise SSO

WebSSO / EAM
Password Management

-

(1) Share agents, share JOIN data

(2) Share agents, share JOIN data

(3) Re-encrypt SSO credentials after PW reset

(4) WebSSO front-end to PW system, WebSSO PW target

User Provisioning

(1)

-

(5) Add target types

(6) Provision credentials after creating logins

(7) Manage WebSSO users, fulfill EAM workflows

Meta Directory

(2)

(5)

-

(8) Provision credentials after creating logins

(9) Manage WebSSO users, fulfill EAM workflows

Enterprise SSO

(3)

(6)

(8)

-

(10) Share authentication

WebSSO / EAM

(4)

(7)

(9)

(10)

-

 

From Table (2), we see that there are ten possible integration points between the five main types of Enterprise IdM applications that an organization may deploy. Most organizations will deploy only a subset of these applications, and so require only a subset of the possible integrations between those applications.

The nature of each of the integrations in Table (2) bears further consideration. Some integrations are easy to construct, including by the organization deploying an IdM infrastructure, while others are very complex, requiring vendor assistance. Also, while some integrations provide significant added value, others do not.

  1. Share agents, share JOIN data (3)

    Integration between: password management and user provisioning.

    Agents, either remote or local, are the connection between an enterprise IdM system and target systems. Clearly, an agent that can validate current and reset new passwords, as well as creating, updating and deactivating users, can be used by both a password management and user provisioning system.

    In products where target system integration is difficult, sharing agents between functional components is a good way to save time and money. In products where target integration is rapid and requires low ongoing maintenance, this integration makes sense, but is not a major contributor to reducing project TCO.

    JOIN data is what connects user objects on different systems back to individual owners. Without JOIN data, it is impossible to provide password synchronization, reset or consolidated user administration.

    A major component of deploying any Enterprise IdM system is to construct and maintain JOIN data across target systems. Password management systems are normally the first to be deployed, since they are simplest and provide immediate ROI. Accordingly, it makes sense for other systems, including user provisioning, to take advantage of the JOIN data assembled during deployment of the password management system.

  2. Share agents, share JOIN data (4)

    Integration between: password management and meta directory.

    Since password management is most often deployed first, it makes sense to leverage its JOIN data in deploying a meta directory.

    In case a meta directory is deployed first, it makes sense to leverage its target system connectivity when subsequently deploying a password management system.

  3. Re-encrypt SSO credentials after PW reset (5)

    Integration between: password management and enterprise single sign-on.

    E-SSO systems manage a set of encrypted credentials to multiple systems and applications. These credentials are normally encrypted using a key derived from each user's primary login password.

    When a password management system resets a user's primary login password, the user will be unable to regenerate the old ESSO encryption key, and so will lose his credentials. Integration is therefore required between simultaneously deployed E-SSO and password management systems, to re-encrypt E-SSO credentials after each password reset, so that users will not have to re-enroll their E-SSO credentials after a password reset.

  4. WebSSO front-end to PW system, WebSSO PW target (6)

    Integration between: password management and web single sign-on.

    Most password management systems are web-based, and a WebSSO system can front-end authentication into the password management system -- at least for routine password updates and user enrollment.

    WebSSO systems most often use a password for initial authentication, and this password can be in scope for a password management system's synchronization and reset services.

  5. Add target types (7)

    Integration between: user provisioning and meta directory.

    Modern user provisioning systems tend to have connectivity to many more types of target systems than contemporary meta directory products. Consequently, it makes sense to leverage a user provisioning system's agents to extend the reach of a meta directory to new types of systems and applications.

  6. Provision credentials after creating logins (8)

    Integration between: user provisioning and enterprise single sign-on.

    Enterprise single sign-on systems maintain a set of credentials for each user, to every system and application into which that user signs on.

    User provisioning systems create and modify login accounts on the same systems.

    As a result, it makes sense for user provisioning systems to write updates into an E-SSO's credential database or directory after each create-user and deactivate-user operation, to eliminate the need for separate user enrollment in the E-SSO system.

  7. Manage WebSSO users, fulfill EAM workflows (9)

    Integration between: user provisioning and web single sign-on.

    User provisioning systems are intended to be a single point of administration for every login ID on every system in an organization. Accordingly, it makes sense for the user provisioning system to be able to manage users on the WebSSO application, just as it does on every other application, system and directory.

    In case an organization prefers to manage users through the WebSSO's identity management infrastructure, that infrastructure will require connectivity to multiple types of target systems, which is not normally available through the WebSSO application. This creates a second type of integration, where the WebSSO application manages the change request / approval process, and the user provisioning system acts as a fulfillment engine to implement approved user administration operations.

  8. Provision credentials after creating logins (10)

    Integration between: meta directory and enterprise single sign-on.

    This is essentially the same integration as between user provisioning and enterprise single sign-on, except that users are created and deleted as a part of the data synchronization process, rather than consolidated, delegated or self-service workflow of a user provisioning system.

  9. Manage WebSSO users, fulfill EAM workflows (11)

    Integration between: meta directory and web single sign-on.

    This is essentially the same integration as between user provisioning and web single sign-on, except that users are created and deleted on the WebSSO system as a part of the data synchronization process, rather than consolidated, delegated or self-service workflow of a user provisioning system, and the meta directory fulfills change requests authorized by the WebSSO's workflow engine.

  10. Share authentication (12)

    Integration between: enterprise SSO and web SSO.

    Where both an enterprise single sign-on system and a web single sign-on system are deployed, it makes sense to authenticate the user once, and enable access to both legacy and web applications.


Integration Value and Complexity

As mentioned earlier, there are ten possible integration points between the five main types of Enterprise IdM applications that an organization may deploy. These integrations can be conveniently classified by value and complexity as shown in the following table.

    Difficulty and value of integrating Enterprise IdM components (13)

Difficulty Simple Complex
Value    
Low

(6) and (12) in Table (2).

(8) and (10) in Table (2).

High

(9) and (11) in Table (2).

(3), (4), (5) and (7) in Table (2).

 

The business impact of the integration value / complexity analysis in Table (13) can be interpreted as follows:


Managing Integration Risk

Regardless of whether the various IdM components are acquired from a single or multiple vendors, some integrations between the components will be required, and of those, some will be complex to integrate.

To mitigate integration risk, it is important to ask the vendor(s) to characterize the high-value integrations, and to demonstrate the high-value, high-complexity integrations in the lab. These integrations are repeated here:

Other integrations, while nice to have, are unlikely to impact project success or scope.


Hitachi ID Systems Integrations

Hitachi ID Systems offers an identity management suite. Though functionally broad, this suite does not encompass every possible enterprise IdM function.

In order to expedite customer deployments, and minimize customer risk, the Hitachi ID Systems suite comes with a broad range of pre-built integrations with other enterprise IdM components, as follows:


Summary

There are only a modest number of integrations between the various components of an enterprise identity management architecture.

The set of integrations relevant to a given organization will depend on the set of IdM functions that the organization deploys. Of these, some will be complex to develop, while others are very simple. Some create significant added value, while others offer only minor convenience.

The fact that suite vendors sell most or all of the components of an enterprise IdM architecture does not guarantee that the various points of integration, and in particular the high-value, high-complexity integrations, are either available or work well in their suite. What is certain is that suite vendors offer significantly reduced functionality in some IdM functions.

Similarly, best of breed vendors may in some cases, and not in others, provide seamless integration with one another. They can be relied upon, however, to provide the maximum possible value, and lowest TCO, for individual IdM functions.

Organizations designing an enterprise identity management architecture should consider ahead of time what integrations they will require, and validate that solutions being considered do provide these integrations. Those integrations that are both high value and difficult to implement should be tested in a lab prior to product purchase.

As a best of breed vendor, Hitachi ID Systems has endeavored to pre-build a wide set of integrations with other products in the enterprise IdM market. Prospective Hitachi ID Systems customers are encouraged to validate these integrations prior to making a purchasing decision.