Architecture overview
How IdentityIQ is built: the application server, the object model, connectors and the tasks that keep identities in sync.
IdentityIQ is a Java web application that runs on an application server such as Tomcat or WebSphere, backed by a relational database. It connects to target systems through connectors, aggregates their data into an object model centred on the Identity Cube, and runs governance through scheduled tasks, workflows and rules.
- A Java web app on Tomcat or WebSphere plus a relational database
- Connectors integrate every target system
- Object model: Identity, Link, Application, Entitlement, Role, Bundle
- Tasks run aggregation, identity refresh and certifications
- Rules and workflows add custom logic at defined points
SailPoint IdentityIQ’s architecture is, at its core, a Java web application talking to a relational database and reaching managed systems through connectors. Understanding how these parts fit together, and where work happens, makes installation, tuning and troubleshooting far more tractable.
The core components
- Web application (WAR), the UI, self-service and REST/SOAP APIs, deployed on Tomcat or JBoss.
- Database, the identity warehouse holding every object (identities, accounts, roles, policies, certifications, audit).
- Task engine, runs background work: aggregation, refresh, certification generation, reports.
- Provisioning engine, compiles plans, evaluates policy, routes approvals, executes changes.
- Connectors, read from and write to each managed system.
The identity warehouse
The database is the centre of gravity. Every object is persisted there, mapped from its XML representation by Hibernate. This is why configuration is XML, why the object model matters for customisation, and why database sizing and health dominate performance and availability. "Backing up IdentityIQ" overwhelmingly means backing up this database.
How data flows
Inbound, aggregation reads accounts and entitlements through connectors into the warehouse, and correlation attaches them to identities. Processing, identity refresh recomputes cubes, roles and policy. Outbound, provisioning pushes approved changes back through connectors. The database sits at the hub of both directions.
Deployment topology
In production the components spread across multiple application-server nodes behind a load balancer, sharing one highly available database. Some nodes serve the UI; others are dedicated task/request servers so heavy batch jobs do not degrade the interactive experience. Heavy jobs are partitioned across task servers to scale.
IdentityIQ versus Identity Security Cloud
The above describes the self-managed IdentityIQ. Identity Security Cloud delivers equivalent capability as a multi-tenant SaaS, replacing the WAR-plus-database model you operate with a service SailPoint runs, plus a lightweight Virtual Appliance in your network for connectivity. The concepts carry across; the operational burden shifts.
Common pitfalls
- Under-sizing the database, the top cause of poor performance.
- Running heavy tasks on UI nodes, degrading the interface.
- Treating the file system as authoritative, the database is the source of truth.
Authoritative sources
- SailPoint IdentityIQ documentation - Official IdentityIQ product and administration docs
- SailPoint Developer Community - APIs, SDKs and reference architecture