Skip to content

Identity Provider Management

Overview

The Identity Provider (IdP) page lets administrators manage the secrets that the LAAVAT Platform uses to authenticate against your identity provider.

The initial IdP configuration is performed once during onboarding through the Identity Provider Setup wizard. After onboarding, this page is used to rotate the IdP application secret or service account credentials when they expire or need to be replaced.

What is mutable

Only the OIDC application client secret (Entra or Google) and the Google service account JSON can be rotated here. Tenant ID, application (client) ID, writer/approver groups, and provider type are fixed at onboarding time and cannot be changed from this page.

Providers

The platform supports two identity providers. The fields required for a rotation request depend on which provider the tenant uses.

Provider Required fields Notes
Microsoft Entra ID (entra) clientSecret The new Entra app registration secret value.
Google Workspace (google) clientSecret and/or googleSAFile OAuth client secret and/or the service account JSON used for Admin SDK / domain-wide delegation. At least one must be supplied.

The provider type is shown as read-only on the rotation form and matches the value selected during onboarding.

Secret Rotation

A rotation request holds the new secrets in a staging area while it is pending approval. The live identity provider configuration is only updated after an approver promotes the request, so an in-flight rotation cannot disrupt the running tenant.

Only one request can be staged at a time

Only one IdP rotation request can be in staging at a time. The existing request must be approved or rejected before a new rotation request can be submitted.

Creating a Rotation Request

  1. Navigate to Admin > Identity Provider.
  2. Click New rotation request.

  3. Fill in the request fields:

    Field Required Description
    Name Yes Short request name, e.g. Rotate Entra app secret 2026-Q2.
    Description No Detailed info about why the rotation is being done.
    Provider type Yes Read-only; matches the tenant's configured provider.
    Client secret Conditional New OIDC application secret. Submit-only — never returned by the API after submission.
    Google service account JSON Google only Replacement service account JSON, base64 encoded for transport. Submit-only.

  4. Submit the request. The platform validates the supplied credentials before accepting the rotation (see below).

Secrets are write-only

Secret values are never returned by the API once submitted. If you lose a secret before approval completes, cancel the request and create a new one with a fresh secret.

Validation Performed at Submission

When a rotation request is submitted, the platform runs the following checks against the staged secrets and reports the outcome in validationResult:

  • OIDC discovery — the provider's OIDC discovery document is reachable using the tenant's existing identity provider configuration and the new credentials.
  • Client credentials grant — the platform can mint a token using the new client secret.
  • Admin SDK reachability (Google only) — the new service account JSON authorises against the Google Admin SDK and can read the configured groups.

A request that fails validation can still be saved as a request record, but it cannot be approved until a working set of secrets is submitted.

Approval Flow

IdP secret rotation follows the platform's standard two-person principle.

State Meaning
Pending Request has been submitted and is awaiting approver action. Secrets are staged but not live.
Approved An approver has accepted the request; secrets are being promoted to the live identity provider configuration.
Ready New secrets have been promoted. The platform picks them up in the background, typically within 15 minutes.
Rejected An approver rejected the request; the staged secret is discarded.
Cancelled The submitter cancelled the request before approval.

After a request reaches Ready, the rotated credentials are typically active within 15 minutes. The platform polls for updated secrets in the background, so there is a short rollout delay between approval and the new credentials taking effect.

Do not invalidate the old secret immediately

Keep the previous secret valid in your identity provider for at least 15 minutes after approval to avoid an authentication outage during the rollout window.

Reviewing Requests

Approvers see the list of pending IdP rotation requests under Approvals > Identity Provider. The detail view shows:

  • Request name, description, and submitter
  • Provider type and which secret types were submitted (client secret, service account file, or both)
  • validationResult summary — pass/fail for each validation step
  • Request state and submission timestamp

Validation must pass before approval

A request whose validationResult shows any failure should not be approved. Reject the request and ask the submitter to resubmit with corrected credentials.

The raw secret values are never visible to approvers — only the validation outcome and request metadata.

Approve / Reject

To act on a pending request:

  1. Open the request from the Approvals > Identity Provider list.
  2. Review the validation summary and request metadata.
  3. Click either:

    • Approve — promotes the staged secrets to the live identity provider configuration. The rotation typically becomes active within 15 minutes.

      Do not invalidate the old secret immediately

      Keep the previous secret valid in your identity provider for at least 15 minutes after approval to avoid an authentication outage during the rollout window. - Reject — discards the staged secret and marks the request as Rejected. The submitter must create a new request to retry.

Approvers cannot edit request fields. If a request has incorrect metadata, reject it and have the submitter create a new one.

Best Practices

Plan rotations ahead of secret expiry

Entra application secrets and Google OAuth secrets have a finite lifetime. Submit and approve rotation requests well before the current secret expires to avoid an outage.

  • Validate before approving. Confirm that validationResult shows all checks passing. A failing rotation that is approved can lock the tenant out.
  • Use descriptive request names. Include the date and the secret being rotated, e.g. Rotate Google SA 2026-Q2. This makes audit trails easier to read.
  • Coordinate with the identity provider team. A rotation only takes effect when both the new secret is staged in LAAVAT and the corresponding secret is active in Entra / Google.
  • Cancel stale requests. If a request sits in Pending for more than a few days, cancel and resubmit rather than letting the staged secret age.