This document will guide you through the entire life of a
successful Identity Management project, including:
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:
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:
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.
Streamline the "on-boarding" process whereby systems access for new employees and contractors is requested, routed, approved and provided.
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.
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.
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?).
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.
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.
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:
An identity management system should have some core technical capabilities, including:
The identity management system should support the number of users and systems under consideration and should scale to support future growth. Run-time performance and load placed on the network and on target systems should be reasonable.
The identity management system should be able to implement organization-specific requirements, such as how to assign new login IDs, how to identify suitable authorizers for change requests, how to map changes in a system of record to target systems, etc.
Flexibility also relates to target systems: it should be easy to manage users on new, non-standard systems, such as custom and vertical-market applications.
Finally, flexibility may impact the exact meaning of updates to target systems. For example, disabling a login account on a target system may mean setting the "account disabled" flag in one organization, while it may mean moving the account to a different container in another organization.
The identity management system must be secure, not only in the sense that it enhances the security of existing users and target systems, but also in the sense that it is well protected, and does not introduce new security vulnerabilities.
In practice, this means that it should be locked down, and implement internal access controls and encryptions to limit the risk of unauthorized activity.
An identity management system is of no value until it is operational, and of limited value until it is fully in use. Moreover, many identity management systems offered in the past have been exceedingly difficult to implement, and deployments have aborted more often than completed.
Technology that assists in rapid deployment is essential to a successful identity management project. This includes at least:
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.
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.
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:
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:
Must understand how to use the system and its impact on their work.
Must define security policy and audit requirements that the system will enforce. Will likely use the system to monitor policy compliance, access rights and change history.
Must understand the impact of an identity management solution on the systems they manage.
Must understand the impact on overall security policy and design.
Must agree to provide authoritative input information to the system, at least for employees, and ideally for contractors as well.
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.
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.
Functional requirements for an identity management system are summarized in (4).
Additional detail for each function is presented below:
|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.|
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:
An identity management system should integrate seamlessly with existing IT infrastructure, including:
Users should be able to authenticate using existing infrastructure -- be it a network login ID/password (such as a Windows NT domain), security tokens (such as an RSA SecurID) or another technology.
The system should automatically create issues / tickets in any help desk call tracking system, to allow for follow-up in the event of a problem (e.g., target system outage or unresponsive authorizer).
The system should be able to interact with users, administrators and authorizers by e-mail -- for example, to notify requesters that the request for new account has been processed and the appropriate accounts have been provisioned.
Existing infrastructure should be able to monitor the identity management server's health, and react to alarm conditions.
Deployment should be as simple as possible. Features supporting this objective include:
The system should be able to automatically and periodically extract user profile information from target systems. This should not be a one-time or manual process.
Login IDs on different systems should be automatically correlated to one another where possible (i.e., where they are consistent, or where correlating data exists and is both complete and reliable). In other cases, self-service reconciliation should be supported, to avoid a massive central reconciliation effort.
Installing agents on a production server normally involves a lengthy change control process. Using existing client software to communicate with servers reduces deployment time.
An identity management system should take advantage of existing user profile databases, which may include information on various accounts for a given user.
An identity management system should be able to use the existing database as a source of information for additional account provisioning.
The system should be configured and managed with a simple, web-based interface.
The system should cope with both current and possible future requirements for:
The user interface should be customizable, and support different appearances for different users (such as multiple languages or user groups).
The mechanism for assigning login IDs to new users should be externalized, to allow organizations to implement their own logic.
The workflow system should leverage existing data to identify authorizers, and to find suitable people to receive escalated change requests.
The workflow system should be able to validate and fill-in attributes in change requests.
The workflow system should be able to limit what users can request, in order to simplify the change request input process.
The business logic for monitoring changes to user profile information in systems of record (e.g., HR), and for filtering, transforming and pushing out changes to target systems should be highly configurable.
The system should be able to respond to a wide variety of conditions by asking for assistance, in the form of writing a call tracking ticket in a help desk automation system.
The system must be able to enforce a global password policy for newly provisioned accounts.
An identity management system literally owns the "keys to the kingdom" and consequently must meet the most stringent security requirements:
The system must record every possible event, so that users and administrators alike can be held accountable for their actions.
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.
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 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.
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.
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:
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.
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:
The following sections outline the objectives of each phase in a identity management deployment project.
To begin the project:
To make an effective product selection:
Another excellent source of information is the Internet: use a search engine to find sites that mention:
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.
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.
Prepare a detailed deployment plan including: system design, schedule and resource allocation. These should cover the following aspects:
Determine how you will carry out:
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:
Determine how you will:
Determine how you will notify users about the system and, if appropriate, ask for registration.
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:
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.
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.
As mentioned earlier, security officers and auditors will most likely want to run reports using the system to track user access to systems.
Over time, the functionality and scope of a successfully deployed identity management system tends to grow. This includes:
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.