This walkthrough stores the identity-provider metadata for a SAML or OIDC connection: what to collect from your IdP, how to save it, and what the stored configuration does — and does not — enable today.
The honest summary up front: the page prepares the connection. Login through SSO is a separate flow that is not active in this release.
1. Collect IdP metadata
- For SAML, collect the entity ID, SSO URL, and X.509 certificate from the identity provider.
- For OIDC, collect the issuer URL, client ID, and client secret. Keep the original secret in your organization's approved secret store.
- If you set an enforced email domain, record the intended policy. Enforcement depends on the login flow, which is not active yet.
For SAML collect the entity ID, SSO URL, and X.509 certificate; for OIDC the issuer URL, client ID, and client secret. Keep the original secret in your organization's approved secret store — the platform stores configuration, not your master copy.
2. Save and verify
- Open /settings/sso, choose the protocol, enter the fields, and save. Compare the displayed certificate fingerprint with the value supplied by the identity administrator.
- Today this feature stores metadata only. Users cannot sign in through SAML or OIDC until the separate login flow is implemented.
- Use Remove to delete the stored configuration. Do not communicate the tenant as SSO-enabled while only metadata is present.
After saving, compare the displayed certificate fingerprint with the value your IdP shows. Until the login flow ships, do not communicate the tenant as SSO-enabled — use Remove to delete stored metadata when a pilot ends.