Skip to content

Sign in with your company's identity provider

Declare your company's OIDC or SAML identity provider for your tenant, prove that the platform can reach it, and enable it so your members sign in with their corporate accounts.

Who can do it

A tenant administrator or a tenant access administrator, or a platform super administrator working inside your tenant. Declaring, testing and enabling need the permission to configure identity federation for the tenant; without it the console shows the providers but keeps Declare an identity provider disabled and says why.

Before you start

  • Your edition must include tenant-configured identity federation. If it does not, the panel says so and names the edition that includes it. Your members can still sign in through the identity provider configured for the deployment.
  • Your tenant holds at most one provider of each protocol.
  • A provider is enabled only when its last self-test passed and your tenant has at least one verified email domain. Declaring a domain is described in Declare the tenant's email domains; a platform administrator verifies it.
  • Register the redirect URL (OIDC) or the Assertion Consumer Service URL (SAML) that the dialog shows with your identity provider, and have its client identifier, metadata and secret at hand.
  • A declared provider cannot be edited. To correct one, you delete it and declare it again.
  • The declaration and the enable ask for a recent sign-in. If yours is too old, the console asks you to confirm who you are before it continues.

Steps

  1. Open Settings and select the Integrations tab.
  2. On the Identity federation row, select Manage.
  3. Select Declare an identity provider.
  4. Choose the Protocol: OIDC or SAML.
  5. Choose a Provider template. A template prefills the standard settings, so you paste only your own identifiers.
  6. Copy the URL shown under Redirect / callback URL (register at your IdP) or Assertion Consumer Service (ACS) URL (register at your IdP) and register it with your identity provider.
  7. Fill in the provider's fields. For OIDC, complete the Identity contract: the Email claim and the Provider verification of that address.
  8. Decide Multi-factor authentication proven by this provider: Trust this provider's MFA only once the provider enforces MFA; the default is Do not trust this provider's MFA. This choice cannot be changed later.
  9. Enter the Secret where the protocol has one. It is write-only.
  10. Select Validate connection. Nothing is stored yet; the result shows whether the provider answered.
  11. When the validation passes, select Declare provider. The provider is stored declared and disabled.
  12. Select Run self-test.
  13. When the self-test passes, select Enable provider, then Done.

What you see when it worked

The dialog reads Enabled. Your users can now sign in through this provider. The provider appears under Providers declared for this tenant as Serving sign-in, with its MFA trust shown as Trusted for MFA or MFA not trusted. The declaration, the self-test and the enable are recorded in the audit trail.

Members linked to the provider can now sign in through it. Whether they may also sign in with their own passkeys or passwords is decided separately, in Choose how members sign in.

If it fails

What you see Cause What to do
The panel says tenant-configured federation is included in another edition Your edition does not include it Contact your account manager. Sign-in through the deployment's provider keeps working
We could not confirm your edition, so this stays locked. The edition could not be read Select Try again
The validation result names a connection failure and its remedy The provider could not be reached or rejected the configuration Correct the field it names and validate again
A conflict saying a provider of this protocol already exists Your tenant already has one Delete the existing provider first, or use it
A declaration trusted for MFA is held for approval Your tenant's quorum approval is on: a trusted declaration waits for the approvers and cannot carry the secret Declare the provider as not trusted, with its secret
Run the connection test - it has not passed for the current configuration The last self-test did not pass Run the self-test again and fix what it reports
Declare and verify at least one email domain Your tenant has no verified email domain Declare a domain and have a platform administrator verify it
Declare whether this provider's email-verification claim is trusted The OIDC identity contract is incomplete Delete the provider and declare it again with Provider verification set
Refused while impersonating On a SaaS deployment, a platform operator in a support-access session cannot declare a provider The tenant's own administrator declares it

Without the console

Surface How
API POST /api/v3/admin/tenants/{tenantId}/idp/validate (operation validateIdp): checks a candidate configuration without storing it
API POST /api/v3/admin/tenants/{tenantId}/idp (operation createIdp): declares the provider, disabled
API POST /api/v3/admin/tenants/{tenantId}/idp/{id}/test (operation testIdp): runs the self-test
API POST /api/v3/admin/tenants/{tenantId}/idp/{id}/enable (operation enableIdp): enables it

No ankasecure-km command and no Admin SDK method manage identity providers.