Identity Management Deployment Best Practices

Addressing Deployment Challenges
in Enterprise Identity Management
© 2014 Hitachi ID Systems, Inc. All rights reserved.

This Hitachi ID Systems white paper describes the major challenges in deploying an enterprise identity
management (IdM) system, including data cleansing, role engineering and workflow definition and main-
tenance. The information presented here is derived from hundreds of deployments performed over many
years.
This paper presents practical solutions to the design and implementation of an IdM system, to overcome
these challenges. Solutions include auto-discovery and self-service login ID reconciliation, minimizing the
need for role definition and user-to-role classification and use of a single, dynamic authorization process
rather than one workflow per request type.
Contents
1 Introduction 1
2 Enterprise Identity Management 2
3 Business Drivers and Use Cases for Enterprise Identity Management 3
4 Deployment Challenges 4
4.1 Login ID Reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Role Engineering and User Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Workflow Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Simplifying Deployment using Processes and Technology 8
5.1 Self-Service Login ID Reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Role Engineering and User Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Dynamic Workflow Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6 Summary 14
7 Hitachi ID Systems Products 15
i

Addressing Deployment Challenges in Enterprise Identity Management
1 Introduction
Enterprise identity management systems bring many beneﬁts to large organizations and are increasingly
a required feature in today’s regulatory environment. Some of the important features of enterprise IdM
include:
• Improved user productivity, due to reduced wait for new and updated systems access and fewer
authentication problems.
• Lower security administration cost, as the bulk of user management is automated or delegated to
business users and password resets are either eliminated or resolved with self-service.
• Enhanced security, as inappropriate access is terminated quickly and reliably.
• Regulatory compliance, including the ability to audit access rights globally, to ensure that only appro-
priate users have access to sensitive systems and data.
Unfortunately, despite two generations of user administration technology, enterprise identity management
systems from many vendors remain difﬁcult to deploy and costly to maintain. Many IdM projects end either
in stripped-down installations or are entirely abandoned due to these factors.
This paper discusses the main challenges encountered by large organizations in deploying enterprise iden-
tity management systems, and offers solutions to help overcome each challenge.
The solutions offered in this paper are implemented in the Hitachi ID Management Suite.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

2 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:
• Password synchronization and self-service password reset.
• User provisioning, including identity synchronization, auto-provisioning and automatic access deacti-
vation, self-service security requests, approvals workflow and consolidated reporting.
• Enterprise single sign-on – automatically filling login prompts on client applications.
• Web single sign-on – consolidating authentication and authorization processes across multiple web
applications.
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.

3 Business Drivers and Use Cases for Enterprise Identity Manage-
ment
There are several business drivers for deploying an enterprise identity management and access governance
system, including:
• Security and regulatory compliance:
– Reliable access deactivation when users leave the organization.
– Secure access to privileged passwords.
– Enforce segregation of duties policies.
– Periodically review security entitlements and eliminate unneeded ones.
– Ensure that new access is provisioned in compliance with standards.
• IT support cost:
– Lower IT support call volume and head count.
– Reduce the amount of manual security administration required.
• User service:
– Simplify change request processes.
– Provision required access more quickly.
– Reduce the number of passwords users must manage.
– Reduce the number of login prompts users must complete.

4 Deployment Challenges
As defined in Section 2 on Page 2, enterprise identity management presents its own challenges, which are
quite distinct from other types of identity management. While the number of users may be relatively modest,
the complexity per user, in terms of data correlation, stale data, unsynchronized data, access requirements
and controlling business processes is significant.
This complexity presents challenges for deploying an enterprise IdM system, described below.
4.1 Login ID Reconciliation
Before user access to multiple systems can be managed by a single, coherent system, the various login
IDs and profiles that belong to each user must be connected to one another. Until this is done, it will be
impossible to synchronize passwords or other data attributes, to report on the access rights of a single user
across multiple systems, or to make updates to user profile data across more than one system at a time.
The process of connecting possibly different login IDs, on different systems, back to their individual human
owners, is called login ID reconciliation. While the process may be simple in principle, reconciling large
numbers of login IDs in a time and cost-effective manner can be a major obstacle, as illustrated in Table 1.
In practice, scenarios 1 and 4 in the table are the most common. Organizations fortunate enough to be in
scenario 1 have no login ID reconciliation problem at all. Organizations in scenario 4 frequently undertake
a manual data cleansing project, to populate an anchor attribute or rename login IDs on key systems to
bring them into compliance with an enterprise-wide naming standard. Such data cleansing projects can
take several months, and cost tens or hundreds of thousands of dollars to complete.
As a result, many enterprise IdM projects encounter an unforeseen delay of many months, and deployment
cost overruns that reach into the millions of dollars.
Only after login ID reconciliation is complete can enterprise IdM functions such as password synchronization
and reset, user profile data synchronization, consolidated access reporting and single-interface access
termination be implemented.

Table 1: Login ID Reconciliation Options
Scenario
If: Then: Example:
1 Every user has just one login
ID, used on every system.
User objects can be connected
using login ID as a key.
jsmith on system A is the
same user as jsmith on
system B.
2 Every user object includes a
globally unique key (an anchor
attribute).
User objects can be connected
using the anchor attribute, in
place of the login ID.
Employee ID or SSN may be
populated on every system.
3 Someone has already built or
is actively maintaining a map
file between login IDs on
different systems.
Login ID reconciliation is
already done! Just load the
data.
CSV file: "jsmith",
"john_smith",
"smith01", · · ·
4 None of the above is true. This is the most common
situation, especially in large
organizations with a history of
mergers, acquisitions and
multiple, platform-specific
security administration groups.
There are three options to
reconcile login IDs in this case:
• Correlate login IDs on
different systems using
exact or approximate
match on full name as
the anchor attribute.
• Embark on a data
cleanup project, to
populate some other
anchor attribute or to
normalize login IDs on
every system.
• Employ self-service, to
get login ID reconciliation
data from the users
themselves.
The best choice will depend
on what data is available, how
complete and reliable it is, and
on corporate culture.

4.2 Role Engineering and User Classification
A common strategy to more efficiently and securely managing user access to systems is to define roles, that
encapsulate the access requirements of groups of users. User access to systems can then be managed
simply by assigning users to the appropriate roles. Moreover, as IT infrastructure and security policy are
changed, role definitions can be adjusted, and user access to systems will automatically be updated to
match.
This approach, commonly called policy-based provisioning, is broken down into three fundamental steps:
• Define a set of roles, detailed enough to capture the full access requirements of every user, on every
target system.
• Classify users into roles, such that their access requirements are fully specified by role membership.
• Reconcile access privileges predicted by the policy model against the access privileges users actually
have on target systems.
• Correct actual privileges to match those predicted by roles, either automatically or after human review
and approval.
Most second-generation user provisioning products are based on this policy-based approach. They define
roles as a fundamental building block of user administration and use roles to control, rather than just add
to, user access to systems.
In real-world enterprises, that have thousands of unique users, each with a slightly different business role,
and consequently a slightly different set of access requirements, this approach leads to the definition of
thousands of roles – often as many roles as there are users.
This complexity makes two key deployment tasks very difficult, time consuming and costly:
• Definition of sufficient roles to encapsulate the access requirements of every user.
• Classification of every user into one or more roles.
As a result, most role-based projects bog down in an interminable role engineering and user classification
phase.
This problem is aggravated by the fact large organizations have significant staff turn-over (retail, bank,
seasonal and service industries are common examples) – new hires, terminations, changes in responsibility,
mergers, acquisitions, divestitures, layoffs, etc. This turn-over makes role definition and user classification
an ongoing challenge, rather than one associated just with initial system setup.
The challenges posed by role engineering and user classification typically lead either to stripped down
deployments – e.g., covering just one or two systems, or applying just to specific populations of very regular
users; or to IdM project abandonment.

4.3 Workflow Definition
An integral component of many identity management systems is the empowerment of business users to
manage access changes directly. This provides greater accuracy for provisioning/de-provisioning and facil-
itates quicker changes while reducing the workload on IT staff. To do this, a self-service workflow system is
installed, that includes:
• Web forms where business users may request security changes, such as creating new users or
accounts for existing users, changing user attributes or entitlements on one or more systems, or
deactivating access for existing users on one or more systems.
• Business logic to validate route change requests, and route them to suitable authorizers.
• Authorization forms where appropriate business users can review and approve or reject changes.
• A fulfillment engine which implements approved changes on target systems.
• Reminders, escalation and delegation features, to deal with unresponsive authorizers.
Most second-generation user provisioning systems include some sort of workflow engine to provide the
above functionality.
Since the validation and authorization logic for each type of change request, on each system may be dif-
ferent, the standard approach to implementing workflow is to embed a general-purpose business workflow
engine in the user provisioning software. Customers can then define unique flowcharts or state tables that
capture the validation, authorization, reminder, escalation and delegation logic for every kind of change
request.
The problem with this open-ended approach is scalability. While a flowchart or state-table based solution
is quite flexible, it requires one flowchart or table to be defined for each and every kind of change request.
Consider a user provisioning deployment where users are managed on 50 different target systems or direc-
tories, and where on each system the user provisioning system may have to provision twenty different kinds
of users, mediate access into and out of 20 different security groups, and support another 10 miscellaneous
transaction types, such as user deactivation, reactivation, renaming and attribute changes. This amounts
to 70 transaction types per system, and 3,500 transaction types in total.
In essence, while an open-ended workflow engine is functionally able to deal with user provisioning applica-
tions, real-world scenarios quickly lead to an unmanageable number of transaction types, and the time and
effort required to define and maintain the thousands of required flowcharts can quickly become prohibitive.
The challenges in administering a traditional workflow engine in the context of an enterprise user provision-
ing system typically lead to delay or abandonment of this core functionality.

5 Simplifying Deployment using Processes and Technology
The seriousness of the deployment challenges in both first and second-generation enterprise identity man-
agement systems, described in Section 4 on Page 4, means that a successful system must be engineered
from the ground up to avoid or resolve these problems. These are the key components required for a
successful system.
5.1 Self-Service Login ID Reconciliation
In organizations where login IDs are not consistent, and where there is no pre-existing, reliable and widely
populated anchor attribute to which different user objects can be reconciled, self-service can be used to
quickly, reliably and inexpensively connect login IDs on different systems back to their human owners.
Hitachi ID Management Suite implements self-service login ID reconciliation, as follows:
• Users are automatically invited to complete their profiles – for example via an e-mail with an embedded
URL.
• Users sign into the registration system, using a primary login ID and password or other types of
credentials.
• Users are asked to type their additional ID/password pairs. Each provided ID/password pair is com-
pared against an automatically maintained inventory of login IDs drawn from target systems, to find
instances where the user-entered login ID appears on a system and does not yet belong to a known
user profile. Management Suite then attempts to sign into that system with the user-entered password.
If the login attempt succeeded, the user’s profile is updated with the system ID and the user-entered
login ID.
Self-service login ID reconciliation has major advantages over data cleansing projects and over approximate
matching on attributes such as full names:
• The process is inexpensive to implement, as it only requires a few minutes from each of thousands of
users. This distributed effort is effectively free.
In contrast, data cleansing projects require months of effort from multiple full time staff.
• The process can be made as fast as desired. Thousands of users can be asked to enroll per week.
An entire organization can be deployed in one or two months.
• Connected login IDs are guaranteed to belong to the indicated user, since their owner “proved pos-
session” by providing a validated password to each login account.
In contrast, both a data cleansing project and approximate matches on full name will yield erroneous
matches, which will later constitute security breaches, including allowing one user to reset another’s
password.

5.2 Role Engineering and User Classification
As mentioned earlier, policy-based user provisioning depends on a model of user privileges. The main
element of user privilege modeling is classifying users into roles, and defining roles in terms of privileges
on individual systems.
The activities of role definition and user classification into roles are collectively referred to as role engineer-
ing. Unfortunately, role engineering in a large organization, where users are not highly regular (e.g., bank
tellers, retail sales clerks) is so costly as to be almost impossible to complete.
The only way to ensure that an enterprise identity management project does not get bogged down in role
engineering or user classification is to avoid roles as the fundamental building block of user administration
in the first place. Hitachi ID Management Suite is designed to work without a reliance on role definitions or
user classification into roles. Indeed, there is no need to model the access profiles of current users at all.
Management Suite does include a role construct, but it is used as a user interface element, rather than a
building block for enforcing security policy. Requests for new access privileges may include a combination
of roles and other privileges – specific account types, membership in security groups, etc.
Rather than depending on roles, Management Suite is based on the notion of business users requesting the
access rights they require, stake-holders reviewing those requests and either approving or rejecting them,
and Management Suite automating all authorized changes.
To ensure that inappropriate, stale user privileges are removed, Management Suite also incorporates a
process for access certification, where managers and application owners are periodically asked to review
the security rights of users in their area of responsibility, and to either approve (certify) or reject (request
deletion) each user and security right.
These processes can be summed up as “Request / Review / Revoke.”
With this approach, a variety of business processes support changes in business roles:
• New hires
– Automatic change propagation:
Hitachi ID Identity Manager can detect new hires on a system of record, such as an HR applica-
tion, a corporate directory or a contractor management application. When new user records are
detected, rules are applied by Identity Manager to decide whether to create a new user profile
and what kinds of accounts to provision on target systems.
Automated user creation is run as a batch process, typically every night.
– Self-service workflow:
Managers or HR users can fill in a form requesting a new user profile and specifying a role (a
collection of model accounts on target systems). These requests are routed to the appropriate
authorizers, reviewed, approved and fulfilled by Identity Manager.
– Consolidated / delegated administration:
An existing change control process may lead a security administrator, either centrally or closer to
the location or department of the new user, to create a new user profile. This is done using the
Identity Manager consolidated user management console.

• Terminations
– Scheduled terminations:
Identity Manager can schedule automatic access termination, as an integral part of the initial
user profile. Scheduled terminations are normally preceded by e-mails asking the user and/or the
user’s direct manager to verify or postpone the termination. At the time of termination, systems
access is disabled and at some later time period, objects owned by the user (e.g., mail folders,
directories on file servers, tablespaces) are deleted, moved or assigned new owners.
Identity Manager can detect terminations on a system of record, such as an HR application, a
corporate directory or a contractor management application. These may appear as either users
that have been removed or users that have been flagged as terminated. When terminations are
detected, rules are applied by Identity Manager to decide whether and where to also terminate
systems access for these users.
Automated terminations are normally batched – e.g., nightly.
Managers or HR users can fill in a form requesting a termination. These requests are routed to
the appropriate authorizers, reviewed, approved and fulfilled by Identity Manager.
An existing change control process, possibly as simple as a management request for urgent
access termination, may lead a security administrator, either centrally or closer to the location
or department of the new user, to deactivate a user. This is done using the Identity Manager
consolidated user management console.
• Users that require new privileges
Identity Manager can be configured with rules, reflecting access management policy, that lay out
access privileges (login accounts, account attributes and group memberships) that each user
should have on each target system.
Changes on a system of record (HR, directory, etc.) trigger these rules and Identity Manager
compares the predicted access rights of a user against the rights that the user actually has on
target systems. Differences are then either applied directly to target systems or to the workflow
engine as requests for change approval.
Automated access changes are normally batched – e.g., nightly.
Users or their managers can submit requests for new accounts, membership in groups or at-
tribute changes interactively on a web form. The Identity Manager workflow engine forwards
change requests to appropriate authorizers for review and acts on them once they are approved.
Requests for new group membership are a special case, in that users who do not know what
group they would like to join can browse for resources (e.g., folders on shares, printers) through
the Hitachi ID Systems Hitachi ID Group Manager web interface and request access to objects.
Group Manager automatically calculates which group membership is required, identifies the ap-
propriate group owner / authorizer and submits a workflow change request.

An existing change control process, possibly as simple as a management request for new access
rights, may lead a security administrator, either centrally or closer to the location or department of
the new user, to create new accounts, attach an existing user to groups or modify the attributes of
an existing user account. This is done using the Identity Manager consolidated user management
console.
• Stale privileges that should be removed from user profiles
– Access certification:
Hitachi ID Access Certifier can be configured to periodically ask every manager in an organi-
zation to review the access privileges of his subordinates. Managers receive an e-mail with an
embedded URL to the Access Certifier web page, where they:
* See a list of their subordinates and indicate which user profiles should be removed, if any.
* Open each subordinate’s profile and see a list of login accounts on target systems. Managers
are required to review each account and select those accounts that are no longer required,
thereby requesting deletion of those accounts.
* Open each account, to see a list of entitlements (membership in security groups or roles on
that target system). Managers are required to review each security entitlement and select
those that are no longer required, thereby requesting deletion of those entitlements.
* User profiles, accounts and entitlements that have been flagged as “no longer required” are
reviewed by system owners or other managers before being removed from target systems.
* Managers see the completion status of the access certification process for each of their
subordinates that is also a manager. In this way, completed access certification flows up
through an organization, ultimately leading to the CEO or CFO being able to attest to the fact
that the access rights of every user have been reviewed and cleaned up.
Identity Manager can be configured with rules, reflecting access management policy, that lay out
access privileges (login accounts, account attributes and group memberships) that each user
should have on each target system.
Changes on a system of record (HR, directory, etc.) trigger these rules and Identity Manager
compares the predicted access rights of a user against the rights that the user actually has on
target systems. Differences are then either applied directly to target systems or to the workflow
engine as requests for change approval.
Automated access changes are normally batched – e.g., nightly.
Managers or HR users can fill in a form requesting the deactivation of accounts or removal of
users from security groups. These requests are routed to the appropriate authorizers, reviewed,
approved and fulfilled by Identity Manager.
An existing change control process, possibly as simple as a management request for reduction in
a user’s access rights, may lead a security administrator, either centrally or closer to the location

or department of the new user, to deactivate a user. This is done using the Identity Manager
consolidated user management console.
5.3 Dynamic Workflow Definition
A workflow engine allows people and automated processes to request and authorize security changes di-
rectly, without involving security administrators. This is a key feature of any successful identity management
and access governance system.
Configuring a workflow engine can be challenging. As an identity management or user provisioning system
deployment scales up to support hundreds of target systems, with hundreds of kinds of updates supported
on each one, the workflow engine must scale to appropriately validate and authorize thousands of types of
transactions.
With a traditional workflow engine, this would require either thousands of flowcharts or thousands of state
tables (either way – unmanageable).
To mitigate the challenge of arithmetic explosion in the number of required workflow processes, the Hitachi ID
Management Suite workflow engine is dynamic, in the sense that a single, powerful state machine is used to
track authorizations for every possible change (transaction) on every target system. Plug-in programs alter
the behavior of the state machine, using business logic to validate inputs, route requests to the appropriate
authorizers based on requested resources or the identity of the requesting principal and so on.
Rather than requiring organizations to define one flowchart for every supported type of user profile change
on every target system, a single, built-in flowchart is used to track change authorization for every possible
change type, on every system. Organizations are instead asked to define business logic for a small number
of control points in the master flowchart: input validation, authorizer routing, reminder timing and automatic
escalation routing. The same workflow engine, implementing the same change authorization process,
applies to every possible user update. Shared business logic ensures that appropriate decisions are made
for validation and authorization in every case.
This approach eliminates the need for organizations to graphically draw out and maintain thousands of
flowcharts (who wants to do that?), with blocks of business logic (programming) embedded in each one.
Instead, Hitachi ID Systems customers use a programming language of their choice to write 4 or 5 blocks
of general-purpose business logic, for tasks such as input validation, authorizer routing and escalation. The
same logic applies globally, which makes dynamic workflow faster to develop, easier to maintain and clearer
to audit.
Dynamic workflow is illustrated in Figure 1 on Page 13.
A dynamic workflow engine is significantly easier to set up and maintain than the alternative: traditional
workflow engines where a graphical flow-chart or a state table is manually defined for each and every one
of the thousands of possible transaction types.
Using its dynamic workflow engine, Management Suite can be configured and deployed in weeks, rather
than months or years. Furthermore, the dynamic workflow engine in Management Suite requires minimal
ongoing maintenance, resulting in a much lower TCO than a traditional workflow engine.

Requester
Form
input
Validation /
completion
Authorizer
routing
Auto-
reminders
Delegated
authority
Auto-
escalation
E-mail
notification
Approved?
Approval
form
E-mail
invitations Target Systems
Workflow
Manager
Transaction
Manager
Connector
B.L.
B.L.
B.L. B.L.
B.L. B.L.
B.L.Exits
business logic: external pro-
grams or scripting code that
modifies Hitachi ID Identity
Manager behavior.
exit programs: external pro-
grams or scripting code that
notifies other systems of
Hitachi ID Identity Manager
events.
Authorizers
Hitachi ID
Management Suite
Figure 1: Management Suite Dynamic Workﬂow

6 Summary
The three main challenges in deploying an enterprise identity management system are:
• Data quality.
• Role engineering.
• Workflow setup and administration.
Failure to address these challenges in an effective manner at the outset of an enterprise identity manage-
ment project leads to a significant risk of cost overruns at the least, and project abandonment in many
cases.
This white paper has laid out simple, practical solutions to each of these challenges:
• Auto-discovery and self-service login ID reconciliation.
• Provisioning without user classification or role definition.
• Dynamic workflow, with embedded logic for validation and authorizer routing.
These strategies for successful deployment are core to the Hitachi ID Management Suite, and have led to
numerous successful enterprise-scale deployments.

7 Hitachi ID Systems Products
The Hitachi ID Management Suite is an integrated solution for identity administration and access gover-
nance. It streamlines and secures the management of identities, security entitlements and credentials
across systems and applications. Organizations deploy the Management Suite to strengthen controls, meet
regulatory and audit requirements, improve IT service and reduce IT operating cost.
The Management Suite is designed to efficiently create, manage and deactivate user objects, identity at-
tributes and security entitlements across systems and applications in medium to large organizations. This
is done using a combination of automation and self-service:
• Automation propagates changes from one system to another.
• Workflow invites business users to participate by completing their own profiles, authorizing changes
and reviewing the current state of users and privileges.
• Consolidated management enables security staff to manage access with a user-centric, rather than
application-centric view.
• Password synchronization and enterprise single sign-on reduce the number of passwords that users
must remember and type.
• Reports enable auditors, security officers and system administrators to analyze current state and
review historical changes.
A rich set of connectors are included, to easily integrate with most common systems and applications and
to manage credentials including passwords, challenge/response profiles, biometric samples, OTP devices,
PKI certificates and smart cards.
The Management Suite’s strengths are industry-leading flexibility, integration and ease of deployment.
An open architecture, including hundreds of plug-in points, allows organizations to adapt the Management
Suite to their needs. Built-in connectors for every common kind of system or application, help desk incident
management system, e-mail systems, telephony platform ad more simplifies integration. Features such
as an auto-discovery engine, a dynamic work-flow engine, role-less user provisioning and managed user
enrollment subsystem expedite deployment.
The Management Suite is designed as identity management and access governance middleware, in the
sense that it presents a uniform user interface and a consolidated set of business processes to manage
user objects, identity attributes, security rights and credentials across multiple systems and platforms. This
is illustrated in Figure 2.
Figure 2: Management Suite Overview: Identity Middleware
Employees, contractors,
customers, and partners
Users Hitachi ID
Management Suite
Target Systems
Business processes
Synch./Propagation
Request/Authorization
Delegated Administration
Consolidated Reporting
User Objects
Attributes
Passwords
Privileges
Related Objects
Home Directories
Mail Boxes
PKI Certs.

The Management Suite includes several functional identity management and access governance modules:
• Hitachi ID Identity Manager – User provisioning, RBAC, SoD and access certification.
– Automated propagation of changes to user profiles, from systems of record to target systems.
– Workflow, to validate, authorize and log all security change requests.
– Automated, self-service and policy-driven user and entitlement management.
– Federated user administration, through a SOAP API (application programming interface) to a
user provisioning fulfillment engine.
– Consolidated access reporting.
Identity Manager includes the following additional features, at no extra charge:
– Hitachi ID Access Certifier – Periodic review and cleanup of security entitlements.
* Delegated audits of user entitlements, with certification by individual managers and applica-
tion owners, roll-up of results to top management and cleanup of rejected security rights.
– Hitachi ID Group Manager – Self service management of security group membership.
* Self-service and delegated management of user membership in Active Directory groups.
– Hitachi ID Org Manager – Delegated constuction and maintenance of Orgchart data.
* Self-service construction and maintenance of data about lines of reporting in an organization.
• Hitachi ID Password Manager – Self service management of passwords, PINs and encryption keys.
– Password synchronization.
– Self-service and assisted password reset.
– Enrollment and management of other authentication factors, including security questions, hard-
ware tokens, biometric samples and PKI certificates.
Password Manager includes the following additional features, at no extra charge:
– Hitachi ID Login Manager – Automated application logins.
* Automatically sign users into systems and applications.
* Eliminate the need to build and maintain a credential repository, using a combination of
password synchronization and artificial intelligence.
– Hitachi ID Telephone Password Manager – Telephone self service for passwords and tokens.
* Turn-key telephony-enabled password reset, including account unlock and RSA SecurID
token management.
* Numeric challenge/response or voice print authentication.
* Support for multiple languages.
• Hitachi ID Privileged Access Manager – Control and audit access to privileged accounts.
– Periodically randomize privileged passwords.
– Ensure that IT staff access to privileged accounts is authenticated, authorized and logged.
• Group Manager is available both as a stand-alone product and as a component of Identity Manager.

Figure 3: Components of the Management Suite
The relationships between the Management Suite components is illustrated in Figure 3 on Page 17.
Target systems supported out of the box include:

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 Ofﬁce
365, SOAP (generic).
OLAP, Hyperion, iLearn,
Caché, Success Factors,
VMWare vSphere.
SSH, Telnet, TN3270,
HTTP(S), SQL, LDAP,
command-line.
www.Hitachi-ID.com
500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com
File: / pub/ wp/ documents/ deploy-challenges/ deploy-challenges-6.tex
Date: June 12, 2008

Identity Management Deployment Best Practices

Recommandé

Recommandé

Contenu connexe

Plus de Hitachi ID Systems, Inc.

Plus de Hitachi ID Systems, Inc. (20)

Dernier

Dernier (20)

Identity Management Deployment Best Practices