iga

How it is built

Architecture overview

Identity governance and administration answers three questions about every account in every system a company runs: who is this person, what may they have, and who said so. It pulls people from an authoritative source (usually HR), pulls accounts and entitlements from each target system (directory, SaaS, database, application), correlates the two into one identity, and then keeps reality equal to policy: it creates, changes and removes access through provisioning connectors, routes requests to approvers, makes managers re-certify access on a schedule, and refuses combinations that policy forbids (separation of duties). Everything it does is recorded as evidence for auditors. The one idea that makes it work is desired-state reconciliation with a human in the loop: the governance model says what each identity should have, the connectors compare that to what exists, and differences are either fixed automatically or turned into a task for a person, with the decision logged. SailPoint, Saviynt and Microsoft Entra ID Governance are the commercial references; Evolveum midPoint and Apache Syncope are open-source ones.

Parts:

• Identity sources and correlation — ingests HR records and target-system accounts, decides which accounts belong to which person — Entity resolution, identity-resolution (no page yet), fuzzy-string-matching (no page yet), ldap-directory (no page yet)
• Access model — entitlements, roles, role hierarchies, peer groups; the "effective access" of an identity — Authorization models (RBAC, ABAC, ReBAC), transitive-closure-index (no page yet), k-means clustering, graph-community-detection (no page yet), Least privilege and isolation
• Policy — birthright access by attribute, separation-of-duties checks, risk rules — Policy engines (PDP/PEP, Cedar, Rego, ReBAC), Rete rules engine, conflict-detection-and-resolution (no page yet), dual-control-approval (no page yet)
• Provisioning — applies changes to target systems through connectors and keeps them converged — scim-provisioning (no page yet), Desired-state reconciliation, Saga pattern, Idempotency keys, Exponential backoff with jitter, Durable job queue
• Workflows and certification — access requests, approvals, joiner-mover-leaver flows, periodic reviews — DAG workflow execution, Durable workflow execution, Human-in-the-loop approval
• Federation edge — how users and connectors authenticate to the governance system and to targets — OAuth 2 and OpenID Connect, saml (no page yet), Mutual TLS
• Evidence — append-only record of requests, approvals, changes and reviews — Tamper-evident audit log
• Operations — keeps the services alive, drains them for deploys, measures and tests them — Process supervision, Graceful draining, hdr-histogram (no page yet), Primary-backup replication, Point-in-time recovery, Deterministic simulation testing, Coverage-guided fuzzing

 HR / authoritative source ─┐
 directories, SaaS, DBs  ───┼─► connectors (read) ─► accounts + entitlements
                            │                              │ correlate
                            ▼                              ▼
                     ┌──────────────────────────────────────────────┐
                     │ identity store: person ─ accounts ─ roles    │
                     │ (hierarchy index, attributes, history)       │
                     └──────┬──────────────────────┬────────────────┘
        policy / rules ─────┘                      │ desired vs actual
        (birthright, SoD, risk)                    ▼
                     requests ─► workflow ─► approvals ─► job queue ─► connectors (write)
                                    ▲                          │          │ SCIM / API / LDAP
              certification ────────┘                          ▼          ▼
              campaigns                                audit log     target systems

How the parts fit together

Identity sources and correlation

An IGA system starts by building one record per human out of many partial ones. The HR system says who exists, when they start and end, which manager and department; each target has its own accounts with its own names (jsmith, john.smith@…, a numeric id in a legacy database). Correlation is the act of attaching accounts to people. It is Entity resolution with a strong deterministic key first (employee id stored in a directory attribute, matched exactly) and fuzzy matching as the fallback: normalised names, email local parts, fuzzy-string-matching (no page yet) such as Jaro-Winkler or edit distance, producing a score and a human review queue for the uncertain band. identity-resolution (no page yet) is the same idea at the identity level, merging duplicate people (contractor re-hired as employee). The cost of a false match is high, since access follows the identity: wrongly attached accounts inherit another person's entitlements, so the threshold is conservative and the review queue is part of the design.

Directory data enters over LDAP (ldap-directory, no page yet; RFC 4511) or an API; the connector returns accounts, groups and memberships on a schedule and optionally as change events.

Access model

The model decides what "access" means. Raw entitlements (a group in a directory, a role in a SaaS app, a database grant) are too many and too cryptic for managers to review, so IGA layers business roles and applications on top: a business role maps to a bundle of entitlements, and a role may include other roles. This is the role-based access control of the NIST RBAC model (hierarchical roles, static and dynamic separation of duty), usually mixed with attribute rules; see Authorization models (RBAC, ABAC, ReBAC).

Two graph problems follow. Effective access (what can this person reach through nested groups and role inheritance?) is a reachability query, answered cheaply if the transitive closure is stored: transitive-closure-index (no page yet) trades write cost on a hierarchy change for constant-time reads during reviews and request checks. Role mining goes the other way, from existing assignments to proposed roles: cluster the identity-by-entitlement matrix (k-means clustering) or find dense groups in the identity-entitlement graph (graph-community-detection, no page yet) and propose "these 40 people share 12 entitlements" as a role candidate or flag the outlier whose access matches no peer group. Mining output is a suggestion for a human, never an automatic grant.

Least privilege and isolation is the goal both feed: certification removes unused access and mining shrinks roles to what groups really use. The connectors themselves follow it too, holding only the permissions their target needs.

Policy

Policies come in three kinds. Birthright rules ("everyone in department X gets mailbox and wiki") are event-condition-action over identity attributes; they re-run when an attribute changes, which suits an incremental forward-chaining engine such as the Rete rules engine. Preventive checks run at request time through a policy engine acting as a decision point: before a request is submitted or approved, ask whether the resulting set of entitlements violates a separation-of-duty rule ("cannot both create and approve payments") or a risk threshold. Entra ID Governance models this as access packages that are incompatible with each other (Microsoft documentation). Detective checks sweep existing access for violations that predate the rule or came in by a back door, and open remediation tasks.

dual-control-approval (no page yet) is the approval-side policy: sensitive entitlements need two distinct approvers, neither the requester. conflict-detection-and-resolution (no page yet) is the reconciliation side: when the same attribute or membership is changed in IGA and directly in the target at the same time, the system must detect it and apply a documented rule (source of truth wins, last writer wins, or raise a task) rather than overwrite silently.

Provisioning

The decision "this person should have X" becomes a call on a target. The lowest common denominator is SCIM (scim-provisioning, no page yet): RFC 7643 defines User and Group resources, including groups, roles and entitlements attributes on a user, and RFC 7644 defines the REST operations, filters, PATCH and bulk. Many targets have no SCIM endpoint, so connectors speak LDAP, SQL, REST or a vendor API; the open-source ConnId framework defines a Java connector interface used by Syncope and midPoint.

The provisioning engine is Desired-state reconciliation at its core: compute what each account should look like from the model, read what it looks like, and produce the delta. Running the loop both on events and periodically (a full reconciliation) catches drift from changes made outside IGA and from failed earlier writes. Because one change often touches several systems (create the account, add to a group, enable mail), a joiner flow is a Saga pattern: if the third step fails permanently the first two are compensated, or the failure is parked as an explicit "partially provisioned" state a person can see.

Target systems are slow, rate-limited and sometimes down, so every write goes through a Durable job queue with Exponential backoff with jitter, and carries an Idempotency key so a retry after a timeout does not create a second account. Where the target does not accept keys, the connector reads before it writes ("does the account exist?") to get the same effect.

Workflows and certification

Request and approval flows are long-lived: a request waits days for a manager, may be delegated or escalated, and must survive a restart. Durable workflow execution stores each step's state so the flow resumes where it was; DAG workflow execution fits the structure, with parallel approvals joined before provisioning. Human-in-the-loop approval is the contract at each wait: the engine presents the facts (who, what, why, risk score, peer comparison), records the decision and the actor, and enforces timeouts and escalation.

Certification campaigns reuse the same machinery: for each reviewer, generate the list of identities and entitlements they own, collect keep or revoke decisions, then turn each revoke into a provisioning job. The scheduling matters: Entra ID Governance access reviews, for example, support recurring reviews and automatic application of results (Microsoft documentation). Reviewers rubber-stamp when a list is long, so the access model (roles instead of raw entitlements) and mining (outliers first) exist partly to make reviews short.

Federation edge and evidence

Users reach the system through OAuth 2 and OpenID Connect or SAML (saml, no page yet; OASIS SAML 2.0). Connectors to cloud targets use OAuth tokens or SCIM bearer tokens; connectors that run inside the customer network (an agent next to the directory) open an outbound Mutual TLS channel to the service, so no inbound firewall hole is needed and both sides are authenticated.

Auditors need proof of what happened. Every request, approval, provisioning call and review decision goes to a Tamper-evident audit log: append-only, hash-chained, with the actor, the policy version and the evidence shown at decision time. The log is the product's answer to "show me who approved this access and when".

Operations

The services run under Process supervision and drain on deploy (Graceful draining) so that a half-finished provisioning job is neither lost nor run twice. The identity store replicates (Primary-backup replication) and supports Point-in-time recovery: the model is the system's memory and restoring it to "before the bad import" is a standing requirement. Queue age and connector latency are tracked with hdr-histogram (no page yet). The reconciliation and saga logic suit Deterministic simulation testing (inject timeouts, duplicate deliveries and concurrent out-of-band changes), and parsers for directory data and connector responses suit Coverage-guided fuzzing.

Data and control flow

Joiner (new employee):

1. HR export or event creates a person; correlation finds no existing accounts and creates the identity.
2. The rules engine evaluates birthright policy and the SoD check against the proposed set.
3. A saga starts: create the directory account, add to groups, create SaaS accounts, each as an idempotent job on the queue.
4. Each connector reads, writes, and returns the resulting account id; the identity store links it. A failure retries with backoff, then raises a task.
5. Every step is appended to the audit log; the manager gets the day-one summary.

Access request with approval:

1. A user asks for a role in the catalogue; the policy engine checks eligibility and SoD.
2. The workflow engine opens approval tasks (manager, then data owner if the risk is high); the flow is persisted and waits.
3. On approval the request becomes provisioning jobs; on rejection or timeout it is closed with a reason.
4. Provisioning confirms the entitlement exists on the target; the request is closed and the audit record sealed.

Certification campaign:

1. The campaign scope (applications, populations) is resolved into one review item per identity-entitlement pair, grouped by reviewer.
2. Reviewers decide in a work list that surfaces outliers first; undecided items escalate after a deadline.
3. Each revoke becomes a job; reconciliation later verifies the access is gone, since a revoke that failed silently is the finding auditors look for.

Scaling

Limits in the order you hit them:

1. Connector throughput and target rate limits. Every target has its own limit; per-target queues with concurrency caps and backoff keep one slow system from blocking others. Use change feeds or delta queries rather than full reads where the target offers them.
2. Reconciliation cost. A full compare of millions of accounts is the heaviest job; run it per target on a schedule, use incremental sync in between, and keep an index from target account id to identity.
3. Effective-access queries. Deep hierarchies and nested groups make live graph walks slow; maintain the closure incrementally and recompute only affected subtrees on change.
4. Workflow volume. Persisted workflows are cheap while idle; the limit is the work-list UI and notification volume, so batch notifications and reviews.
5. Review fatigue is the quality limit, not a compute one: shorter, role-level, outlier-first reviews give better decisions than bigger servers.

Failure modes

Real implementations

Sources

• RFC 7643, SCIM: Core Schema, and RFC 7644, SCIM: Protocol. RFC 7643, RFC 7644
• RFC 4511, Lightweight Directory Access Protocol (LDAP): The Protocol. RFC
• NIST, Role Based Access Control project (RBAC standard: hierarchies, separation of duty). NIST
• OASIS, Security Assertion Markup Language (SAML) V2.0. OASIS
• Microsoft, Entra ID Governance documentation: overview, incompatible access packages, how provisioning works.
• Evolveum midPoint and Apache Syncope project documentation (links in the table).