IIQ Engineer cheat sheet

IdentityIQ deploys as a WAR on a supported servlet container (Tomcat, JBoss/WildFly, WebSphere) and requires a supported JDK; confirm the version compatibility matrix before upgrading.

iiq.properties supplies dataSource.url, dataSource.username, dataSource.password, identityIQ.home, identityIQ.plugins, and the keystore location.

Fresh install sequence: create an empty database, deploy the WAR, then run 'install' from iiq console to load the base configuration objects.

Upgrade order: back up the database and export object configuration, stop the server, run 'iiq upgrade' then any 'patch' scripts, install updated plugins, deploy the new WAR, start, then run checkConfig.

iiq console commands include install, upgrade, patch, create, export, import, encrypt, decrypt, checkConfig, and rule.

Encrypted configuration values are decrypted with keys in the keystore file; if the keystore is lost those values cannot be recovered and must be re-entered.

Plugins are installed with 'plugin install ' in iiq console and enabled by listing them in the identityIQ.plugins property.

The Check Configuration task on a running system verifies database access, key storage, plugin loading, and object configuration, and reports each failure.

Every application object names a connector, its connection parameters, an account schema, optionally a group schema, and the provisioning policies used for create/update/delete.

The DelimitedFile connector requires a file or transport, delimiter, quote/escape settings, a header-row flag, and schema attributes with declared types.

Correlation maps application account attributes to identity attributes; unmatched accounts either create new identities (authoritative sources) or remain uncorrelated accounts.

Only one application per identity source should be flagged authoritative, because its accounts create identities and set identity attributes during aggregation.

Account aggregation reads accounts and builds or updates Link objects; group aggregation creates ManagedAttribute objects that represent groups and entitlements.

Test Connection validates host, credentials, and connector settings before a full aggregation is run.

Application feature strings (ENABLE, DISABLE, UNLOCK, DELETE, DIRECT_PERMISSIONS) toggle which provisioning operations the connector will attempt.

Delta aggregation requires connector support and reads only records changed since the previous run instead of the full account set.

Joiner, mover, and leaver behavior is implemented with lifecycle events driven by identity trigger rules or by access requests through LCM.

Refresh Identity Cube recomputes identity attributes, correlates accounts and managers, detects and assigns roles, and runs policy scans for the identities in scope.

The LCM Provisioning workflow chains approval, provisioning plan compilation, execution against applications, and verification, recording each stage.

A provisioning plan holds AccountRequests; the provisioner compiles them into per-application ProvisioningProjects and executes the requested operations.

Authoritative aggregation creates new identity cubes, while non-authoritative aggregation only links accounts to identities that already exist.

Leaver processing normally disables accounts first and deletes them only after the retention period defined by policy or the workflow.

Identity attributes can be derived with transforms or rules; the identity cube holds Links plus role and entitlement assignments.

Failed provisioning operations are retried according to the provisioning configuration, and the outcome is recorded in the task result and the identity's provisioning history.

Business roles group other roles; IT roles constrain application entitlements directly and are the roles that drive provisioning.

An IT role profile contains constraints on applications, attributes, and entitlement values, with a match mode of all, any, or none.

Membership criteria or a population on a business role determines automatic assignment of that role to matching identities.

Role detection matches account attributes and entitlements against role profiles; detected roles become assigned through refresh, role propagation, or a role assignment rule.

Group-based entitlements are stored as ManagedAttribute objects and must be aggregated before roles can reference them in profiles.

Role assignment sources include manual assignment, business role membership criteria, role propagation, and role assignment rules.

Profiles can require the presence of specific entitlement values or explicitly exclude values, so a role never matches an unwanted account.

Role owners plus role certification allow periodic review of role definitions and of the identities holding each role.

Certification types include manager, role, entitlement owner, application owner, account group, identity, and advanced (custom definition) certifications.

A campaign moves from creation/staging to active and then to sign-off; reviewer decisions are approve, revoke, mitigate, or delegate.

Decisions feed remediation: revoke removes access, mitigate creates a mitigation for a violation, and allow records an approved exception.

Policy types include separation of duty, entitlement SOD, activity-based, and rule/script-based policies; each violation carries severity, status, and owner.

The policy scan evaluates policy definitions against identities and creates or updates PolicyViolation objects for every conflict detected.

A violation is suppressed only while an approved mitigation object is active; when the mitigation expires the violation becomes active again.

Advanced certifications use certification definitions to control scope, sign-off levels, and micro-certification of individual items.

Scheduled certifications repeat on a defined schedule and reuse the scope and sign-off configuration stored in the certification definition.

Rules execute as BeanShell or JavaScript inside the IdentityIQ context with access to the sailpoint API objects, the current context, and a log object.

Common rule hooks are application correlation, provisioning before/after operations, identity triggers, role assignment, task logic, and workflow script steps.

Workflows are XML definitions composed of steps (approval, script, subprocess, condition, end) connected by transitions with variables and forms.

The WorkflowCase object persists a running workflow's state, variables, and pending approvals until the workflow completes or is terminated.

Identity attribute transforms (rule, static, upper/lower, date format, concatenation, identity attribute) compute derived identity attribute values.

Forms and provisioning policies define the fields, defaults, and validation used in LCM requests and approval steps.

Task definitions bind a task class or rule to schedules and arguments, producing recurring jobs whose output is stored as TaskResult objects.

The iiq console checkConfig, show, search, export, import, encrypt, decrypt, and set commands are the primary diagnostic and maintenance tools.

Logger levels are raised per class or category from System Setup > Logging to increase detail for one component without flooding all logs.

TaskResult objects store each run's status, timing, messages, and exceptions, and are the first place to inspect a failed task.

Health Check and System Setup pages report database connectivity, memory usage, and version; sustained heap pressure and frequent GC indicate a need for JVM tuning.

Maintenance tasks that prune old task results, workflow cases, and requests keep object tables and audit data from growing without bound.

Aggregation partitioning splits a large aggregation into concurrent tasks along defined partition boundaries; delta aggregation further reduces read volume.

StaleObjectStateException and ConcurrentModificationException signal two processes modifying the same object, so the competing tasks should be serialized.

Clearing the object cache from the debug page or console reloads changed configuration objects without restarting the application server.