Identity Governance & Administration (IGA) Workflow with JWT

This guide explains the Identity Governance & Administration (IGA) workflow, specifically designed to ensure secure governance over identity-related changes within a decentralized Identity and Access Management (IAM) system. A key feature of this IGA workflow is the protection of the JSON Web Token (JWT) signing key and the signing process. The system ensures that no unauthorized changes—whether to user roles, permissions, or the signing process itself—can be made by a single administrator.

In addition to preventing unauthorized changes, the IGA workflow also safeguards the integrity of the JWT signing key and the signing process, providing a robust security framework for managing sensitive identity information.

Overview of IGA:

IGA extends the capabilities of IAM by adding governance controls to manage changes to user identities, permissions, and roles. It specifically focuses on the security around the JWT signing key, a critical component in authorizing access to resources. Through multi-administrator approval, IGA ensures that no single administrator can make unauthorized or unilateral changes that impact the JWT signing process.

The Tide IGA workflow, built on top of Keycloak administration, prevents any one administrator from making identity-related changes alone. Any modifications, such as changes to roles or permissions that affect the JWT, must go through an authenticated approval process by multiple administrators, in a way that cannot be circumvented.

Protection of the JWT Signing Key:

One of the primary goals of the IGA is to protect the JWT signing key and process. The JWT is used to authenticate and authorize users securely, and any compromise to its signing process would undermine the integrity of the entire system. To prevent unauthorized changes that could impact the JWT:

• Multi-Admin Approval for Changes : Changes that affect the JWT, such as modifying user roles or access permissions, require a majority vote from a quorum of administrators.
• Authenticated Approval : All administrators involved in the approval process must authenticate themselves using secure credentials before a change can be approved. This ensures that only authorized personnel are able to vote on the changes.
• Non-Circumventable Workflow : The workflow is designed so that no administrator can bypass the voting process or act alone to implement changes.

Key Functions of IGA:

1. Change Request Queue :

• When a change is initiated, a draft is added to a queue where it awaits review and voting by administrators. This structured approach ensures that all requests are properly tracked and processed in the correct order, maintaining an organized governance workflow.

2. Logging of Votes :

• Both accepted and failed drafts are logged to maintain a transparent audit trail. If a vote fails to reach the necessary threshold, it is placed in limbo , where it remains until further action is taken. This allows administrators to revisit the failed request and ensure that no changes are prematurely discarded or bypassed.

3. Role & Permission Management :

• Any change to user roles or permissions that affects the JWT token must be reviewed and approved by multiple administrators before being enacted. This prevents unauthorized or accidental modifications that could compromise access control.

4. Change Request Workflows :

• When a change is requested (e.g., adding a role or modifying permissions), it is distributed to a decentralized network of administrators. The change cannot be implemented until the necessary number of administrators have voted to approve it.

5. Threshold Voting & TSS :

• The approval process uses a Threshold Signature Scheme (TSS) , meaning a pre-defined majority of administrators must approve the change before it is cryptographically signed and enacted. This ensures that no single party holds the complete signing key.

6. JWT Signing Process Protection :

• Any change that could affect the JWT signing key, the token's validity, or how it is issued, is safeguarded by this multi-party review process. Administrators work collectively to authorize changes, ensuring robust oversight over the JWT's integrity.

Workflow Steps:

1. Administrator Proposes a Change Request

In the first step, the process starts when an Administrator submits a request to modify sensitive identity attributes such as roles, permissions, or other settings related to user access. These changes are important as they may directly impact the system's access control and the claims embedded in the JWT (JSON Web Token) that the system issues. This ensures that all modifications are tracked and handled with due governance procedures. Once the request is submitted, a draft is created, capturing the proposed changes. The draft contains detailed information about the intended modifications and is passed to the Tide IGA system to begin the approval process.

2. Tide IGA Distributes the Request to a Quorum of Administrators

Once the change request is submitted, the Tide IGA System distributes it to a quorum of administrators for review. This step ensures that the approval of sensitive changes is not handled by a single administrator but is subjected to collective decision-making by multiple admins. By requiring a majority consensus, the system reinforces governance and security, preventing unauthorized or accidental changes to roles, permissions, or other critical identity attributes.

3. Admins Authenticate and Review the Change Request

Before administrators in the quorum can review the proposed change, they must first authenticate themselves to the Tide IGA System . This step guarantees that only legitimate and authorized admins participate in the approval process. Once authenticated, each admin carefully reviews the proposed changes, ensuring that the request aligns with organizational policies and standards. This thorough review process adds another layer of security, ensuring that any changes are made with oversight and deliberation.

4. Outcome of Majority Voting

After the review, the system proceeds in two possible paths depending on whether a majority vote is achieved.

4.1 If a Majority Vote is Reached

If a majority of the administrators in the quorum approve the proposed change, the system initiates several key actions to finalize the change securely:

1. Admins Approve Change (Majority Vote)
   • After reviewing the proposed change request, each admin casts their vote. If a majority of the quorum approves the request, the change is officially accepted for further processing. This ensures that the change has been collectively validated by the necessary number of authorized administrators before being applied. The majority approval threshold is a critical security measure to prevent unauthorized or unilateral changes.
2. Tide IGA Cryptographically Signs the Change (TSS)
   • Upon receiving the majority approval, the Tide IGA System uses a Threshold Signature Scheme (TSS) to cryptographically sign the change. TSS is a cryptographic protocol where multiple parties (administrators, in this case) jointly sign a transaction without any one party having full control over the signing key. This ensures that even if a malicious actor were to compromise a single admin, they cannot tamper with the signing key or the change request. The cryptographic signature guarantees the authenticity and integrity of the request.
3. Update JWT Signing Key or Process
   • Once the change is cryptographically signed, it is applied to the relevant system components. For changes affecting user roles, permissions, or claims, this step may involve updating the JWT signing key or altering the way the system processes JWTs. Since JWTs are used to authenticate and authorize users across the system, any changes to the signing key must be handled with extreme care to maintain the integrity of the authentication process.
4. Log Approved Change in the KeyCloak Audit Log
   • To ensure a full audit trail, the system records the approved change in the TideCloak Audit Log . This log entry includes the details of the change request, the administrators who approved it, and the cryptographic signature associated with the change. This logging provides accountability and transparency, allowing auditors or security teams to trace the history of changes made in the system. It also enables the organization to review decisions in the future, ensuring that all changes are well-documented and reversible if necessary.

4.2 If a Majority Vote is Not Reached

If a majority of administrators do not approve the proposed change, the system follows a separate path to handle the request safely:

1. Admins Deny or Flag the Change for Further Review

   • When the quorum of administrators reviews the change request and a majority vote is not achieved, the system considers the request either denied or flagged for further investigation. Administrators may deny the request outright if they determine that it is unnecessary, risky, or incorrect. Alternatively, the request may be flagged for further review, especially if there is uncertainty or a need for additional information before making a final decision. This process ensures that any questionable or incomplete change requests are subjected to a thorough review before action is taken.

2. Log Denied or Flagged Request in the KeyCloak Audit Log

   • Similar to the approval process, denied or flagged change requests are also recorded in the KeyCloak Audit Log . The log captures the details of the proposed change, the votes from each admin, and any comments or reasons provided for the denial or flagging. This logging is important for accountability and future reference, as it allows the system to track which requests were rejected and why. In cases where the request is flagged for further review, the log serves as a reference point for additional investigation.

3. Reevaluate or Adjust the Change (if Flagged for Review)

   • If the change is flagged for review rather than denied, the Tide IGA System may return the request to the original administrator or a designated group for reevaluation. This step provides the opportunity to adjust or refine the change request based on feedback from the admins. For example, the administrator might need to provide additional details or modify the scope of the request to address concerns raised by the quorum. This ensures that no changes are implemented without proper oversight and that the system remains secure even in cases of uncertainty.

4. Prevent Unauthorized Changes from Being Enacted

   • Whether the request is denied or flagged, the system ensures that no unauthorized changes are applied. This prevents any unapproved modifications from affecting the JWT signing process or user permissions. By rejecting or holding the request for further review, the system maintains its integrity, ensuring that only authorized changes backed by a majority vote are enacted.

5. Administrator Notification

Once the voting process is complete, the Tide IGA System sends a notification to the original administrator who proposed the change. The notification informs the administrator whether the request was approved, denied, or flagged for further review. This communication keeps the administrator in the loop about the status of their request, ensuring transparency and accountability throughout the governance process. It also provides an opportunity for further action if necessary.

6. System Enacts the Approved Changes

If the change request is approved, the system proceeds to apply the changes to the relevant components, such as updating roles, permissions, or the JWT signing process. This step ensures that the approved modifications are implemented in a secure and efficient manner. By updating the system based on the approved changes, the Tide IGA System maintains the integrity of the organization’s identity governance policies while ensuring that all actions are properly documented in the audit logs.

Benefits of JWT Signing Key Protection in IGA:

• Tamper-Proof Signing Process : The signing process is protected by a multi-party approval mechanism, ensuring that no single party can alter the JWT key or process.
• Resilient Security : By requiring multi-administrator approval, the IGA workflow reduces the risk of insider threats or accidental changes compromising the JWT.
• Accountability : Every change to the signing key or process is logged and can be audited, creating a clear trail of responsibility for all changes.
• Non-Circumventable Workflow : The system is designed to prevent administrators from bypassing the multi-admin approval process, guaranteeing that all changes go through proper governance.

Integration with Keycloak and IAM:

Tide IGA is fully integrated with Keycloak, building on top of its existing administration tools to provide an additional governance layer. This ensures that the JWT signing key and process are protected from unauthorized changes, adding an extra layer of security to the IAM system.