Multiple, Load-Balanced Servers
Hitachi ID Identity Manager supports multiple, load-balanced servers.
Each server can host multiple Identity Manager instances, each with its own
users, target systems, features and policies.
Identity Manager instances can and normally do span multiple servers.
Every server hosting a given instance is functionally identical.
User traffic is load balanced between servers supporting the instance.
Load balancing may be accomplished using DNS (round-robin is built into
most DNS servers) or at the IP level with a device from Cisco, F5, etc.
High availability is accomplished by combining load balancing with
server health monitoring and automatic fail-out. Identity Manager includes
server monitoring tools that can be configured on each server to
monitor its peers and when a failure is detected to trigger an
alarm (e.g., by e-mail) and to automatically update DDNS records
to remove the failed server from circulation. Hitachi ID Systems also provides
these tools for Unix/BIND with traditional DNS.
There is no coded limit to the number of concurrent, replicated servers.
With more than 10 servers, replication may become slow.
Since the three largest customers of Hitachi ID Systems run with just two production
servers each, this is only a theoretical problem.
Identity Manager must be installed on a Windows 2012 or Windows 2012/R2 server.
Installing on a Windows server allows Identity Manager to leverage
client software for most types of target systems, which is available
only on the "Wintel" platform. In turn, this makes it possible for
Identity Manager to manage passwords and accounts on target systems without
installing a server-side agent.
Each Identity Manager application server requires a web server.
IIS is used as it comes with the Windows 2012 Server OS.
Identity Manager is a security application and should be locked down accordingly.
Please refer to the Hitachi ID Systems document about hardening Identity Manager
servers to learn how to do this. In short, most of the native
Windows services can and should be removed, leaving a very small
attack surface, with exactly one inbound TCP/IP port (443):
- No ASP, JSP or PHP are used, so such engines should be disabled.
- .NET is not required on the web portal and in most cases can be
disabled on IIS.
- No ODBC or DCOM are required inbound, so these services should
be filtered or disabled.
- File sharing (inbound, outbound) should be disabled.
- Remote registry services should be disabled.
- Inbound TCP/IP connections should be firewalled, allowing only port
443 and possibly remote desktop services (often required for some
configuration tasks), plus a handful of port numbers between Identity Manager
servers, for replication.
Each Identity Manager server requires a database instance. Microsoft SQL
2012 is the recommended choice, Microsoft SQL 2014 will be officially
supported in 2016. Oracle database is supported on versions up to 9.0.x
and is not supported on 10.0 or later releases.
Application Server Hardware and Operating System
Production Identity Manager application servers are normally configured
- Hardware requirements or equivalent VM capacity:
- An Intel Xeon or similar CPU.
Multi-core CPUs are supported and leveraged.
- At least 8GB RAM -- 16GB or more is typical for a server.
- At least 500GB disk, preferably configured as RAID for reliability and
preferably larger for retention of more historical and log data.
More disk is always better, to increase log retention.
- At least one Gigabit Ethernet NIC.
- Operating system:
- Windows 2012R2 Server, with current service packs.
- The server should not normally be a domain controller and in
most deployments is not a domain member.
- Installed and tested software on the server:
- TCP/IP networking, with a static IP address and DNS name.
- IIS web server with an SSL certificate.
- At least one web browser and PDF viewer.
- A database instance is required to host the Identity Manager schema.
Microsoft SQL Server 2012 is recommended (Oracle 11gR2 is supported
on 9.0.x releases but has been be discontinued as of the 10.0
The SQL Server database software can be deployed on the same server
as the Identity Manager application, as this reduces hardware cost and
allows application administrators full DBA access for troubleshooting
and performance tuning purposes.
In addition to a web/application server, Identity Manager requires a database
server. In most environments, the Microsoft SQL Server software is
installed on the same hardware or VM as the Identity Manager software, on each
Identity Manager server node. This reduces hardware cost, eliminates network
latency and reduces the security surface of the combined solution.
Database I/O performance on a virtualized filesystem (e.g., VMDK or
equivalent) is not very performant. Accordingly, if a VM is used to
host the database server software, please consider a NAS or SAN solution
for the actual data storage.
Identity Manager can leverage an existing database server cluster. Hitachi ID Systems
recommends a dedicated database server instance, however, for a number
- The data managed by Identity Manager is extremely sensitive, so it is
desirable to minimize the number of DBAs who can access it (despite
use of encryption).
- MSSQL has limited features to isolate workloads between
database instances on the same server. This means that a burst of
activity from Identity Manager (as happens during auto-discovery)
would cause slow responses in other applications. Conversely, other
applications experiencing high DB load would slow down Identity Manager.
- Identity Manager already includes real-time, fault-tolerant, WAN-friendly,
encrypted database replication between application nodes, each with
its own back-end database. Use of an expensive DB server cluster
is neither required nor beneficial.
The Identity Manager replicating data service can be configured to use
the following SQL database engines as its physical data store:
- Microsoft SQL Server 2012, Standard Edition.
- Microsoft SQL Server 2012, Express Edition, with Advanced Services
(free download from http://microsoft.com/) -- suitable for
development, test and smaller production environments.
- 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 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.