Replicated, High Performance Database Architecture

Hitachi ID Identity Manager includes built-in data replication and uses stored procedures to ensure optimized transaction processing.

Database Architecture Overview

All Hitachi ID 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.

Built-in Replication

Identity Manager includes built-in data replication between servers.

Data replication between Identity Manager servers occurs in real time -- all updates to one server's database are queued up and sent to other (peer) servers as well. If a peer server is unavailable, database updates are automatically retried when the server becomes available again.

All replication is performed at the application level, over an encrypted TCP/IP socket. This makes configuration of a replicated environment straightforward and eliminates the need to license and configure a replicated RDBMS server product.

Application-level replication is especially helpful for deployments where Identity Manager servers are physically distant from one another, for example to provide fault tolerance in the event of a disaster at a single data center. Database replication provided by database vendors such as Microsoft or Oracle is very difficult to configure where the network between nodes is insecure, unreliable, low bandwidth or high latency. Since a WAN network normally exhibits all of these problems, Hitachi ID Systems built replication right into Identity Manager to operate reliably under these same constraints.

Identity Manager data replication is secure. Data transmitted between servers is encrypted and each endpoint authenticates the other. Replication uses relatively low bandwidth and is tolerant of high latency, making it suitable for deployment across physically distant sites. Replication is fault tolerant, in that failed transmissions are queued and retried until they succeed.

Designed for Performance

Figure [link] highlights differences between the architecture of Identity Manager and other common architectures for competing identity management and access governance products. Using the optimizations shown in this diagram, Identity Manager is able to process changes, such as auto-discovery of large numbers of users on target systems, up to 100 times faster than many competing products.


    Performance of Alternative IAM Solution Architectures

In the diagram:

  1. The "Optimized" architecture shows the components of Identity Manager. In this diagram:
    1. Users access the system using a web browser, connected to a web server using the HTTPS protocol. This is common to all products with a web portal.
    2. Identity Manager's user interface and core services are implemented using native-compiled IA86 code, which executes 2x to 10x faster than Java or .NET bytecode.
    3. Business logic is added to the system in the form of script code -- an approach common to all identity management and access governance products and modern products.
    4. A database server houses all data: policies, identities, workflow requests, transaction history, etc.
    5. Stored procedures act both to isolate the database from the user interface and IAM services and to accelerate the system by performing as much of its processing as possible within the database.

  2. The "Typical" architecture shows the components of most competing products. This architecture performs less well than the Hitachi ID Identity and Access Management Suite because of the following differences:
    1. The UI and IAM services are written in either Java (J2EE) or .NET. Java is typically about 10x slower than native code and .NET is typically about 2x slower than native code.
    2. The IAM logic, in both the UI and IAM services, has direct access to the database. Issuing SQL calls directly to the database means that searches and updates that might be accelerated by being run inside the database instead trigger slow network traffic -- back and forth between the app and DB.

  3. The "Slow" architecture shows the components of only one or two competing products. In this architecture, a high performance relational database is replaced with complex XML objects embedded in an LDAP directory. Whenever the IAM system has to look up user profile data or search for users that match certain criteria, an XML parser must be applied to each and every user profile. This not only severely impairs performance, but it also makes it impossible to use off-the-shelf tools to write custom reports.

Read More:

  • Network architecture:
    Identity Manager network architecture.
  • Replicated, High Performance Database Architecture:
    Identity Manager includes built-in data replication and uses stored procedures to ensure optimized transaction processing.
  • Included Connectors:
    Connectors included in Identity Manager and their capabilities.
  • Auto-Discovery System:
    How the Identity Manager automatically discovers new, deleted and changed users on integrated systems and applications.
  • Reconciling User IDs:
    How Identity Manager maps user IDs on different systems back to their human users, both automatically and with human assistance.
  • Integrations:
    Integrations between Identity Manager and other parts of an IT infrastructure.
  • Custom Business Logic:
    How organizations can implement their own business logic without modifying the core Identity Manager product or impairing system reliability or upgradeability.
  • Dynamic Workflow:
    How Identity Manager invites business users to review and approve changes to user profiles.
  • Reliable Authorization:
    Using parallel invitations, reminders, escalation and delegation to get reliable results from human authorizers.
  • Roles & Rules:
    Using roles and rules to simplify the management of user provisioning policies.
  • Self-service Group Management:
    Using the included Group Manager module to move AD group management to a self-service model.
  • Event Notification:
    Identity Manager can alert people and other systems of changes that it detects on target systems and of events that took place within identity management and access governance business processes.
  • Server Requirements:
    How to configure Identity Manager servers and how many are required.
  • Customizable User Interface:
    How the Identity Manager user interface can be branded, rearranged and adapted to specific customer requirements.
  • Language Support:
    Languages in which Identity Manager can display its user interface.