# Single sign-on

> Connect Microsoft Entra ID to a Botyard organization: SAML or OpenID Connect sign-in, SCIM provisioning, group-to-role mapping, and requiring SSO.

Canonical URL: https://docs.botyard.io/docs/sso

Single sign-on (SSO) lets the members of a Botyard organization sign in through your identity
provider instead of with Botyard credentials. SCIM provisioning lets the identity provider add,
update and remove those members automatically, and set their roles from groups.

Botyard supports **Microsoft Entra ID** as the identity provider:

| Capability             | What it does                                                                      | Guide                                                          |
| ---------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| SAML 2.0 sign-in       | Members sign in through an Entra Enterprise application, including single logout. | [SAML: Entra Enterprise application](/docs/sso/entra-saml)     |
| OpenID Connect sign-in | Members sign in through an Entra app registration.                                | [OpenID Connect: Entra app registration](/docs/sso/entra-oidc) |
| SCIM provisioning      | Entra creates, updates and removes members, and maps groups to roles.             | [Provisioning with SCIM](/docs/sso/entra-scim)                 |
| Sign-in policy         | Require SSO for everyone, with an owner break-glass.                              | [Require SSO](/docs/sso/require-sso)                           |

Each organization has one identity provider connection, over either SAML or OpenID Connect. If
you have no preference, choose SAML. It is the default in the setup screen, and members can open
Botyard from the tile in Entra's My Apps.

## Availability

Two things decide whether an organization can set up SSO and SCIM:

* **Botyard enables SSO for your organization.** Until it does, the **Single sign-on** tab shows
  "Single sign-on isn't available for this organization" and nothing to set up. Contact Botyard
  support to request access.
* **Your plan includes the feature.** Single sign-on is included in the Pro and Enterprise plans.
  SCIM provisioning is included in the Enterprise plan only. Organizations on a legacy plan
  that is no longer sold, Business or Early Bird, also have single sign-on but not SCIM
  provisioning.

| Plan                          | Single sign-on | SCIM provisioning |
| ----------------------------- | -------------- | ----------------- |
| Starter                       | No             | No                |
| Pro                           | Yes            | No                |
| Enterprise                    | Yes            | Yes               |
| Business, Early Bird (legacy) | Yes            | No                |

If your organization is enabled but its plan doesn't include a feature, the tab shows an upgrade
card in place of that feature's setup controls, with a **See plans** button. On a plan with single
sign-on but not SCIM, the identity provider and sign-in policy cards are available, and SCIM
provisioning shows an upgrade card.

If your organization moves to a plan without a feature it already set up, the setup keeps working
in a limited way, and the tab shows a banner:

* **Single sign-on:** members can still sign in through the existing connection, and **Require
  SSO** stays as it is. The settings become read-only, except that you can still replace the
  client secret or refresh the metadata, disconnect the identity provider, or turn off **Require
  SSO**.
* **SCIM provisioning:** Botyard refuses Entra's provisioning requests, so add and remove members
  by hand. You can still turn off provisioning and delete group mappings.

The **Sign in with SSO** entry on the login page is always shown. Whether a sign-in succeeds
depends on the organization's identity provider connection, not on the browser.

## Who can manage SSO

Only **organization owners** can connect, change or disconnect an identity provider. The same
applies to provisioning and the sign-in policy. Other members who open the page see: "Single
sign-on and provisioning are managed by organization owners."

## Where to find it

1. Sign in to [app.botyard.io](https://app.botyard.io).
2. Open **User menu** › **Settings** › **General** › **Single sign-on**.

The page has four cards:

* **Identity provider**: connect Entra over SAML or OpenID Connect. This card shows the values to
  paste into Entra and lets you enable, disable or disconnect the connection.
* **Sign-in policy**: **Require SSO** and **Also ask for Botyard two-factor after SSO**.
* **Provisioning (SCIM)**: the Tenant URL and token Entra's provisioning service uses, and its
  health.
* **Group → role mappings**: which Entra groups grant which Botyard role.

## How members are identified

Botyard identifies an Entra user by their directory (tenant) ID and object ID, never by email
address. A connection is pinned to exactly one Entra tenant. Sign-ins from any other tenant are
refused, and so are Microsoft personal accounts.

When someone signs in through your identity provider for the first time, Botyard adds them to the
organization with the **Member** role, if your plan has a free seat. With SCIM provisioning on,
Entra can also add members before their first sign-in, set their role from groups, and remove them
when you unassign them.

Botyard never merges accounts just because an identity provider sends the same email address.
When an Entra identity is not yet linked and its email already belongs to a Botyard account,
the person must prove control of that existing account before linking it.

### Link an existing Botyard account

To link the account:

1. Start SSO for your organization and authenticate with Entra. If that email already has an
   unlinked Botyard account, Botyard opens **Link single sign-on** at `/sso/link` in the same browser.
2. Choose **Sign in to your account** and sign in directly to the existing Botyard account using
   your usual Botyard sign-in method, not SSO. Complete Botyard's authenticator check if you have
   TOTP enrolled. Keep using the browser that started the SSO sign-in.
3. After returning to the linking page, choose **Link account**. If you were already signed in
   before starting this request, are signed in to another account, or used an SSO session, choose
   **Sign in again** and sign in directly to the account for the displayed email address first.
4. Botyard links the identity and starts SSO again. Complete the new Entra sign-in to get an SSO
   session. If the page instead says &#x2A;*Your account is linked.**, use **Go to sign in** and start
   SSO from the login page.

The request expires after 10 minutes and is single-use. If it expires or you switch browsers,
start SSO again to create a new request. There is no email-click-only confirmation: Entra's email
claim is not proof of control of the existing Botyard account.

Linking itself does not create an SSO session or turn the Botyard session used to confirm into
one. The new SSO sign-in applies the organization's **Also ask for Botyard two-factor after SSO**
policy as usual. An account can have only one Entra identity per organization.

## Disable or disconnect a connection

On the **Identity provider** card, a connected identity provider shows an **Active** or
**Disabled** badge and an **Enabled** switch.

**Disabling** the connection (turning **Enabled** off) pauses it without removing anything:

* New sign-ins through it are refused.
* Members who already signed in through it lose access to the organization on their next request.
* No new members join through it.
* Nothing is deleted: the connection, its settings, members and their roles stay as they are.

Turning **Enabled** back on restores all of it. Members who still have a session regain access
without signing in again.

**Disconnect** removes the connection. Members can no longer sign in through it, but their Botyard
accounts and memberships are kept, and you can connect again at any time.

You can't disable or disconnect the connection while **Require SSO** is on, because that would lock
members out. Turn off **Require SSO** under **Sign-in policy** first.
