White Papers Managing an Identity Management Project Identity Management Project Roadmap
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Identity Management Project Roadmap

arrowAbstract
This document will guide you through the entire life of a successful Identity Management project, including:
  • A needs analysis.
  • Who to involve in the project.
  • How to select the best product.
  • Technical design decisions.
  • How to effectively roll out the system.
  • How to monitor and assure sound ROI.

(1)

As today's organizations deploy an ever-growing number of complex systems and manage existing or new staff, manual administration of user access to systems becomes costly and ineffective:

Clearly, these problems call for automation, to consolidate and rationalize the administration of user identity data across a variety of systems.

This document will guide you through the entire life of a successful Identity Management project, including:

Needs analysis

(2)

The first step in an identity management project is to document the needs of the organization.

The needs analysis should identify the problems associated with existing business processes. The resulting set of requirements should be mapped to technical specifications, to be fed into subsequent technology selection and implementation design.

Following are the most common user access administration problems, and a brief description of available technology that can address them:

User productivity

The problem

Newly hired employees usually are not productive for an extended period of time, often weeks, as they wait for their accounts to be provisioned.

Existing users are not productive as they wait for updates or changes to their existing accounts.

Business process solutions

Streamline the "on-boarding" process whereby systems access for new employees and contractors is requested, routed, approved and provided.

Technological solutions

Implement:

Excessive administration cost

The problem

Users require access to multiple systems, such as the network, e-mail, Intranet, ERP, mainframe and more. Each system's administrator must perform essentially the same tasks to create, change and terminate user access. This redundant effort is expensive and causes inconsistencies.

Business process solutions

Consolidate routine user management to at least eliminate the possibility that several different administrators will have to work on a single request for a single user.

Technological solutions

Inconsistent user data

The problem

Different systems may have different and possibly contradictory data about the same user. This makes it difficult to reliably provide services (e.g., sending e-mail to an external address), and to make security decisions (e.g., should the user be allowed to initiate a financial transaction?).

Business process solutions

Technological solutions

User service

The problem

Business process solutions

Technological solutions

Security vulnerabilities

The problem

Business process solutions

Technological solutions

Audit and reporting

The problem

For reasons of good governance, and in many cases for regulatory compliance, it is important to be able to track what users have access to what systems and data.

In a heterogeneous environment, this information may be scattered across multiple systems, uncorrelated, or simply unavailable.

Business process solutions

Technological solutions

Regulatory compliance

The problem

Regulations governing customer privacy (e.g., in the health care, financial and retail industries), sound business processes (e.g., in the pharmaceutical industry) and good corporate governance (e.g., for publically traded companies) generally require basic security practices:

These requirements can be restated in terms of the consistency, security, audit and reporting criteria laid out above.

Technology requirements

(3)

System functions

(4)

The business needs analysis above produces the functional requirements for an identity management system listed below. In any given organization, some subset of these requirements will be relevant:

Technical infrastructure

(5)

An identity management system should have some core technical capabilities, including:

Organization

(6)

To be successful, an identity management project must have a mandate, a schedule and a budget. Persons in an organization with a vested interest in identity management must be involved early in the project. This ensures that their requirements are met at the design stage, and that they will not object to any part of the project during deployment.

Mandate

A account management project must start with a clear mandate to solve specific business problems. (2) outlines the most likely issues to be resolved.

Projects that start without this mandate may fail when the time comes to request resources and the support of groups within the organization.

Budget

It is often helpful to verify, at the onset of an identity management project, whether or when sufficient funds will be available. The following items require funding:

Participants

Early involvement by all interested parties in an organization ensures that the final design reflects all needs, and that no objections will be raised late in the project.

The following groups are typically involved in an identity management project:

Ownership

It is crucial for an identity management project to include the system's long-term owner, as early as possible.

Ideally, the long-term system owner and the system's technical administrator(s) will have a strong influence over product selection. These people will have to work with the system and its vendor, so they are more likely to take the time to make a critical analysis of product documentation, and undertake a technical laboratory evaluation of candidate products.

It is risky, on the other hand, to have one team select a product, and a separate team install and manage it.

Selecting a product

(7)

The ideal identity management product should meet all of the project's technical requirements, and be supported by a stable, mature and helpful vendor.

The following sections describe the technical and business requirements that an identity management system vendor should meet.

Technical requirements

Functionality

Functional requirements for an identity management system are summarized in (4).

Additional detail for each function is presented below:

Capability Requirements
Automation Support multiple systems of record; be able to filter out just changes of interest; be able to transform changes to multiple formats, suitable for multiple target systems.
Workflow Allow any business users to submit change requests; be able to validate input requests; assign authorizers based on requested resources, on the identity of the requester, and on other request attributes; ask authorizers to approve requests by e-mail; support reminders, delegation and escalation to ensure that authorizers respond in a timely manner; allow requesters to track the status of their request, and to cancel open requests if appropriate; record change history for later reporting.
Consolidated user administration Allow security administrators to manage any user on any system from one point; implement access control lists to control what each administrator can see and do; be fully accessible from a web browser.
Delegated user administration Allow organization-specific logic to leverage existing information to make dynamic delegation decisions (i.e., can this administrator sign in, and if so what can he or she do, to whom?).
Auto-discovery Be able to efficiently extract full lists of users and groups from each managed system, nightly; be able to extract arbitrary user attributes and group memberships from managed systems, without impacting run-time performance too much.
Login ID reconciliation Support both systems where login IDs are standardized/consistent, and those where they aren't. Allow users to attach non-standard, uncorrelated IDs to their own profiles in a secure manner.
Password management Include password synchronization, self-service password reset, assisted password reset, global policy enforcement, early warning of upcoming password expiration, etc.; be accessible from a web browser, workstation login prompts and a telephone (IVR).
Password initialization Allow users entering change request to specify initial passwords, to eliminate insecure default values and transmission.
Audit logs Track user access rights on managed systems, and full change history.
Reporting engine Support both built-in reports (e.g., who has what), and an open schema and reporting interface, to allow for custom reports.
Standards enforcement Ensure that change requests are properly authroized. Create new accounts in compliance with standards, for example by cloning model IDs.

 

Target systems

A successful identity management system should be able to manage login IDs on most or all of the systems to which users login.

Target systems should work "out of the box" in as many cases as possible.

Where this is infeasible (e.g., home-grown applications, vertical market applications, legacy applications), the product should be open enough to make it possible to easily integrate with applications:

Integration

An identity management system should integrate seamlessly with existing IT infrastructure, including:

Deployment

Deployment should be as simple as possible. Features supporting this objective include:

Flexibility

The system should cope with both current and possible future requirements for:

Security

An identity management system literally owns the "keys to the kingdom" and consequently must meet the most stringent security requirements:

Vendor profile

As with any vendor, the company supporting an identity management system should offer sound support, effective professional services, good relationships with other relevant vendors, and long term stability.

Financial stability

In the interests of long term support for the technology, it is important to verify that prospective vendors are financially sound: growing rather than shrinking, and profitable rather than burning cash reserves.

Quality of support

Quality technical support is crucial to project success. This is best measured by implementing the identity management system in a test environment, and evaluating the ability of the vendor to assist in the installation process.

Deployment time

Vendors should be able to offer turn-key or assisted deployments. A good vendor will be able to successfully deploy the system in a minimum amount of time. A good product can be deployed without intrusion -- without installing desktop software, and with limited use of server agents.

The deployment effort in a large organization should not take more than 10-20 supplier person/days.

Single source

It is easier and safer to work with a vendor that can provide all the required technology directly. This eliminates the risks of using third party technology, such as:

Future direction

The successful vendor should have a clear direction for future growth and technology advancement. This helps to ensure vendor stability, and a sound future for the product.

Partners

identity management products must inter-operate with other IT infrastructure supported by current suppliers. Relationships between an identity management vendor and the vendors of other infrastructure or services can streamline interoperability and ongoing support.

In particular, it is helpful if the identity management vendor has a working relationship with providers of:

Project management

(8)

The following sections outline the objectives of each phase in a identity management deployment project.

Project startup

To begin the project:

  1. Perform a needs analysis, as described in (2).
  2. Document technical and business requirements, as described in (7).
  3. Establish a project whose mandate is to resolve the problems identified in the needs analysis.
  4. Identify prospective vendors and products.
  5. Allocate and approve people, systems and a budget.

Product selection

To make an effective product selection:

  1. Perform some research to find out what products are currently available. Analyst firms generally know which vendors have significant market share, and can identify prospects.

    Another excellent source of information is the Internet: use a search engine to find sites that mention:

    • "identity management,"
    • "user provisioning"
    • "user access management."

  2. Once you have identified prospective vendors, forward your technical and business requirements document to them, and request a proposal.

  3. Provide the prospective vendors a list of key decision-makers in your organization and their selection criteria. This will help vendors to focus their efforts on what matters most to you.

  4. Evaluate the product in either a laboratory environment or with a pilot group of users and systems. Evaluating products based on paper only is very risky. You may reach final conclusions based on unfounded or inaccurate information.

    Vendor RFP responses are no substitute for lab testing: some vendors will respond to RFPs based on what they believe the customer wants to hear, with no bearing on what their product can actually do, on the theory that "we can either build it later, or convince the customer that they don't need it."

    Analyst reports are also no substitute for lab testing: the analysts do not install products in their own labs, and instead rely on every vendor for an assessment of their own capabilities. Specific vendor claims are not verified.

    Ensure that all features defined in the requirements document are tested and compared. This exercise will highlight differences between products and vendors in a way that a paper process cannot.

  5. Compare vendor proposals, technical evaluation results and prices.

Acquisition

Once a product has been selected, negotiate on a price and project deliverables and sign a contract. Fixing the price and deliverables (professional services, milestones, level of support) mitigates project risk.

Include a detailed list of deliverables and a statement of work attached to the contract.

Product design, pilot and deployment

Prepare a detailed deployment plan including: system design, schedule and resource allocation. These should cover the following aspects:

Design

Determine:

Installation

Determine how you will carry out:

Software configuration

The sequence of feature and target system activation can vary widely from organization to organization. It is normally best to start small, and grow the system's capability over time, as this reduces project risk, and establishes value early rather than late in the project.

Following is a typical feature intallation sequence:

Training

Determine how you will:

User roll-out

Determine how you will notify users about the system and, if appropriate, ask for registration.

Ongoing system ownership and administration

(9)

While the bulk of the work in an identity management deployment process ends with user roll-out, more work is required on an on-going basis. This includes:

Ongoing support and upgrades

A technical resource must be assigned to ongoing system support. In particular, this person must:

A mature product should allow you to minimize the amount of effort required to perform these duties.

Directory cleanups

Once deployed, an identity management system can be used to identify and remove dormant and orphan accounts on each managed system.

Another type of directory cleanup made possible by an identity management system is login ID normalization, to eliminate the need for users to remember multiple, different login IDs on each system.

An identity management system can report on user access rights across systems, and these reports can be given to management to verify appropriateness, with the result being reduced system privileges where they are not needed.

Reporting and auditing

As mentioned earlier, security officers and auditors will most likely want to run reports using the system to track user access to systems.

Functional and scope extensions

Over time, the functionality and scope of a successfully deployed identity management system tends to grow. This includes:

Summary

(10)

Identity management systems offer a simple way to improve the process of creation and maintenance of user objects across the IT infrastructure.

A successfully deployed identity management system improves user productivity and service, reduces security administration operating cost, and improves both security and accountability.

A typical project begins with a concept, proceeds through a needs analysis, produces a set of technical and functional requirements, includes a broad deployment team, and proceeds through product selection, system design, deployment and ongoing management.

If managed effectively, an identity management project can go from conception to production in under six months, and yield a positive return on investment with in 2-3 months of deployment.