Components

An IdentityIQ deployment is, at heart, a Java web application talking to a relational database and reaching out to managed systems through connectors. Understanding the handful of components involved, and how they interact, makes everything from installation to troubleshooting far less mysterious. This page walks the architecture piece by piece.

• Web application (WAR): the identityiq web archive deployed on an application server such as Apache Tomcat or JBoss/WildFly. It serves the administrative UI, the end-user self-service pages and the REST/SOAP APIs.
• Relational database: Oracle, Microsoft SQL Server or MySQL. This is the identity warehouse, the single source of truth holding every object: identities, accounts, entitlements, roles, policies, tasks, certifications and audit records.
• Task engine: a scheduler (Quartz-based) that runs background work, aggregation, identity refresh, role propagation, certification generation, reports, on a schedule or on demand.
• Request/provisioning engine: compiles provisioning plans, evaluates policy, routes approvals and executes changes through connectors.
• Connectors and integration modules: the adapters that read from and write to each managed application.

The database deserves special attention because it is the centre of gravity. Every object IdentityIQ knows about is persisted there, mapped from its XML representation by the Hibernate ORM layer. This is why import and export use XML, why the object model matters for customisation, and why database health is the dominant factor in performance and availability. When people say "back up IdentityIQ", they overwhelmingly mean back up this database.

A normal day of operation flows like this:

• The task engine runs an aggregation; the relevant connector reads accounts and entitlements from a target and loads them into the warehouse.
• An identity refresh recomputes cubes, re-evaluates roles and runs policies against the freshly aggregated data.
• A user action or lifecycle event triggers the provisioning engine, which builds a plan, obtains approvals, and pushes the change back out through a connector.
• Throughout, the web application serves administrators and end users, all reading from and writing to the same warehouse.

In production these components are usually spread across multiple servers for scale and availability: several application-server nodes behind a load balancer sharing one highly available database, with some nodes dedicated to serving the UI and others configured as task/request servers to run background work. This separation keeps heavy batch jobs from degrading the interactive user experience.

Everything above describes IdentityIQ, the on-premise/self-managed product. SailPoint's SaaS platform, Identity Security Cloud, packages equivalent capabilities as a managed service, replacing the WAR-on-Tomcat-plus-database model with a cloud multi-tenant architecture and a lightweight Virtual Appliance that sits in the customer network to reach on-premise systems. The concepts, sources, identities, entitlements, roles, carry across; the operational responsibility shifts to SailPoint.

• Under-sizing the database, the most common cause of poor performance and instability.
• Running heavy tasks on UI nodes, which makes the interface sluggish; dedicate task servers.
• Treating the file system as authoritative, it is not; the database is. Keep configuration in source control and rely on database backups for state.