Replicated, High Performance Database Architecture - Hitachi ID Identity Manager
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:
- A client component calls a client wrapper library.
- 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).
- 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.
- 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.
- 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.
- Data returned by stored procedures is passed back to the calling
This architecture is advantageous for several reasons:
- Built-in data replication makes it easy to configure Identity Manager
in a high-availability, fault-tolerant architecture.
- Using stored procedures rather than direct SQL calls significantly
improves performance while leaving open the possibility of future
- Using a Identity Manager database service to front-end the physical database
enables robust access controls and easy-to-manage database replication.
- Wrapping data calls in an encrypted protocol enables secure
configuration in a distributed environment, over untrusted
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
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 IdM Solution Architectures
In the diagram:
- The "Optimized" architecture shows the components of Identity Manager.
In this diagram:
- 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.
- 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.
- 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.
- A database server houses all data: policies, identities,
workflow requests, transaction history, etc.
- Stored procedures act both to isolate the database from the
user interface and IdM services and to accelerate the system
by performing as much of its processing as possible within
- 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:
- The UI and IdM 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.
- The IdM logic, in both the UI and IdM 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.
- 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.