2.1 IdentityIQ Infrastructure Components

IdentityIQ Infrastructure Components

Blueprint objective 1.1 asks you to understand the different infrastructure components of IdentityIQ deployments. Expect exam scenarios such as a new customer asking what they must provide, or a failed Active Directory password change traced to a missing Windows component. You need to know what each piece does and where it runs.

The Core Stack

The application is delivered as a zip containing identityiq.war plus database, doc, and integration folders. You expand the WAR into a directory, commonly called identityiq_home. Its WEB-INF subfolders hold the files engineers use daily:

• WEB-INF/bin – the iiq script used for iiq console, iiq schema, iiq keystore, iiq encrypt, iiq upgrade, and iiq patch.
• WEB-INF/classes – iiq.properties (database connection settings), the keystore files iiq.dat and iiq.cfg, and the .hbm.xml Hibernate mapping files under sailpoint/object.
• WEB-INF/config – XML import files such as init.xml and init-lcm.xml.
• WEB-INF/database – the DDL scripts for supported database platforms.
• WEB-INF/lib – Java libraries, where you add a JDBC driver or a custom JAR.

The Databases

The database scripts create more than one database:

• The IdentityIQ database (default name identityiq) holds every persistent object.
• The plugin database (identityiqPlugin) gives installed plugins their own tables. By default, iiq.properties sets plugins.enabled, plugins.runSqlScripts, and plugins.importObjects to true.
• The Access History database was added in IdentityIQ 8.4. The documentation says this separate database is required even when Access History is disabled. It may share a database instance, but a separate instance is recommended in production because it keeps growing.

Oracle, Microsoft SQL Server, and MySQL have long been supported. IdentityIQ 8.4 added PostgreSQL. Always confirm the exact versions in the Supported Platforms section of the release notes for your IdentityIQ version, because platform support changes from release to release.

Components Outside the Web Application

• IQService – a native Windows service that lets IdentityIQ reach information available only through Win32 APIs. You must install and register an IQService before you can provision to Active Directory, aggregate Terminal Services attributes, read Windows Event Logs, or load local Windows users and groups through the direct connectors. This includes password changes. The Active Directory application stores the IQService host and port, and the IQService version must match the IdentityIQ server version, including patch level.
• Connectors – most connectors run inside IdentityIQ itself. Some need an agent near the target system, and IQService is the most tested example.
• Message broker – when Data Extract and Access History arrived in 8.4, they used an ActiveMQ broker, embedded or external (the Debug pages have an ActiveMQ Monitoring page). The documentation notes that as of 8.4p2, Access History and Data Extract no longer depend on ActiveMQ.
• Load balancer – distributes user sessions across UI hosts in a multi-host installation.
• Identity provider – optional SAML or rule-based single sign-on (section 3.3).

Multi-Host Installations

Production installations usually run several IdentityIQ instances against one shared database. The documentation describes the moving parts:

1. Server objects and heartbeats. Each instance has a Server object. A heartbeat thread updates it regularly. If a host's heartbeat stops advancing, the other hosts mark it as crashed. When several instances run on one machine, each one needs a unique iiq.hostname so that it gets its own Server object.
2. Services per host. Background services include Task (the Quartz task scheduler), Request (the request processor), Heartbeat, Cache, Monitoring, and Reanimator. The Reanimator resets or terminates tasks that look hung. In the Administrator Console, under Environment > Hosts, you can switch services on or off for each host. A host whose Task service is off still runs requests aimed specifically at it but does not pick up untargeted work. The Request service cannot be fully shut down.
3. Dedicated hosts. To keep batch processing away from interactive users, disable the Task service on UI hosts. Then put a comma-separated hosts list in a task definition's Host field or in a RequestDefinition object's hosts attribute. With a list, the task runs on the first host that has an active heartbeat.
4. Partitioning. Account aggregation, account group aggregation, identity refresh, Identity Request Maintenance, Perform Maintenance, manager and targeted certification generation, and role propagation can be split into partitions. The partitions go into a global queue, and hosts compete to run them. If a host fails, its partitions return to the queue. RequestDefinition objects such as Aggregation Partition and Identity Refresh Partition set maxThreads per host. The default is 1.

Exam Traps

• "The heartbeat is a database cluster feature." No. The heartbeat is an IdentityIQ service that updates Server objects. It is not database replication.
• "Disabling the Task service stops everything on that host." No. Targeted requests still run. Only untargeted work is no longer picked up.
• "IQService is needed for every connector." No. It is needed for Windows-specific work such as Active Directory provisioning and password changes, Windows local accounts, and Event Log collection.
• "Access History is optional, so its database is optional." The documentation says the separate database is required even when the feature is not used.