Enterprise SSO and provisioning

Enterprise SSO lets members sign in through your identity provider (IdP). SCIM lets that provider create, update, and deactivate members without waiting for them to sign in. An organization has one connection; you can enable sign-in, provisioning, or both in Settings > Enterprise SSO as an Admin or Owner.

Before you start

You need permission to register an application with your IdP, its client credentials or SAML metadata, and the public Tale address members will use. Keep a working administrator session open while testing so you can correct the connection if a test sign-in fails.

Choose a Display name members will recognize. When more than one organization on the deployment has SSO enabled, it appears in the organization picker on the public sign-in page, so avoid internal or confidential information.

Choose the protocol

Connect an OIDC or OAuth2 provider

1. Select the protocol in Tale and open Setup guide to find the callback URL.
2. Register a web application with your IdP. Copy the callback URL exactly, including scheme, host, and path. Register each additional callback URL Tale shows if members use several deployment domains.
3. Enter the client ID and secret in Tale. For OIDC, enter the issuer URL; Tale discovers the endpoints. For OAuth2, enter the three endpoint URLs yourself.
4. Review Scopes and Advanced. Request the identity claims your provisioning rules need. Map nonstandard claim names where necessary; claim paths can use dots, such as realm_access.roles.
5. Select Test connection, resolve any error, then Save in the header. Continue with a real sign-in test below.

For Entra, use a tenant-specific issuer such as https://login.microsoftonline.com/{tenant-id}/v2.0, register the callback as a Web redirect URI, and copy the client secret's value rather than its ID. Microsoft's application registration guide explains the provider-side setup. Group-to-team sync requires the Microsoft Graph GroupMember.Read.All permission and admin consent. App roles you define in the app registration and assign to users or groups in the enterprise application arrive in the sign-in token, so an App role rule matches the role's Value (for example Administrator) and needs no Graph permission.

For Google, choose Generic OIDC with issuer https://accounts.google.com; see Google's OpenID Connect setup. Standard Google OIDC does not provide group memberships, so signing in with Google alone does not enable group-to-team sync.

Connect a SAML provider

1. Choose SAML 2.0. Copy the SP metadata URL and ACS (reply) URL into your IdP's SAML application. Use the service-provider metadata for its entity ID/audience and set the Name ID format to email address.
2. Under Import IdP metadata, import the IdP's metadata URL or select Upload XML. Review the entity ID, sign-on URL, and signing certificate filled in by the import. You can also enter them manually.
3. Under Advanced, map email, name, and groups if the IdP uses different attribute names. Keep Require signed assertions enabled.
4. Save the connection, then test a sign-in through the IdP.

If your IdP encrypts assertions, add a matching SP certificate (PEM) and SP private key (PEM) under Advanced. The certificate is published in SP metadata; the private key is stored as a secret and is not shown again. Configure the IdP to encrypt before enabling Require encrypted assertions. Tale refuses that setting without a decryption key and rejects unencrypted assertions when it is enabled.

Both IdP-initiated and Tale-initiated SAML are supported. For a sign-in started in Tale, finish in the same browser so the callback can validate the cookie created at the start.

Assign roles and teams at sign-in

Role rules are checked from top to bottom, and the first rule that matches decides the role. A person who matches several rules — for example, someone with both an Administrator and an Employee app role — gets the role of the rule higher in the list, not automatically the most privileged one. Put the most privileged rules first: drag a rule by its handle or use its Move up and Move down arrows, then save.

Team sync removes memberships it previously granted when groups disappear and deletes teams it created once empty. It preserves memberships created manually or through SCIM, and leaves excluded groups alone. See teams for manual membership management.

Provision members through SCIM

1. In SCIM provisioning, select Generate token and copy it immediately; it is shown once.
2. Enter the token as a bearer credential and the displayed SCIM base URL in your IdP's provisioning configuration.
3. Provision a test user and group. Confirm the member and team appear in Tale, then test updates and deactivation before enabling a wider rollout.

SCIM Users map to members and Groups to teams. Deactivation (active: false) disables the member's access; reactivation restores their previous role. Deleting a SCIM user removes their organization membership but preserves their account. Provisioning them again starts with the connection's default role.

The organization owner cannot be deactivated or removed through SCIM. Groups can contain only members of this organization. A username change is refused if the new email is in use or the account belongs to multiple organizations, protecting its shared sign-in identity.

Sign members in through an authenticating proxy

An application that already authenticates its users can hand them into this organization through its reverse proxy, so members never see Tale's sign-in form. The Trusted headers card on the same page holds the switch, the role ceiling and the keys the proxy presents.

1. Turn on Accept sign-ins from a trusted proxy and choose the Highest role a proxy may assert. The role header is capped at this role; Owner is never assertable. On every sign-in the member's seat follows the asserted role; an Owner seat never changes.
2. Select Create key, name it after the proxy that will hold it, and copy the key immediately; it is shown once. An organization holds at most 10 live keys.
3. Configure the proxy to send its sign-ins to the Hand-off URL with the key in the key header and the identity headers listed under Header names. A member who arrives through the proxy is signed in on the app's first request and never sees a sign-in page; the app offers them no sign-out, since the proxy owns that session. Pointing the proxy's /log-in at the same address remains supported.

To show the pages inside the application's own page, turn on Allow embedding in a frame under Embedding and list the page's origin under Allowed origins; Tale then admits that origin as a frame ancestor. A frame carries the signed-in session only when the surrounding page is on the same site as Tale.

The key decides the organization: a member signs in, an address Tale has never seen becomes a new member with the asserted role, and an existing account from another organization is refused. Turning the switch off refuses every key without revoking one. Revoke stamps a key so the proxy can no longer sign anyone in; sessions it already started stay signed in. The operator's authentication configuration covers header names and proxy requirements.

Verify and troubleshoot

Open a separate browser session and choose Continue with SSO. The organization picker appears only when more than one organization on the deployment has SSO enabled; select the organization by its display name there. Otherwise the button opens the one enabled organization's identity provider directly, and an address typed into the e-mail field is passed along only as a login hint — Tale does not route by e-mail domain. Complete sign-in, then check the expected role and team memberships. Test connection checks connection details; it does not prove that a real user receives the right access.

Disable sign-in stops new SSO sign-ins while keeping active sessions. Remove deletes the connection configuration and credentials. Arrange another working sign-in method before using either action.