> Markdown version of https://docs.laavat.io/gui/admin/idp/ from the LAAVAT PKI and Signing Platform documentation. All pages: https://docs.laavat.io/llms.txt # 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](https://docs.laavat.io/getting-started/onboarding/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. > **Note: 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. > **Note: 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). > **Warning: 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. > **Warning: 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 > **Tip: 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. > **Warning: 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 > **Warning: 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.