Identity Management Deployment Best Practices

Addressing Deployment Challenges

in Enterprise Identity Management

© 2014 Hitachi ID Systems, Inc. All rights reserved.

http://Hitachi-ID.com/

http://Hitachi.com/

This Hitachi ID Systems white paper describes the major challenges in deploying an enterprise identitymanagement (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 manyyears.

This paper presents practical solutions to the design and implementation of an IdM system, to overcomethese challenges. Solutions include auto-discovery and self-service login ID reconciliation, minimizing theneed for role definition and user-to-role classification and use of a single, dynamic authorization processrather 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 benefits to large organizations and are increasinglya required feature in today’s regulatory environment. Some of the important features of enterprise IdMinclude:

• Improved user productivity, due to reduced wait for new and updated systems access and fewerauthentication problems.

• Lower security administration cost, as the bulk of user management is automated or delegated tobusiness 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 managementsystems from many vendors remain difficult to deploy and costly to maintain. Many IdM projects end eitherin 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 toeffectively and consistently manage modest numbers of users and entitlements across multiple systems. Inthis definition, there are typically significantly fewer than a million users, but users typically have access tomultiple 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 webapplications.

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

Characteristic Enterprise IAM (typical) Extranet IAM (typical)

Number of users under 1 million over 1 million

Number of systems anddirectories

2 – 10,000 1 – 2

Users defined before IAMsystem is deployed

Thousands Frequently only new users

Login ID reconciliation Existing accounts may havedifferent IDs on differentsystems.

Single, consistent ID per user.

Data quality Orphan and dormant accountsare common. Datainconsistencies betweensystems.

Single or few objects per user.Consistent data. Dormantaccounts often a problem.

User diversity Many users have uniquerequirements.

Users fit into just a fewcategories.

In short, Enterprise IAM has fewer but more complex users. Extranet IAM has more users and highertransaction 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 governancesystem, 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 arequite 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 requirementsand 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 loginIDs and profiles that belong to each user must be connected to one another. Until this is done, it will beimpossible to synchronize passwords or other data attributes, to report on the access rights of a single useracross 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 humanowners, is called login ID reconciliation. While the process may be simple in principle, reconciling largenumbers 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 inscenario 1 have no login ID reconciliation problem at all. Organizations in scenario 4 frequently undertakea manual data cleansing project, to populate an anchor attribute or rename login IDs on key systems tobring them into compliance with an enterprise-wide naming standard. Such data cleansing projects cantake 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 deploymentcost overruns that reach into the millions of dollars.

Only after login ID reconciliation is complete can enterprise IdM functions such as password synchronizationand reset, user profile data synchronization, consolidated access reporting and single-interface accesstermination be implemented.



Table 1: Login ID Reconciliation Options

Sce

nario

If: Then: Example:

1 Every user has just one loginID, used on every system.

User objects can be connectedusing login ID as a key.

jsmith on system A is thesame user as jsmith onsystem B.

2 Every user object includes aglobally unique key (an anchorattribute).

User objects can be connectedusing the anchor attribute, inplace of the login ID.

Employee ID or SSN may bepopulated on every system.

3 Someone has already built oris actively maintaining a mapfile between login IDs ondifferent systems.

Login ID reconciliation isalready done! Just load thedata.

CSV file: "jsmith","john_smith","smith01", · · ·

4 None of the above is true. This is the most commonsituation, especially in largeorganizations with a history ofmergers, acquisitions andmultiple, platform-specificsecurity administration groups.There are three options toreconcile login IDs in this case:

• Correlate login IDs ondifferent systems usingexact or approximatematch on full name asthe anchor attribute.

• Embark on a datacleanup project, topopulate some otheranchor attribute or tonormalize login IDs onevery system.

• Employ self-service, toget login ID reconciliationdata from the usersthemselves.

The best choice will dependon what data is available, howcomplete and reliable it is, andon 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, thatencapsulate the access requirements of groups of users. User access to systems can then be managedsimply by assigning users to the appropriate roles. Moreover, as IT infrastructure and security policy arechanged, role definitions can be adjusted, and user access to systems will automatically be updated tomatch.

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 everytarget 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 actuallyhave on target systems.

• Correct actual privileges to match those predicted by roles, either automatically or after human reviewand approval.

Most second-generation user provisioning products are based on this policy-based approach. They defineroles as a fundamental building block of user administration and use roles to control, rather than just addto, 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 ofthousands 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 classificationphase.

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 classificationan 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 downdeployments – e.g., covering just one or two systems, or applying just to specific populations of very regularusers; or to IdM project abandonment.



4.3 Workflow Definition

An integral component of many identity management systems is the empowerment of business users tomanage 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 isinstalled, that includes:

• Web forms where business users may request security changes, such as creating new users oraccounts for existing users, changing user attributes or entitlements on one or more systems, ordeactivating 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 theabove 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 workflowengine in the user provisioning software. Customers can then define unique flowcharts or state tables thatcapture the validation, authorization, reminder, escalation and delegation logic for every kind of changerequest.

The problem with this open-ended approach is scalability. While a flowchart or state-table based solutionis 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 kindsof users, mediate access into and out of 20 different security groups, and support another 10 miscellaneoustransaction types, such as user deactivation, reactivation, renaming and attribute changes. This amountsto 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 andeffort 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 engineeredfrom the ground up to avoid or resolve these problems. These are the key components required for asuccessful 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 widelypopulated anchor attribute to which different user objects can be reconciled, self-service can be used toquickly, 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 embeddedURL.

• Users sign into the registration system, using a primary login ID and password or other types ofcredentials.

• 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 findinstances where the user-entered login ID appears on a system and does not yet belong to a knownuser 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-enteredlogin ID.

Self-service login ID reconciliation has major advantages over data cleansing projects and over approximatematching on attributes such as full names:

• The process is inexpensive to implement, as it only requires a few minutes from each of thousands ofusers. 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 erroneousmatches, which will later constitute security breaches, including allowing one user to reset another’spassword.



5.2 Role Engineering and User Classification

As mentioned earlier, policy-based user provisioning depends on a model of user privileges. The mainelement of user privilege modeling is classifying users into roles, and defining roles in terms of privilegeson 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., banktellers, 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 roleengineering or user classification is to avoid roles as the fundamental building block of user administrationin the first place. Hitachi ID Management Suite is designed to work without a reliance on role definitions oruser 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 abuilding block for enforcing security policy. Requests for new access privileges may include a combinationof 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 theaccess 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 aprocess for access certification, where managers and application owners are periodically asked to reviewthe security rights of users in their area of responsibility, and to either approve (certify) or reject (requestdeletion) 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 aredetected, rules are applied by Identity Manager to decide whether to create a new user profileand 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 (acollection of model accounts on target systems). These requests are routed to the appropriateauthorizers, reviewed, approved and fulfilled by Identity Manager.

– Consolidated / delegated administration:

An existing change control process may lead a security administrator, either centrally or closer tothe location or department of the new user, to create a new user profile. This is done using theIdentity Manager consolidated user management console.



• Terminations

– Scheduled terminations:

Identity Manager can schedule automatic access termination, as an integral part of the initialuser profile. Scheduled terminations are normally preceded by e-mails asking the user and/or theuser’s direct manager to verify or postpone the termination. At the time of termination, systemsaccess 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, acorporate directory or a contractor management application. These may appear as either usersthat have been removed or users that have been flagged as terminated. When terminations aredetected, rules are applied by Identity Manager to decide whether and where to also terminatesystems 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 tothe appropriate authorizers, reviewed, approved and fulfilled by Identity Manager.


An existing change control process, possibly as simple as a management request for urgentaccess termination, may lead a security administrator, either centrally or closer to the locationor department of the new user, to deactivate a user. This is done using the Identity Managerconsolidated user management console.

• Users that require new privileges


Identity Manager can be configured with rules, reflecting access management policy, that lay outaccess privileges (login accounts, account attributes and group memberships) that each usershould have on each target system.

Changes on a system of record (HR, directory, etc.) trigger these rules and Identity Managercompares the predicted access rights of a user against the rights that the user actually has ontarget systems. Differences are then either applied directly to target systems or to the workflowengine 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 forwardschange 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 whatgroup they would like to join can browse for resources (e.g., folders on shares, printers) throughthe 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 accessrights, may lead a security administrator, either centrally or closer to the location or department ofthe new user, to create new accounts, attach an existing user to groups or modify the attributes ofan existing user account. This is done using the Identity Manager consolidated user managementconsole.

• 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 anembedded 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. Managersare 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 onthat target system). Managers are required to review each security entitlement and selectthose that are no longer required, thereby requesting deletion of those entitlements.

* User profiles, accounts and entitlements that have been flagged as “no longer required” arereviewed 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 theirsubordinates that is also a manager. In this way, completed access certification flows upthrough an organization, ultimately leading to the CEO or CFO being able to attest to the factthat 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 outaccess privileges (login accounts, account attributes and group memberships) that each usershould have on each target system.

Changes on a system of record (HR, directory, etc.) trigger these rules and Identity Managercompares the predicted access rights of a user against the rights that the user actually has ontarget systems. Differences are then either applied directly to target systems or to the workflowengine 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 ofusers 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 ina 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 Managerconsolidated 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 managementand access governance system.

Configuring a workflow engine can be challenging. As an identity management or user provisioning systemdeployment scales up to support hundreds of target systems, with hundreds of kinds of updates supportedon each one, the workflow engine must scale to appropriately validate and authorize thousands of types oftransactions.

With a traditional workflow engine, this would require either thousands of flowcharts or thousands of statetables (either way – unmanageable).

To mitigate the challenge of arithmetic explosion in the number of required workflow processes, the Hitachi IDManagement Suite workflow engine is dynamic, in the sense that a single, powerful state machine is used totrack authorizations for every possible change (transaction) on every target system. Plug-in programs alterthe behavior of the state machine, using business logic to validate inputs, route requests to the appropriateauthorizers 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 changeon every target system, a single, built-in flowchart is used to track change authorization for every possiblechange type, on every system. Organizations are instead asked to define business logic for a small numberof control points in the master flowchart: input validation, authorizer routing, reminder timing and automaticescalation 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 madefor validation and authorization in every case.

This approach eliminates the need for organizations to graphically draw out and maintain thousands offlowcharts (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 blocksof general-purpose business logic, for tasks such as input validation, authorizer routing and escalation. Thesame logic applies globally, which makes dynamic workflow faster to develop, easier to maintain and clearerto 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: traditionalworkflow engines where a graphical flow-chart or a state table is manually defined for each and every oneof the thousands of possible transaction types.

Using its dynamic workflow engine, Management Suite can be configured and deployed in weeks, ratherthan months or years. Furthermore, the dynamic workflow engine in Management Suite requires minimalongoing maintenance, resulting in a much lower TCO than a traditional workflow engine.



Requester

Forminput

Validation /completion

Authorizerrouting

Auto-reminders

Delegatedauthority

Auto-escalation

E-mailnotification

Approved?Approvalform

E-mailinvitations Target Systems

WorkflowManager

Transaction ManagerConnector

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 IDManagement Suite

Figure 1: Management Suite Dynamic Workflow



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 manycases.

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 tonumerous 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 credentialsacross systems and applications. Organizations deploy the Management Suite to strengthen controls, meetregulatory 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. Thisis 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 changesand reviewing the current state of users and privileges.

• Consolidated management enables security staff to manage access with a user-centric, rather thanapplication-centric view.

• Password synchronization and enterprise single sign-on reduce the number of passwords that usersmust remember and type.

• Reports enable auditors, security officers and system administrators to analyze current state andreview historical changes.

A rich set of connectors are included, to easily integrate with most common systems and applications andto 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 ManagementSuite to their needs. Built-in connectors for every common kind of system or application, help desk incidentmanagement system, e-mail systems, telephony platform ad more simplifies integration. Features suchas an auto-discovery engine, a dynamic work-flow engine, role-less user provisioning and managed userenrollment subsystem expedite deployment.

The Management Suite is designed as identity management and access governance middleware, in thesense that it presents a uniform user interface and a consolidated set of business processes to manageuser objects, identity attributes, security rights and credentials across multiple systems and platforms. Thisis 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./PropagationRequest/AuthorizationDelegated AdministrationConsolidated Reporting

User Objects

AttributesPasswordsPrivileges

Related Objects

Home DirectoriesMail BoxesPKI 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 SecurIDtoken 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 orTopSecret.

iSeries (OS400), OpenVMS.

ERP: Collaboration: Tokens, Smart Cards:

JDE, Oracle eBiz,PeopleSoft, SAP R/3, SAPECC 6, Siebel, BusinessObjects.

Lotus Notes, Exchange,GroupWise, BlackBerry ES.

RSA SecurID, SafeWord,RADIUS, ActivIdentity,Schlumberger.

WebSSO: Help Desk: HDD Encryption:

CA Siteminder, IBM TAM,Oracle AM, RSA AccessManager.

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

McAfee, CheckPoint,BitLocker, PGP.

SaaS: Miscellaneous: Extensible:

Salesforce.com, WebEx,Google Apps, MS Office365, 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: [email protected]

File: / pub/ wp/ documents/ deploy-challenges/ deploy-challenges-6.texDate: June 12, 2008

http://Hitachi-ID.com/

Identity Management Deployment Best Practices

Technology

Transcript of Identity Management Deployment Best Practices