Skip to main content

Large Scale IAM with Hitachi ID Identity Manager

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


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

Identity Manager is the user provisioning component of the Hitachi ID Identity and Access 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 how implementing 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 entitlements across the enterprise.

  • Identity Manager Technology

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

  • Return on Investment

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

Business Challenges in Identity and Entitlement Management

Several factors combine to make management of users and their security entitlements a growing challenge for 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 [link].


    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 the organization 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 or other 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.

Shared Infrastructure for Identity Management

To resolve the business problems that arise from the complexity introduced in Figure (_label_fig:silo-processes), it makes sense to implement a shared infrastructure for managing users and security entitlements. This is illustrated in Figure [link].


    Externalizing the Management of Users and Entitlements

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

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

Shared user directory (LDAP)

The first approach to consolidating identity and access management -- removing this function from application silos and moving it to a shared infrastructure -- is to use a directory. Applications should then be configured 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 have internal 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 part of the IT infrastructure. If the data storage requirements of every application were added to a single LDAP 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 function is to publish data.

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

Shared management layer (IDM)

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

Identity Manager is designed to provide a shared set of processes and infrastructure to manage users and access across heterogeneous systems. It implements multiple processes that an organization can use to provision, update and deactivate user access to multiple systems.

Streamlined User and Entitlement Management Processes

User life-cycle

User movement through an organization is referred to as the user life-cycle. The processes involved vary from 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 illustrated graphically in Figure [link].


    User Lifecycle Management

In the context of an identity management system, the user life-cycle has external inputs and observable outputs. Inputs are typically business events: hire an employee or contractor, change departments, terminate a user, etc. Outputs are the changes made on integrated systems and applications to reflect changing needs: 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 for contractors, sign-up for customers and partners, enrollment for students, etc. This business event triggers creation 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 passwords, 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. These business events often trigger the need for changing access rights. In other words, their access rights need to be managed over time.

All users leave eventually and their access rights must be deactivated. In many cases, objects belonging to the user -- home directory with files, mail folder with archives messages, etc. -- may have to be retained for a period of time before they are permanently deleted. Some data about users, such as their unique identifiers, 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, hence the cycle in the user life-cycle.

Without automation, each of the above processes is handled separately, with no link between processes and 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 (_label_fig:silo-processes).

Business Processes

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

  • Auto-provisioning, deactivation:
    Detect new user records on a system of record (SoR, such as HR) and automatically provision those users with appropriate access on other systems and applications. Detect deleted or deactivated users on the SoR and automatically deactivate those users across integrated systems and applications.
  • Self-service requests:
    Enable users to update their own profiles (e.g., new home phone number) and to request new entitlements (e.g., access to an application or share).
  • Delegated administration:
    Enable managers, application owners and other stake-holders to modify users and entitlements within their scope of authority.
  • Access certification:
    Periodically invite managers and application owners to review users and security entitlements within their scope of authority, flagging inappropriate entries for removal.
  • Identity synchronization:
    Detect changes to attributes, such as phone numbers or department codes on one system and automatically copy to others.
  • Authorization workflow:
    Validate all proposed changes, regardless of their origin and invite business stake-holders to approve them before they are applied to integrated systems and applications.

Integrations and Manual Fulfillment

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

Built-in Connectors

Identity Manager comes with built-in connectors for most common systems and applications, as illustrated in Figure [link].




Any LDAP, AD, NDS, eDirectory, NIS/NIS+.

Windows 2000--2012, Samba, NDS, SharePoint.

Oracle, Sybase, SQL Server, DB2/UDB, ODBC, Informix, Progress.




Linux, Solaris, AIX, HPUX, 24 more variants.

z/OS with RAC/F, ACF/2 or TopSecret.

iSeries (OS400), OpenVMS.



Tokens, Smart Cards:

JDE, Oracle eBiz, PeopleSoft, SAP R/3, SAP ECC 6, Siebel, Business Objects.

Lotus Notes, Exchange, GroupWise, BlackBerry ES.

RSA SecurID, SafeWord, RADIUS, ActivIdentity, Schlumberger.


Help Desk:

HDD Encryption:

CA Siteminder, IBM TAM, Oracle AM, RSA Access Manager.

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

McAfee, CheckPoint (PointSec), Microsoft (BitLocker), Symantec (PGP).



Extensible:, WebEx, Google Apps, MS Office 365, Concur, AWS, vCloud, SOAP (generic).

OLAP, Hyperion, iLearn, Caché, Success Factors, VMware vSphere. Cisco IOS, Juniper JUNOS, F5, iLO cards, DRAC cards, RSA cards, etc.

SSH, Telnet, TN3270, HTTP(S), SQL, LDAP, command-line.


    Target system types supported by Identity Manager

Scriptable Connectors

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

There are flexible connectors to script interaction with:

API binding:

Terminal emulation:

Web services:

Back end integration:


  • C, C++
  • Java, J2EE
  • .NET
  • COM, ActiveX
  • MQ Series

  • SSH
  • Telnet
  • TN3270, TN5250
  • Simulated browser

  • SOAP
  • WebRPC
  • Pure HTTP(S)

  • SQL Injection
  • LDAP attributes

  • Windows
  • Power Shell
  • Unix/Linux


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

If Hitachi ID Systems customer 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.

Implementer Workflows

Identity Manager supports the notion of an "implementer-style" target system, where a human system administrator is asked to create, modify or delete a user object on the target system, in place of an automated 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. In these cases, the level of effort required to deploy automated integration to manage users on the target system (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 to give users a "one stop shop" experience for security change requests, using Identity Manager, at the start of deployment. This is preferable to asking users to refer to different request systems depending on what kind of access they require.

Individual target systems or applications may also be configured in a hybrid mode. For example, a CSV file might be used to enumerate users, groups and/or group memberships but a human implementer may be invited to make updates manually.

Identity Manager Technology


Identity Manager includes an auto-discovery engine, used to extract a list of accounts, groups, group memberships and more from every integrated system. The discovery process is scheduled to run regularly -- usually every 24 hours.

  • Every Identity Manager connector supports list operations.
  • By default, auto-discovery is scheduled to run every night. Some organizations choose to schedule it more frequently.
  • When connecting to each managed system, an inventory of all login IDs (accounts) and all available security groups or roles is always extracted.
  • On systems that support this, incremental listing is used to reduce runtime -- i.e., list only IDs that have been added, changed or moved since the last list.
  • The membership in those security groups or application roles which have been marked as 'Managed' in Identity Manager is extracted.
  • Connections to target systems are made in a massively multi-threaded fashion, to minimize runtime.

The list operation in all Identity Manager connectors writes list files to the filesystem of the relevant Identity Manager server. Once all list files have been generated, a separate process determines what changed in each list file and loads appropriate updates into the Identity Manager database schema. This includes:

  • Updating group, account, group membership, attribute and related data in the database, to reflect current state on target systems.
  • Creating new or disabling existing Identity Manager user profiles, where new accounts were discovered on systems marked as 'source of profile' or existing profile accounts were disabled or disappeared.
  • Triggering automated processes, such as provisioning network access in response to newly discovered HR records.
  • Detecting out of band administrative changes, such as placing a user into an Administrators group and responding with e-mail alerts, workflow requests to undo or approve the change, etc.

The entire process can take from a few minutes to run, in smaller deployments, to 2--3 hours to run, in large enterprises with tens of thousands of users and hundreds of integrated systems.

ID Mapping / Reconciliation

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

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 table or 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 embedded URL.
  • Users sign into the registration system, using a primary login ID and password or other types of credentials.
  • Users are asked to type their additional ID/password pairs. Each provided ID/password pair is compared against an automatically maintained inventory of login IDs drawn from target systems, to find instances where the user-entered login ID appears on a system and does not yet belong to a known user profile. 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-entered login ID.

Self-service reconciliation is inexpensive (about 5 minutes per user), reliable, fully automated (users are reminded to register until they actually do) and very secure.

Both self-service and administrative login ID reconciliation are logged. Other forms of login ID reconciliation are 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 are often 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 be inconsistent across systems and in many large organizations multiple users share the same full name and sometimes the same location.

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

  • Incorrect ID mapping allows one user to set another user's password, which is a serious breach of security.

Where self-service login ID reconciliation is required, the process is both inexpensive (25,000 users spending 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 Systems knowledge, unique.

Unique Approach to Workflow

Identity Manager's workflow automation engine streamlines the process of requesting and authorizing the creation of new accounts, as well as other security changes such as adding/removing group membership, changing attribute values, renaming or moving accounts, deleting or deactivating accounts and so on.

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

Workflow in Identity Manager is loosely coupled, in the sense that request input (API, automation, web portal) is separated from form validation, which in turn is separated from authorizer selection and related logic, which is separated from the process used to invite participants to respond to a change request. This loosely coupled architecture significantly simplifies configuration and maintenance by encouraging code reuse.

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-deactivation and 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 group memberships, enable or disable accounts, etc.
    • Plug-in programs can limit or alter requests -- for example by limiting who can submit a given type of request, for whom they can make requests and by validating or populating the contents of a request.

  • Request routing:
    • Requests are automatically routed to appropriate authorizers, which are selected based on the identities 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 an extended 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, any one 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 in the 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 escalation 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 requested changes 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. Reminders, 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.

Role Based Access Control and Segregation of Duties

Identity Manager includes a complete infrastructure for managing user entitlements using role based 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 organizations to 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 been assigned a role may request any of its optional components, which will be granted without need for additional approvals.

  • Role Assignment:

    Users can be assigned zero or more roles:

    • Some users can be outside the scope of the RBAC 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 U_q asks that a receiving user U_p be assigned role R_x. Such requests may be subject to policy and human approval before being completed.

    Roles can also be assigned automatically, by defining a class of users who should be assigned a given 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 qualification for 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 other entitlements that the new user should be provisioned.

    Requests relating to preexisting users can include role changes. Role changes may cause entitlements 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 assigned roles or may not need all of the privileges in that role. Identity Manager supports users who remain legitimately 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 any entitlements they have in violation of their assigned roles -- either too many or too few -- can be detected and automatically remediated.

  • Cascading Changes:

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

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

    One of the use cases this supports is cascading role changes: an administrator can change a role's definition and commit the change. On the next automated enforcement run, the RBAC automation engine will automatically submit workflow requests to bring users into compliance with the new role definition. These requests may be auto-approved (depending on Hitachi ID Systems customer's policy), which means 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, allowing time to educate users about the new system and troubleshoot errors in the RBAC model for a few users 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 directly from 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 role assignment 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 these 30 groups."

  • Approved exceptions:
    • Users may be allowed to violate SoD rules, so long as an authorized person has approved the violation.
    • 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 strong business 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 Identity Manager.

  • 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 was implemented.
      • Pre-existing conditions, where a user violated the SoD rule before the rule was added to Identity 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 flagged as an SoD violation.
    • The Identity Manager SoD engine, perhaps uniquely in the marketplace, will detect such violations. In general, it supports enforcement where SoD rules may cover any combination of individual entitlements and nested roles.

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

User Classes: Sets and Relationships

Identity Manager includes a mechanism for classifying users -- individually or as they relate to one another -- called user classes.

When applied to individual users, user classes can examine a user's accounts, identity attributes or security group memberships to decide whether a user is in a given class. For example, help desk users may be members of an Active Directory group called it_support. Linux administrators may be in an LDAP OU called 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 a regional IT support model, such that a given help desk user can only provide assistance, such as password resets, 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 the same 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 managing Identity Manager to users.
  2. In the delegated user administration security model, they determine what a given user can do on behalf of another given user.
  3. They are used to place users into Identity Manager user groups, which in turn are assigned access rights to managed systems.
  4. They are used to select users who will be invited to approve requests for exceptional access.
  5. They are used in the Identity Manager access control model, to determine who can see and who can modify what identity attributes, on whose profiles.
  6. They are used to select users who will be invited to approve requests for changes to user profiles or entitlements.
  7. They can be used by automated provisioning logic, to automatically assign roles or groups to users.
  8. They can be used to segment access certification rounds, by deciding which certifier should review which users and entitlements.

Network Architecture

Identity Manager is designed for:

  • Security:

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

  • Scalability:

    Multiple Identity Manager servers can be installed, using a built-in data replication facility. Workload can 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 application layer.

  • Performance:

    Identity Manager uses a normalized, relational and indexed database back end. All access to the database is via stored procedures, which help to minimize communication overhead between the application and database. All Identity Manager code is native code, which provides a 2x to 10x performance 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 enterprise requirements.

  • Low TCO:

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

Figure [link] illustrates the Identity Manager network architecture:


    Network architecture diagram

  • 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., Cisco Local Director, F5 Big/IP) or simply using DNS round-robin distribution.

  • Native password changes on some systems may trigger transparent password synchronization. A password change interceptor DLL, library or exit may capture such changes and initiate transparent password synchronization.

  • Users may call an IVR system with a telephone and be authenticated either using touch-tone input of personal information or using a voice print. Authenticated users may initiate a password reset.

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

  • Local agents are provided for Unix/Linux servers and z/OS mainframes. A local agent is recommended for z/OS -- on Unix/Linux it's only included in case there is no SSHD. Use of these agents improves transaction security, speed and concurrency.

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

  • Where target systems are remote and communication with them is slow, insecure or blocked by a firewall or NAT, a Identity Manager 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 remote proxies, 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 HR databases (ODBC), directories (LDAP) and meta-directories (e.g., WMI to Microsoft ILM).

  • Identity Manager can send e-mails to users asking them to complete enrollment, participate in workflow processes or to notify them of events impacting their profiles. Over 300 events can trigger e-mail notification.

  • Identity Manager can create tickets on many types of incident management systems, either recording completed activity or requesting assistance (security events, user service follow-up, etc.). Over 300 events can trigger ticket generation. Binary integrations are available for 20 help desk applications and open integration is possible using mail, ODBC, SQL and web services.

High-Performance, High-Availability Database Architecture

All Identity Manager components, including user interface screens, reports, service programs and 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, encrypted communication using a shared key).
  3. The Identity Manager database service authenticates clients, checks what they are allowed to see/do and 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 Oracle Database 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 database service 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-tolerant architecture.
  2. Using stored procedures rather than direct SQL calls significantly improves performance while leaving open the possibility of future schema changes.
  3. Using a Identity Manager database service to front-end the physical database enables robust access controls and easy-to-manage database replication.
  4. Wrapping data calls in an encrypted protocol enables secure configuration in a distributed environment, over untrusted network segments.

Return on Investment

Identity Manager strengthens security by:

  • Quickly and reliably removing access to all systems and applications when users leave an organization.
  • 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 remove them, as appropriate.
  • Reducing the number and scope of administrator-level accounts needed to manage user access to systems and applications.
  • Providing readily accessible audit data regarding current and historical security entitlements, including who 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 addresses.
  • 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 an authoritative 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 on this date?" or "who authorized this user to have this entitlement?"

page top page top