Enterprise identity management systems bring many benefits 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 appropriate users have access to sensitive systems and data. Unfortunately, despite two generations of user administration technology, enterprise identity management systems from many vendors remain difficult 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 identity management systems, and offers solutions to help overcome each challenge. The solutions offered in this paper are implemented in the Hitachi ID Management Suite.
Addressing Deployment Challenges in Enterprise Identity Management © 2011 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 workﬂow deﬁnition 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 deﬁnition and user-to-role classiﬁcation and use of a single, dynamic authorization process rather than one workﬂow 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 Classiﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Workﬂow Deﬁnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5 Simplifying Deployment using Processes and Technology 8 5.1 Self-Service Login ID Reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2 Role Engineering and User Classiﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3 Dynamic Workﬂow Deﬁnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 1 Addressing Deployment Challenges in Enterprise Identity Management 2 Enterprise Identity Management Enterprise Identity and Access Management (IAM) is deﬁned as a set of processes and technologies to effectively and consistently manage modest numbers of users and entitlements across multiple systems. In this deﬁnition, there are typically signiﬁcantly 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 workﬂow and consolidated reporting. • Enterprise single sign-on – automatically ﬁlling 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 2 – 10,000 1–2 directories Users deﬁned before IAM Thousands Frequently only new users system is deployed Login ID reconciliation Existing accounts may have Single, consistent ID per user. different IDs on different systems. Data quality Orphan and dormant accounts Single or few objects per user. are common. Data Consistent data. Dormant inconsistencies between accounts often a problem. systems. User diversity Many users have unique Users ﬁt into just a few requirements. categories. In short, Enterprise IAM has fewer but more complex users. Extranet IAM has more users and higher transaction rates, but less complexity. © 2011 Hitachi ID Systems, Inc. All rights reserved. 2 Addressing Deployment Challenges in Enterprise Identity Management 3 Business Drivers and Use Cases for Enterprise Identity Manage- ment There are several business drivers for deploying an enterprise identity and access management 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 3 Addressing Deployment Challenges in Enterprise Identity Management 4 Deployment Challenges As deﬁned 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 signiﬁcant. 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 proﬁles 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 proﬁle 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 proﬁle data synchronization, consolidated access reporting and single-interface access termination be implemented. © 2011 Hitachi ID Systems, Inc. All rights reserved. 4 Addressing Deployment Challenges in Enterprise Identity Management Table 1: Login ID Reconciliation Options Scenario If: Then: Example: 1 Every user has just one login User objects can be connected jsmith on system A is the ID, used on every system. using login ID as a key. same user as jsmith on system B. 2 Every user object includes a User objects can be connected Employee ID or SSN may be globally unique key (an anchor using the anchor attribute, in populated on every system. attribute). place of the login ID. 3 Someone has already built or Login ID reconciliation is CSV ﬁle: "jsmith", is actively maintaining a map already done! Just load the "john_smith", ﬁle between login IDs on data. "smith01", · · · different systems. 4 None of the above is true. This is the most common The best choice will depend situation, especially in large on what data is available, how organizations with a history of complete and reliable it is, and mergers, acquisitions and on corporate culture. multiple, platform-speciﬁc 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 5 Addressing Deployment Challenges in Enterprise Identity Management 4.2 Role Engineering and User Classiﬁcation A common strategy to more efﬁciently and securely managing user access to systems is to deﬁne 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 deﬁnitions 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: • Deﬁne 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 speciﬁed 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 deﬁne 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 deﬁnition of thousands of roles – often as many roles as there are users. This complexity makes two key deployment tasks very difﬁcult, time consuming and costly: • Deﬁnition of sufﬁcient roles to encapsulate the access requirements of every user. • Classiﬁcation of every user into one or more roles. As a result, most role-based projects bog down in an interminable role engineering and user classiﬁcation phase. This problem is aggravated by the fact large organizations have signiﬁcant 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 deﬁnition and user classiﬁcation an ongoing challenge, rather than one associated just with initial system setup. The challenges posed by role engineering and user classiﬁcation typically lead either to stripped down deployments – e.g., covering just one or two systems, or applying just to speciﬁc populations of very regular users; or to IdM project abandonment. © 2011 Hitachi ID Systems, Inc. All rights reserved. 6 Addressing Deployment Challenges in Enterprise Identity Management 4.3 Workﬂow Deﬁnition 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 workﬂow 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 fulﬁllment 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 workﬂow 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 workﬂow is to embed a general-purpose business workﬂow engine in the user provisioning software. Customers can then deﬁne unique ﬂowcharts 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 ﬂowchart or state-table based solution is quite ﬂexible, it requires one ﬂowchart or table to be deﬁned 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 workﬂow 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 deﬁne and maintain the thousands of required ﬂowcharts can quickly become prohibitive. The challenges in administering a traditional workﬂow engine in the context of an enterprise user provision- ing system typically lead to delay or abandonment of this core functionality. © 2011 Hitachi ID Systems, Inc. All rights reserved. 7 Addressing Deployment Challenges in Enterprise Identity Management 5 Simplifying Deployment using Processes and Technology The seriousness of the deployment challenges in both ﬁrst 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 prompted to ﬁll in their proﬁles – for example by receiving an e-mail with an embedded URL. • Users sign into the registration system, using a primary login ID and password or other authentication factor. • Users are prompted to type their additional ID/password pairs. Each provided ID/password pair is compared against an automatically maintained inventory of login IDs drawn from target systems, to ﬁnd instances where the user-entered login ID appears on a system, and does not yet belong to a known user proﬁle. Management Suite then attempts to sign into that system with the user-entered password. If the login attempt succeeded, the user’s proﬁle 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 8 Addressing Deployment Challenges in Enterprise Identity Management 5.2 Role Engineering and User Classiﬁcation 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 deﬁning roles in terms of privileges on individual systems. The activities of role deﬁnition and user classiﬁcation 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 classiﬁcation is to avoid roles as the fundamental building block of user administration in the ﬁrst place. Hitachi ID Management Suite is designed to work without a reliance on role deﬁnitions or user classiﬁcation into roles. Indeed, there is no need to model the access proﬁles 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 – speciﬁc 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 certiﬁcation, 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 proﬁle and what kinds of accounts to provision on target systems. Automated user creation is run as a batch process, typically every night. – Self-service workﬂow: Managers or HR users can ﬁll in a form requesting a new user proﬁle and specifying a role (a collection of model accounts on target systems). These requests are routed to the appropriate authorizers, reviewed, approved and fulﬁlled 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 proﬁle. This is done using the Identity Manager consolidated user management console. © 2011 Hitachi ID Systems, Inc. All rights reserved. 9 Addressing Deployment Challenges in Enterprise Identity Management • Terminations – Scheduled terminations: Identity Manager can schedule automatic access termination, as an integral part of the initial user proﬁle. 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 ﬁle servers, tablespaces) are deleted, moved or assigned new owners. – Automatic change propagation: 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 ﬂagged 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. – Self-service workﬂow: Managers or HR users can ﬁll in a form requesting a termination. These requests are routed to the appropriate authorizers, reviewed, approved and fulﬁlled by Identity Manager. – Consolidated / delegated administration: 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 – Automatic change propagation: Identity Manager can be conﬁgured with rules, reﬂecting 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 workﬂow engine as requests for change approval. Automated access changes are normally batched – e.g., nightly. – Self-service workﬂow: 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 workﬂow 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, identiﬁes the ap- propriate group owner / authorizer and submits a workﬂow change request. © 2011 Hitachi ID Systems, Inc. All rights reserved. 10 Addressing Deployment Challenges in Enterprise Identity Management – Consolidated / delegated administration: 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 proﬁles – Access certiﬁcation: Hitachi ID Access Certiﬁer can be conﬁgured 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 Certiﬁer web page, where they: * See a list of their subordinates and indicate which user proﬁles should be removed, if any. * Open each subordinate’s proﬁle 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 proﬁles, accounts and entitlements that have been ﬂagged 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 certiﬁcation process for each of their subordinates that is also a manager. In this way, completed access certiﬁcation ﬂows 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. – Automatic change propagation: Identity Manager can be conﬁgured with rules, reﬂecting 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 workﬂow engine as requests for change approval. Automated access changes are normally batched – e.g., nightly. – Self-service workﬂow: Managers or HR users can ﬁll 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 fulﬁlled by Identity Manager. – Consolidated / delegated administration: 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 © 2011 Hitachi ID Systems, Inc. All rights reserved. 11 Addressing Deployment Challenges in Enterprise Identity Management or department of the new user, to deactivate a user. This is done using the Identity Manager consolidated user management console. 5.3 Dynamic Workﬂow Deﬁnition A workﬂow engine allows people and automated processes to request and authorize security changes directly, without involving security administrators. This is a key feature of any successful identity and access management system. Conﬁguring a workﬂow 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 workﬂow engine must scale to appropriately validate and authorize thousands of types of transactions. With a traditional workﬂow engine, this would require either thousands of ﬂowcharts or thousands of state tables (either way – unmanageable). To mitigate the challenge of arithmetic explosion in the number of required workﬂow processes, the Hitachi ID Management Suite workﬂow 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 deﬁne one ﬂowchart for every supported type of user proﬁle change on every target system, a single, built-in ﬂowchart is used to track change authorization for every possible change type, on every system. Organizations are instead asked to deﬁne business logic for a small number of control points in the master ﬂowchart: input validation, authorizer routing, reminder timing and automatic escalation routing. The same workﬂow 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 ﬂowcharts (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 workﬂow faster to develop, easier to maintain and clearer to audit. Dynamic workﬂow is illustrated in Figure 1 on Page 13. A dynamic workﬂow engine is signiﬁcantly easier to set up and maintain than the alternative: traditional workﬂow engines where a graphical ﬂow-chart or a state table is manually deﬁned for each and every one of the thousands of possible transaction types. Using its dynamic workﬂow engine, Management Suite can be conﬁgured and deployed in weeks, rather than months or years. Furthermore, the dynamic workﬂow engine in Management Suite requires minimal ongoing maintenance, resulting in a much lower TCO than a traditional workﬂow engine. © 2011 Hitachi ID Systems, Inc. All rights reserved. 12 Addressing Deployment Challenges in Enterprise Identity Management Exits exit programs: external pro- B.L. business logic: external pro- grams or scripting code that grams or scripting code that notifies other systems of modifies Hitachi ID Identity Hitachi ID Identity Manager Manager behavior. events. Requester Workflow Transaction Form Auto- Manager Manager input reminders Connector Hitachi ID B.L. Management Suite Validation / Delegated Approval Approved? completion authority form B.L. B.L. B.L. Authorizer Auto- routing escalation B.L. B.L. E-mail E-mail invitations notification Target Systems Authorizers Figure 1: Management Suite Dynamic Workﬂow © 2011 Hitachi ID Systems, Inc. All rights reserved. 13 Addressing Deployment Challenges in Enterprise Identity Management 6 Summary The three main challenges in deploying an enterprise identity management system are: • Data quality. • Role engineering. • Workﬂow 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 signiﬁcant 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 classiﬁcation or role deﬁnition. • Dynamic workﬂow, 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. © 2011 Hitachi ID Systems, Inc. All rights reserved. 14 Addressing Deployment Challenges in Enterprise Identity Management 7 Hitachi ID Systems Products The Hitachi ID Management Suite is a complete identity and access management solution that enables organizations to more securely and efﬁciently manage the user lifecycle across enterprise applications and systems. The Management Suite is designed to efﬁciently create, manage and deactivate user objects, identity at- tributes and security privileges across multiple 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. • Workﬂow invites business users to participate by completing their own proﬁles, 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 ofﬁcers and system administrators to analyze current state and review historical changes. A rich set of connectors are included, to easily integrate with over most common systems and applications and to manage authentication factors including passwords, challenge/response proﬁles, biometric samples, OTP devices, PKI certiﬁcates and smart cards. The Management Suite’s strengths are industry-leading ﬂexibility, 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 simpliﬁes integration. Features such as an auto-discovery engine, a dynamic work-ﬂow engine, role-less user provisioning and managed user enrollment subsystem expedite deployment. The Management Suite is designed as identity and access management 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 authentication factors across multiple systems and platforms. This is illustrated in Figure 2. Figure 2: Management Suite Overview: Identity Middleware Users Hitachi ID Target Systems Management Suite Business processes User Objects Related Objects Synch./Propagation Attributes Home Directories Request/Authorization Passwords Mail Boxes Employees, contractors, Delegated Administration Privileges PKI Certs. customers, and partners Consolidated Reporting The Management Suite includes several functional identity and access management modules: © 2011 Hitachi ID Systems, Inc. All rights reserved. 15 Addressing Deployment Challenges in Enterprise Identity Management • Hitachi ID Identity Manager – User provisioning, RBAC, SoD and access certiﬁcation. – Automated propagation of changes to user proﬁles, from systems of record to target systems. – Workﬂow, 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 fulﬁllment engine. – Consolidated access reporting. Identity Manager includes the following modules, at no extra charge: – Hitachi ID Access Certiﬁer – Periodic review and cleanup of security entitlements. * Delegated audits of user entitlements, with certiﬁcation 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 certiﬁcates. Password Manager includes the following modules, 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 artiﬁcial 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. The relationships between the Management Suite components is illustrated in Figure 3 on Page 17. © 2011 Hitachi ID Systems, Inc. All rights reserved. 16 Addressing Deployment Challenges in Enterprise Identity Management HITACHI ID MANAGEMENT SUITE Passwords ABC Users 123 Roles Security questions Accounts IDENTITY Smart cards MANAGER Groups Certificates ORG RBAC Tokens RS Secu A Identity attributes rID 159 MANAGER 759 Entitlements GROUP ACCESS Biometrics MANAGER CERTIFIER 010101 101001 100101 Encryption keys PRIVILEGED PASSWORD ACCESS MANAGER MANAGER TELEPHONE LOGIN PASSWORD MANAGER MANAGER Figure 3: Components of the Management Suite Target systems supported out of the box include: Directories: Servers: Databases: Any LDAP, AD, NDS, Windows 2000, 2003, 2008, Oracle, Sybase, SQL Server, eDirectory, NIS/NIS+. Samba, Novell, SharePoint. DB2/UDB, ODBC. Unix: Mainframes: Midrange: Linux, Solaris, AIX, HPUX, z/OS with RAC/F, ACF/2 or iSeries (OS400), OpenVMS. 24 more. TopSecret. ERP: Collaboration: Tokens, Smart Cards: JDE, Oracle eBiz, Lotus Notes, Exchange, RSA SecurID, SafeWord, PeopleSoft, SAP R/3, Siebel, GroupWise, BlackBerry ES. RADIUS, ActivIdentity, Business Objects. Schlumberger. WebSSO: Help Desk: HDD Encryption: CA Siteminder, IBM TAM, BMC Remedy, BMC SDE, McAfee, CheckPoint. Oracle AM, RSA Access HP Service Manager, CA Manager. Unicenter, Assyst, HEAT, Altiris, etc. 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 www.Hitachi-ID.com Date: June 12, 2008
Pages to are hidden for
"Addressing Deployment Challenges in Enterprise Identity Management©"Please download to view full document