Before you start
An authorised administrator should agree identity-provider ownership, approved domains and workspace access mappings. Available protocols and provisioning depend on deployment and entitlement. Test before directing all users to a new sign-in route.
Distinguish the protocols
SAML and OpenID Connect support federated sign-in. OAuth 2.0 governs delegated authorisation; it is not, by itself, a complete user sign-in protocol. SCIM provisioning manages users/groups through its configured mappings.
Microsoft Entra ID, Okta or another compatible provider may be used where supported. A provider group or job title does not automatically confer every platform permission.
Prepare and verify the change
- Agree provider, domains, intended users and access mapping with the identity owner.
- Use the supported configuration and test controls and verify domain ownership.
- Test an authorised user’s sign-in, expected role and restricted actions before enabling routing.
- Follow the independent approval/activation requirements shown by the application.
- Verify session/MFA requirements and the joiner/leaver process for the agreed deployment.
Maintain access
Review mappings when roles change and verify deprovisioning/session revocation through the supported route. Preserve ownership and audit history.
Escalate failures with the time, environment and visible identity error. Do not disclose SAML assertions, client secrets, bearer tokens or recovery codes in ordinary help requests.