Skip to main content

Identity Governance & Administration (IGA) Workflow

This guide outlines the IGA workflow for managing identity changes in a decentralized IAM system. It emphasizes multi-admin governance over critical operations-especially protecting the JWT signing key and signing process-so no single administrator can unilaterally modify roles, permissions, or token policies.

1. What is IGA?​

IGA extends IAM by adding governance controls to:

  • Change user identities (roles, groups, permissions)
  • Protect JWT signing (key integrity & issuance process)
  • Enforce multi-admin approval (threshold signing)

Every change must pass through an authenticated, quorum‑based approval process, ensuring robust oversight and auditability.

2. Core IGA Components​

ComponentDescription
Change Request QueueDrafts of proposed changes are added to a queue for review and voting.
Vote LoggingApproved and denied drafts are recorded in the audit log; failed votes remain pending for reevaluation.
Role & Permission MgmtAny modification impacting JWT claims requires multi-admin review.
Threshold SignatureAThreshold Signature Scheme (TSS) ensures changes are cryptographically signed only after majority approval-no single admin holds the key.
Key ProtectionThe JWT signing key and issuance process cannot be altered without quorum‑validated signing votes.

3. JWT Signing Protection​

Protecting the JWT signing key is critical because JWTs authorize access across your system. The IGA workflow enforces:

  1. Multi‑Admin Approval Changes affecting JWT issuance (roles, claims, key rotation) require a ≥ majority vote from the administrator quorum.
  2. Authenticated Voting Admins must authenticate before voting, ensuring only authorized personnel participate.
  3. Non‑Circumventable Process No single admin can bypass quorum voting or submit changes unilaterally.

4. IGA Workflow Steps​

  1. Submit Change Request An admin drafts a change (e.g. update role, modify permission) and submits it to the IGA queue.
  2. Distribute to Quorum The IGA system sends the request to a quorum of admins for review.
  3. Authenticate & Review Each admin logs in, reviews details, and casts an approve or deny vote.
  4. Vote Outcome
  • Approved (majority reached):
  1. TSS signs the change request.
  2. System applies updates (roles, permissions, JWT key rotation).
  3. Log entry created in audit log.
  • Denied (no majority):
  1. Request is marked denied or flagged for further review.
  2. Logged in audit log with reasons.
  3. Optionally, request can be revised and resubmitted.

5. Detailed Sequence Diagram​

IGA Workflow Diagram

6. Audit & Accountability​

  • Every step (submission, vote, signature) is logged with timestamps, admin identities, and cryptographic proofs.
  • Audit trails support compliance and forensic analysis without exposing secrets.

7. Integration with Keycloak​

Tide's IGA layer integrates seamlessly with Keycloak's admin console and REST API. It intercepts changes to sensitive endpoints, adds governance controls, and applies TSS‑based signing before committing alterations.

8. Benefits​

  • Tamper‑Proof Governance: No single point of failure or unauthorized change.
  • Insider Threat Resistance: Quorum votes mitigate rogue admin risks.
  • Clear Audit Trails: Full visibility into who changed what, when, and how.
  • Regulatory Compliance: Meets strict governance requirements out of the box.