Hitachi ID Access Certifier supports multiple, load-balanced servers.
Each server can host multiple Access Certifier instances, each with its own users, target systems, features and policies.
Access Certifier 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. Access Certifier 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. In practice, 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.
Access Certifier must be installed on a Windows 2012 server.
Installing on a Windows server allows Access Certifier 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 Access Certifier to manage passwords and accounts on target systems without installing a server-side agent.
The Access Certifier server must also be configured with a web server. Since the Access Certifier application is implemented as CGI executables, any web server will work. The Access Certifier installation program can detect and automatically configure IIS but Apache can be manually configured instead if required.
Access Certifier is a security application and should be locked down accordingly. Please refer to the Hitachi ID Systems document about hardening Access Certifier 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):
Each Access Certifier server requires a database instance. SQL 2012 is the most common options, but Oracle database is also supported in the current release.
In addition to a web/application server, Access Certifier requires a database server. In most environments, the database server software (Microsoft SQL Server or Oracle Database Server) is installed on the same hardware or VM as the Access Certifier software, on each Access Certifier 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) may not be ideal. If a VM is used to host the database server software, please consider a NAS or SAN solution for disk I/O.
Access Certifier can leverage an existing database server cluster. Hitachi ID Systems recommends a dedicated database server instance, however, for a number of reasons:
The Access Certifier replicating data service can be configured to use any of the following SQL database engines as its physical data store: