Large Scale User Provisioning with Hitachi ID Identity Manager

Large Scale User Provisioning

with Hitachi ID Identity Manager

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

http://Hitachi-ID.com/

http://Hitachi.com/

This document introduces the business problems of user life-cycle management: slow and complex on-boarding; redundant administration effort; slow and unreliable deactivation; excess security entitlementsand inconsistent user profile data. It then describes how Identity Manager addresses these problems usingstreamlined business processes built on integrated technology. Finally, the benefits of enabling automationand self-service to improve user and security management processes are described.

Contents

1 Introduction 1

2 Business Challenges in Identity and Entitlement Management 2

3 Shared Infrastructure for Identity Management 4

3.1 Shared user directory (LDAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2 Shared management layer (IDM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Streamlined User and Entitlement Management Processes 6

4.1 User life-cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.2 Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.3 Integrations and Manual Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.3.1 Built-in Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.3.2 Scriptable Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.3.3 Implementer Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Hitachi ID Identity Manager Technology 10

5.1 Auto-Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.2 ID Mapping / Reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.3 Unique Approach to Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.4 Role Based Access Control and Segregation of Duties . . . . . . . . . . . . . . . . . . . . . 13

5.5 User Classes: Sets and Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.6 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.7 High-Performance, High-Availability Database Architecture . . . . . . . . . . . . . . . . . . . 19

6 Return on Investment 20

i

Large Scale User Provisioning with Identity Manager

1 Introduction

This document introduces the business problems of user life-cycle management: slow and complex on-boarding; redundant administration effort; slow and unreliable deactivation; excess security entitlementsand inconsistent user profile data. It then describes how Hitachi ID Identity Manager addresses these prob-lems using streamlined business processes built on integrated technology. Finally, the benefits of enablingautomation and self-service to improve user and security management processes are described.

Identity Manager is the user provisioning component of the Hitachi ID Management Suite.

The remainder of this document is organized as follows:

• Business Challenges in Identity and Entitlement Management

The motivation for deploying Identity Manager.

• Shared Infrastructure for Identity Management

How the intersection of many systems with many business processes create complexity and howimplementing shared processes to manage users and entitlements helps.

• Streamlined User and Entitlement Management Processes

Best practices for faster, simpler and more reliable processes to manage users and entitlementsacross the enterprise.

• Identity Manager Technology

The architecture and integrations that enable scalable, secure and manageable user managementprocesses.

• Return on Investment

A basic cost savings calculation that can be used to justify investment in Identity Manager.

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

Large Scale User Provisioning with Hitachi ID Identity Manager

2 Business Challenges in Identity and Entitlement Management

Several factors combine to make management of users and their security entitlements a growing challengefor many organizations:

• The number of systems and applications that users need to sign into is large and growing.

• String regulatory requirements create additional administration burden.

• Organizations cannot afford to increase IT support staff to cope with the ever-growing work-load.

This complexity is illustrated in Figure 1.

Business Processes

Systems and Applications

Users

Passwords

Groups

Attributes

IT Processes

Hire Retire New Application Retire ApplicationResign Finish Contract

ApplicationOperatingSystem

DatabaseDirectory E-mailSystem

ERP LegacyApp

Mainframe

Transfer Fire Start Contract Password Expiry Password Reset

Figure 1: Managing Each Application in its own Silo

The impact of this complexity is straightforward business problems:

• Security and regulatory compliance:

– The access deactivation process may be slow or unreliable, allowing users who have left theorganization to retain access.

– Access to privileged accounts, such as Administrator, root or sa is not consistently secured,leading to weak accountability and access to critical systems retained by departed users.

– Users accumulate security entitlements over time, ending up with the ability to commit fraud orother abuses.

• IT support cost:

– The IT support group must respond to a large volume login- and access-related calls.– A large number of security administration staff are needed to setup, manage and tear-down user

access in response to a changing organization.

• User service:



– It is difficult for users to figure out how to request access for new or reassigned users.– It takes too long to authorize and provision needed access rights.– Users must manage too many passwords and fill in too many login prompts.



3 Shared Infrastructure for Identity Management

To resolve the business problems that arise from the complexity introduced in Figure 1, it makes senseto implement a shared infrastructure for managing users and security entitlements. This is illustrated inFigure 2.

Business Processes

Systems and Applications

Users

Passwords

Groups

Attributes

IT Processes

Hire Retire New Application Retire ApplicationResign Finish Contract

ApplicationOperatingSystem

DatabaseDirectory E-mailSystem

ERP LegacyApp

Mainframe

Transfer Fire Start Contract Password Expiry Password Reset

Identity Management System

Figure 2: Externalizing the Management of Users and Entitlements

Using this approach, the links that connect every process to every system are severed, replaced with linksbetween each process and a shared IDM system, plus links between that system and each integratedapplication. If before there were N processes, M applications and N ×M links (chaos!), now there are justN +M links – much more manageable.

A shared infrastructure for users and entitlements can take on different forms, each of which has merit andall of which can be combined.

3.1 Shared user directory (LDAP)

The first approach to consolidating identity and access management – removing this function from appli-cation silos and moving it to a shared infrastructure – is to use a directory. Applications should then beconfigured to externalize user identification, authentication and authorization information to the directory.

This approach has merit, hence the popularity of LDAP. It also has limitations:

• Many systems are not compatible with LDAP, and cannot externalize their user/security databases.

• Some systems that can externalize user data can only do so for some attributes, and continue to haveinternal user profiles, which must still be managed directly.

• Many systems require data about users that is special to them, and would not benefit any other partof the IT infrastructure. If the data storage requirements of every application were added to a singleLDAP directory, then the schema would grow to thousands of attributes per user – clearly not practical.



• Some user-related data is confidential, and does not belong in a directory whose main design functionis to publish data.

Because of these limitations, LDAP has helped to slow the proliferation of user databases but organizationsstill have multiple systems to manage.

3.2 Shared management layer (IDM)

Where the physical user directory cannot be consolidated, it makes sense to at least consolidate the pro-cesses that create, modify and delete users and entitlements on multiple systems. This is the functionof a user provisioning system – to implement consistent processes which manage users and entitlementsacross multiple, heterogeneous directories of users and entitlements.

Hitachi ID Identity Manager is designed to provide a shared set of processes and infrastructure to manageusers and access across heterogeneous systems. It implements multiple processes that an organizationcan use to provision, update and deactivate user access to multiple systems.



4 Streamlined User and Entitlement Management Processes

4.1 User life-cycle

User movement through an organization is referred to as the user life-cycle. The processes involved varyfrom one classification of user to another and sometimes from one individual to another. For example,employees and contractors typically have different life-cycles. The process is referred to as a life-cycle,to emphasize that users who have left an organization may later return. The user life-cycle is illustratedgraphically in Figure 3.

Figure 3: User Lifecycle Management

In the context of an identity management system, the user life-cycle has external inputs and observableoutputs. Inputs are typically business events: hire an employee or contractor, change departments, termi-nate a user, etc. Outputs are the changes made on integrated systems and applications to reflect changingneeds: create a login ID, disable a login ID, add or remove security entitlement, etc.

Every user life-cycle begins with an on-boarding event – a new-hire for employees, start-of-engagement forcontractors, sign-up for customers and partners, enrollment for students, etc. This business event triggerscreation of one or more login accounts and other objects for the user in question.

Over time, users will make routine password changes and may periodically forget or lock out their pass-words, leading to a need for IT support (password reset or clear lockout).

As users move through an organization, they may change job functions, projects, locations, etc. Thesebusiness events often trigger the need for changing access rights. In other words, their access rights needto be managed over time.

All users leave eventually and their access rights must be deactivated. In many cases, objects belongingto the user – home directory with files, mail folder with archives messages, etc. – may have to be retainedfor a period of time before they are permanently deleted. Some data about users, such as their uniqueidentifiers, and whether it is OK to re-hire them, may be retained indefinitely, for future reference.

In some cases, a user who has departed will return to the organization and need to be re-activated, hencethe cycle in the user life-cycle.



Without automation, each of the above processes is handled separately, with no link between processesand with unique processes implemented for each system and application, managed by different IT staff,using different access administration tools. This is what leads to the complexity illustrated in Figure 1.

4.2 Business Processes

Hitachi ID Identity Manager implements several types of business processes when managing users:

• Auto-provisioning:Detect new user records on a system of record (such as HR) and automatically provision those userswith appropriate access on other systems and applications.

• Auto-deactivation:Detect deleted or deactivated users on an authoritative system and automatically deactivate thoseusers on all other systems and applications.

• Identity synchronization:Detect changes to personal data, such as phone numbers or department codes, on one system andautomatically make matching changes on other systems for the same user.

• Self-service requests:Enable users to update their own profiles (e.g., new home phone number) and to request new entitle-ments (e.g., access to an application or share).

• Delegated administration:Enable managers, application owners and other stake-holders to modify users and entitlements withintheir scope of authority.

• Access certification:Periodically invite managers and application owners to review lists of users and security entitlementswithin their scope of authority, flagging inappropriate entries for further review and removal.

• Authorization workflow:Validate all proposed changes, regardless of their origin and invite business stake-holders to approvethem before they are applied to integrated systems and applications.

• Consolidated reporting:Provide data about what users have what entitlements, what accounts are dormant or orphaned,change history, etc. across multiple systems and applications.

4.3 Integrations and Manual Fulfillment

Once a business process has produced a change that should be applied to an application, one of severalprocesses should push the change to the system in question. There are three ways to do this – use abuilt-in connector, use a scripted integration or ask a human being to make the change.



4.3.1 Built-in Connectors

Hitachi ID Identity Manager comes with built-in connectors for most common systems and applications, asillustrated in Figure 4.

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.

Figure 4: Target system types supported by Identity Manager

4.3.2 Scriptable Connectors

Hitachi ID Identity Manager includes a number of flexible connectors, each of which is used to script in-tegration with a common protocol or mechanism. These connectors allow organizations to quickly andinexpensively integrate Identity Manager with custom and vertical market applications. The ability to quicklyand inexpensively add integrations increases the value of the Identity Manager system as a whole.

There are flexible connectors to script interaction with:



API binding: Terminalemulation:

Web services: Back endintegration:

Command-line:

• C, C++• Java, J2EE• .NET• COM,

ActiveX• MQ Series

• SSH• Telnet• TN3270,

TN5250• Simulated

browser

• SOAP• WebRPC• Pure

HTTP(S)

• SQLInjection

• LDAPattributes

• Windows• Power Shell• Unix/Linux

Organizations that wish to write a completely new connector to integrate with a custom or vertical marketapplication may do so using whatever development environment they prefer (J2EE, .NET, Perl, etc.) andinvoke it as either a command-line program or web service.

If the organization develops their own integrations, an effort of between four hours and four days is typical.Alternately, Hitachi ID Systems offers fixed-cost custom integrations for a nominal fee.

4.3.3 Implementer Workflows

Hitachi ID Identity Manager supports the notion of an “implementer-style” target system, where a humansystem administrator is asked to create, modify or delete a user object on the target system, in place of anautomated Identity Manager connector.

Implementer-style target systems are useful in two main circumstances:

1. A custom or vertical-market target system either has a very small or very static user population. Inthese cases, the level of effort required to deploy automated integration to manage users on the targetsystem (typically on the order of several days) is not warranted given the small pay-back.

2. There are many target systems (hundreds, thousands) in-scope for the project and it is desirable togive users a “one stop shop” experience for security change requests, using Identity Manager, at thestart of deployment. This is preferable to asking users to refer to different request systems dependingon what kind of access they require.



5 Identity Manager Technology

5.1 Auto-Discovery

Hitachi ID Identity Manager includes an auto-discovery engine, which typically extracts information aboutusers and groups from target systems nightly.

• An auto-discovery engine extracts a full inventory of login IDs, from each target system, nightly.

• The auto-discovery engine extracts a list of all available groups from each target system, nightly.

• For groups that have been designated as “managed,” the auto-discovery engine also extracts fullgroup membership from the target systems.

• The auto-discovery engine automatically creates, updates and removes user profiles in the internalIdentity Manager database, based on the appearance of user accounts on systems that are consid-ered authoritative sources of Identity Manager IDs.

• Information such as last-login-date is used to identify dormant accounts, globally.

• Identity attributes configured as “managed” in Identity Manager are read from each target system, intothe Identity Manager identity cache.

Auto-discovery is incremental on systems that support this – such as Active Directory and most other LDAPdirectories. A full extract is produced on systems where incremental listing is not supported, and a delta iscalculated on the Identity Manager server before being loaded into the Identity Manager database. .

5.2 ID Mapping / Reconciliation

Every enterprise identity management and access governance system, regardless of its features, mustsupport login ID reconciliation. Users have login accounts and other records on various systems and thesehave to be attached to a single profile, in order to create a user-centric identity system. The process ofattaching non-standard login IDs and other user identifiers to a single profile is called login ID reconciliation.

Hitachi ID Identity Manager supports multiple options for login ID reconciliation, as follows:

• Automatically, typically by matching consistent login IDs.

• By matching other attributes such as an SSN or employee ID, where they are available.

• By drawing on an external source of data – for example, some organizations maintain a mapping tableor spreadsheet.

• Using a self-service reconciliation process.

When self-service login ID reconciliation is required, it works 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. Identity Manager 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 reconciliation is inexpensive (about 5 minutes per user), reliable, fully automated (users arereminded to register until they actually do) and very secure.

Both self-service and administrative login ID reconciliation are logged. Other forms of login ID reconciliationare typically batch oriented and can be configured with logging if required.

Note that attempts to reconcile login IDs by matching on attributes of user profiles on target systems areoften costly and/or insecure, especially when combined with a password management system:

• The only attribute that is commonly available on every system is a user’s full name. This may beinconsistent across systems and in many large organizations multiple users share the same full nameand sometimes the same location.

• Failure to automatically correlate an account leads to manual, administrative reconciliation, which isexpensive.

• Incorrect ID mapping allows one user to set another user’s password, which is a serious breach ofsecurity.

Where self-service login ID reconciliation is required, the process is both inexpensive (25,000 users spend-ing 5 minutes each costs nothing, while one consultant spending weeks or months is expensive) and error-free (since IDs are claimed with a validated password). This process is, to the best of Hitachi ID Systemsknowledge, unique.

5.3 Unique Approach to Workflow

Hitachi ID Identity Manager’s workflow automation engine streamlines the process of requesting and au-thorizing the creation of new accounts, as well as other security changes such as adding/removing groupmembership, changing attribute values, renaming or moving accounts, deleting or deactivating accountsand so on.

The Identity Manager workflow engine accepts change requests from the Identity Manager web portal, theIdentity Manager web services API or the auto-provisioning engine. Its main task is to validate changerequests and manage authorization of changes by business users, who are invited to review requests viae-mail and provide approval via the web portal.



Workflow in Identity Manager is loosely coupled, in the sense that request input (API, automation, webportal) is separated from form validation, which in turn is separated from authorizer selection and relatedlogic, which is separated from the process used to invite participants to respond to a change request. Thisloosely coupled architecture significantly simplifies configuration and maintenance by encouraging codereuse.

The workflow automation engine works as follows:

• Request input:

– Users can authenticate to the system and make change requests.

– Third party programs can submit change requests via a web services API.

– The unattended Identity Manager process used to implement auto-provisioning, auto-deactivationand identity synchronization can submit change requests programmatically.

– Change requests are formulated as changes to user profiles – the requester’s own (self-service)or another user’s (the recipient).

– Change requests may be to update profile attributes, add new accounts, add or remove groupmemberships, enable or disable accounts, etc.

– Plug-in programs can limit or alter requests – for example by limiting who can submit a given typeof request, for whom they can make requests and by validating or populating the contents of arequest.

• Request routing:

– Requests are automatically routed to appropriate authorizers, which are selected based on theidentities of the requester and recipient plus the specified operations and resources.

– All authorizers are invited at the same time.

1. Authorizers may delegate their responsibility in advance if they plan to be unavailable for anextended period.

2. Identity Manager can check an authorizer’s out-of-office status in an e-mail system (example:Exchange) and preemptively escalate the request to someone else.

– In most cases, a response is only required from a subset of the authorizers – for example, anyone of three people can approve a new account on a given application.

– Authorizers are notified by e-mail that their input is required. They click on a URL embedded inthe e-mail to respond.

– Reminders are sent to non-responsive authorizers.

– If an authorizer fails to respond after too many reminders, a new authorizer is selected by esca-lation logic.

• Authorization:

– Authorizers review requests using a web form, over a secure connection (HTTPS).

– Authorizers normally have to sign in before they can approve a request.



• Executing approved requests:

– Once sufficient approvals has been collected, Identity Manager will generally apply the requestedchanges to target systems.

– For un-integrated systems, Identity Manager can execute a separate workflow process to invite“implementers” (typically system administrators) to make the approved change manually. Re-minders, escalation and delegation apply to this workflow as well.

The built-in workflow engine is designed to get quick and reliable feedback from groups of business users,who may be individually unreliable. It supports:

• Concurrent invitations to multiple users to review a request.• Approval by N of M authorizers (N is fewer than M).• Automatic reminders to non-responsive authorizers.• Escalation from non-responsive authorizers to their alternates.• Scheduled delegation of approval responsibility from unavailable to alternate approvers.

5.4 Role Based Access Control and Segregation of Duties

Hitachi ID Identity Manager includes a complete infrastructure for managing user entitlements using rolebased access control (RBAC).

• Define Roles:

Administrators define roles in Identity Manager as collections of:

– Login accounts on specified target systems.

– Membership in groups on target systems.

• Role Hierarchy:

In addition to entitlements on target systems, roles can include other roles. This allows organizationsto define:

– Technical roles, consisting of entitlements on target systems.

– Business roles, consisting of other roles.

• Mandatory and Optional Components:

Roles may contain both mandatory and optional entitlements. Users who are assigned a role will,in general, be assigned all of the mandatory elements in a role. In addition, users who have beenassigned a role may request any of its optional components, which will be granted without need foradditional approvals.

• Role Assignment:

Users can be assigned zero or more roles:

– Some users can be outside the scope of the RBAC (role-based access control) infrastructure.



– Other users can be assigned exactly one role, representing their singular job function.

– Still other users can be assigned multiple roles, representing multiple job functions.

• Manual and Rule-based Assignment:

Roles may be assigned via a request process – i.e., a requesting user Uq asks that a receiving userUp be assigned role Rx. Such requests may be subject to policy and human approval before beingcompleted.

Roles can also be assigned automatically, by defining a class of users who should be assigned agiven role and associating that class with the role. In this case, both on a batch basis (e.g., nightly),with a throttle mechanism, and as user profiles are altered in a manner that changes their qualificationfor the user class, roles are automatically assigned or revoked.

• Role-based Change Requests:

Requests to create new user profiles can specify a role – either instead of or in addition to otherentitlements that the new user should be provisioned.

Requests relating to preexisting users can include role changes. Role changes may cause entitle-ments to be added, removed or left in place.

• Approved Exceptions:

Some users may have a legitimate reason to retain privileges beyond those called for in their assignedroles or may not need all of the privileges in that role. Identity Manager supports users who remainlegitimately out of compliance, through approved exceptions to role-based security entitlements.

• Controlled Enforcement:

Users can be flagged for role-based access control (RBAC) enforcement. This means that anyentitlements they have in violation of their assigned roles – either too many or too few – can bedetected and automatically remediated.

• Cascading Changes:

Identity Manager includes an RBAC enforcement engine, which is normally run as batch process every24 hours. This engine can detect users whose actual security entitlements are out of compliance withthe entitlements that their assigned roles predict. This may be because changes were made to theirprofiles outside of Identity Manager, or because the role’s definition has changed.

The RBAC enforcement engine detects non-compliant users and automatically submits workflowchange requests to bring users back into compliance.

One of the use cases this supports is cascading role changes: an administrator can change a role’sdefinition and commit the change. On the next automated enforcement run, the RBAC automationengine will automatically submit workflow requests to bring users into compliance with the new roledefinition. These requests may be auto-approved (depending on the organization’s policy), whichmeans that they may be applied to target systems immediately.

• Gradual Deployment:

It is impractical to deploy RBAC enforcement to every one of a large population of users, all at once.To avoid this, Identity Manager supports gradual activation of users for RBAC enforcement, allowingtime to educate users about the new system and troubleshoot errors in the RBAC model for a fewusers at a time.



• Role-Aware Access Certification:

Identity Manager supports certification of user entitlements at several levels of granularity:

– Fine-grained entitlements assigned to users – many checkboxes, based on data pulled directlyfrom target systems.

– Roles assigned to users – fewer checkboxes, representing groups of privileges.

– Approved exceptions to the privileges predicted for a user by policy, where the policy may be roleassignment or a segregation of duties rules.

Identity Manager includes what is probably the most advanced segregation of duties (SoD) engine available.The Identity Manager SoD engine supports:

• Policy definition:

– An SoD rule is defined as a toxic sets of entitlements.– Entitlements that participate in the SoD rule may themselves be roles, login IDs on specified

target systems or membership in specific security groups.– Users who have at least N of the M SoD entitlements are considered to be in violation.

This is a very general model. It supports rules such as “No user shall belong to more than 2 of these30 groups.”

• Approved exceptions:

– Users may be allowed to violate SoD rules, so long as an authorized person has approved theviolation.

– Access certification is used to periodically renew approved SoD exceptions.

This is a practical model. It allows organizations to knowingly violate rules where there is a strongbusiness reason to do so and where suitable compensating controls are in place.

• Proactive enforcement:

– Identity Manager’s SoD engine is an integral part of the workflow engine.– All change requests that pass through the Identity Manager workflow engine must either:

1. Satisfy all SoD rules (i.e., violate none); or

2. Include a request for an approved exception to every violated rule.– Requesters – via the Identity Manager UI, API or automation engine – simply cannot ask for

violations without also asking for an approved exception.

SoD should be proactive rather than after-the-fact, wherever possible. This is supported by IdentityManager.

• Reporting on out-of-band and pre-existing violations:

– There are several ways to bypass the Identity Manager pro-active SoD enforcement engine:

* Pre-existing conditions, where a user violated the SoD rule before Identity Manager wasimplemented.



* Pre-existing conditions, where a user violated the SoD rule before the rule was added toIdentity Manager.

* Out of band changes, made by administrators outside of Identity Manager.– In these cases, there is no general way for Identity Manager to know which of the offending

entitlements is inappropriate, so it cannot automatically remediate the violating users.– Instead, Identity Manager includes reports to identify violating users and help security staff make

appropriate remediating changes.

SoD reporting is the defense of last resort.

• Deep inspection:

– Consider an SoD rule: "no user may have roles R1 and R2."– Now assume that role R1 contains entitlements E1 and E2, while role R2 contains E3, E4.– Next, consider a user who already has E1, E2 and E3, but has never been explicitly assigned

R1. This user effectively has R1. If this user requests E4 or R2, the request should be flaggedas an SoD violation.

– The Identity Manager SoD engine, perhaps uniquely in the marketplace, will detect such vio-lations. In general, it supports enforcement where SoD rules may cover any combination ofindividual entitlements and nested roles.

To the best of Hitachi ID Systems’ knowledge, no other SoD engine will detect SoD violations wherethe SoD rule is defined in terms of one level of the role hierarchy but the violation takes place atanother level. This means that other SoD engines in reality only give organizations a false sense ofsecurity!

5.5 User Classes: Sets and Relationships

Hitachi ID Identity Manager includes a mechanism for classifying users – individually or as they relate toone another – called user classes.

When applied to individual users, user classes can examine a user’s accounts, identity attributes or securitygroup memberships to decide whether a user is in a given class. For example, help desk users may bemembers of an Active Directory group called it_support. Linux administrators may be in an LDAP OUcalled ou=Admins and be members of an AD group called linux_experts.

User classes can also formalize relationships between users. For example, an organization may have aregional IT support model, such that a given help desk user can only provide assistance, such as passwordresets, to users in his region. This is supported by defining user classes that relate two users – for example,the “helpdesk” user must be a member of an AD group called it_support and both users must have thesame values in the Division and Country-Code attributes.

User classes have multiple uses:

1. They are used in the Identity Manager operational security model, to assign rights for managingIdentity Manager to users.

2. In the delegated user administration security model, they determine what a given user can do onbehalf of another given user.



3. They are used in the Identity Manager access control model, to determine who can see and who canmodify what identity attributes, on whose profiles.

4. They are used to select users who will be invited to approve requests for changes to user profiles orentitlements.

5. They can be used by automated provisioning logic, to automatically assign roles or groups to users.

5.6 Network Architecture

Hitachi ID Identity Manager is designed for:

• Security:

Identity Manager is installed on hardened servers. All sensitive data is encrypted in storage andtransit. Strong authentication and access controls protect business processes.

• Scalability:

Multiple Identity Manager servers can be installed, using a built-in data replication facility. Workloadcan be distributed using any load-balancing technology (IP, DNS, etc.). The end result is a multi-master, distributed architecture that is very easy to setup, as replication is handled at the applicationlayer.

• Performance:

Identity Manager uses a normalized, relational and indexed database back end. All access to thedatabase is via stored procedures, which help to minimize communication overhead between theapplication and database. All Identity Manager code is native code, which provides a 2x to 10xperformance advantage as compared to Java or .NET

• Openness:

Open standards are used for inbound integration (SOAP) and outbound communications (SOAP,SMTP, HTTP, etc.).

• Flexibility:

Both the Identity Manager user interface and all functionality can be customized to meet enterpriserequirements.

• Low TCO:

Identity Manager is easy to set up and requires minimal ongoing administration.

Figure 5 on Page 18 illustrates the Identity Manager network architecture:

• Users normally access Identity Manager using HTTPS from a web browser.

• Multiple Identity Manager servers may be load balanced using either an IP-level device (e.g., CiscoLocal Director, F5 Big/IP) or simply using DNS round-robin distribution.



UserPasswordSynchTriggerSystems

Load Balancer

SMTP or Notes Mail

IncidentManagementSystem System of

Record

IVRServer

ReverseWeb Proxy

Target Systemswith local agent:OS/390, Unix, older RSA

Firewall

TCP/IP + AES

Various Protocols

Secure Native Protocol

HTTPS

Remote Data Center

Firewall

Local Network

Target Systemswith remote agent:AD, SQL, SAP, Notes, etc

Target SystemsEmails

Tickets

Lookup & Trigger

Native

password

change

AD, Unix,

OS/390,

LDAP,

AS400

Validate PW

Web Services

Proxy Server(if needed)

Hitachi IDApplicationServer(s)

SQL/Oracle

SQLDB

SQLDB

Cloud-hosted,

SaaS apps

VPNServer

Figure 5: Network architecture diagram

• Users may call an IVR (interactive voice response) system with a telephone and be authenticatedeither using touch-tone input of personal information or using a voice print. Authenticated users mayinitiate a password reset.

• Identity Manager connects to most target systems using their native APIs (application programminginterfaces) and protocols and thus requires no software to be installed locally on those systems.

• Local agents are provided and recommended for Unix servers and z/OS mainframes. Use of theseagents improves transaction security, speed and concurrency.

• A local agent is mandatory on older RSA SecurID servers (version 7.x and later exposes a remoteAPI).

• Where target systems are remote and communication with them is slow, insecure or both, a IdentityManager proxy server may be co-located with the target system in the remote location. In this case,servers in the main Identity Manager server cluster initiate fast, secure connections to the remoteproxies, which decode these transactions and forward them to target systems locally, using native,slow and/or insecure protocols.

• Identity Manager can look up and update user profile data in an existing system, including HRdatabases (ODBC), directories (LDAP) and meta-directories (e.g., WMI to Microsoft ILM).

• Identity Manager can send e-mails to users asking them to register or to notify them of events impact-ing their profiles. Over 114 events can trigger e-mail notification.

• Identity Manager can create tickets on most common incident management systems, either recordingcompleted activity or requesting assistance (security events, user service follow-up, etc.). Over 114events can trigger ticket generation. Binary integrations are available for 17 help desk applicationsand open integration is possible using mail, ODBC, SQL and web services.



5.7 High-Performance, High-Availability Database Architecture

All Hitachi ID Identity Manager components, including user interface screens, reports, service programsand command-line / batch processes access the database using the same architecture:

1. A client component calls a client wrapper library.

2. The client wrapper library communicates with a Identity Manager database service using an IPC.This may be shared memory (same server, very fast) or TCP/IP socket (remote server, encryptedcommunication using a shared key).

3. The Identity Manager database service authenticates clients, checks what they are allowed to see/doand invokes stored procedures to read from and write to the database.

4. Stored procedures, installed on the relational database back end (e.g., Microsoft SQL Server or OracleDatabase Server), access data in the local schema and return results.

5. Calls to stored procedures which insert, delete or update records are forwarded by the databaseservice to its replicating peers, so that each database instance may be kept up to date.

6. Data returned by stored procedures is passed back to the calling program.

This architecture is advantageous for several reasons:

1. Built-in data replication makes it easy to configure Identity Manager in a high-availability, fault-tolerantarchitecture.

2. Using stored procedures rather than direct SQL calls significantly improves performance while leavingopen the possibility of future schema changes.

3. Using a Identity Manager database service to front-end the physical database enables robust accesscontrols and easy-to-manage database replication.

4. Wrapping data calls in an encrypted protocol enables secure configuration in a distributed environ-ment, over untrusted network segments.



6 Return on Investment

Hitachi ID Identity Manager strengthens security by:

• Quickly and reliably removing access to all systems and applications when users leave an organiza-tion.

• Finding and helping to clean up orphan and dormant accounts.

• Assigning standardized access rights, using roles and rules, to new and transitioned users.

• Enforcing policy regarding segregation of duties and identifying users who are already in violation.

• Ensuring that changes to user entitlements are always authorized before they are completed.

• Asking business stake-holders to periodically review user entitlements and either certify or removethem, as appropriate.

• Reducing the number and scope of administrator-level accounts needed to manage user access tosystems and applications.

• Providing readily accessible audit data regarding current and historical security entitlements, includingwho requested and approved every change.

Identity Manager reduces the cost of managing users and security entitlements:

• Auto-provisioning and auto-deactivation leverage data feeds from HR systems to eliminate routine,manual user setup and tear-down.

• Self-service eliminates IT involvement in simple updates to user names, phone numbers and ad-dresses.

• Delegated administration moves the responsibility for requesting and approving common changes,such as for new application or folder access, to business users.

• Identity synchronization means that corrections to user information can be made just once, on anauthoritative system and are then automatically copied to other applications.

• Built-in reports make it easier to answer audit questions, such as “who had access to this system onthis date?” or “who authorized this user to have this entitlement?”

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/white/idsynch/ids-white-10.texDate: 2011-04-12

http://Hitachi-ID.com/