# Single sign-on

> Connect Microsoft Entra ID, Okta, Google Workspace, SAML 2.0 or OpenID Connect to LightHouse, test it with a sign-in, then turn it on for the organisation.

A client administrator connects the organisation’s identity provider to LightHouse™ at **Access → Single sign-on**. Sign-in at the edge is enforced by Cloudflare Access for every tenant (see [Authentication](/api/authentication/)); this page configures the organisation’s provider in Cloudflare Access.

## Requirements

| Requirement       | Detail                                                                                                                |
| ----------------- | --------------------------------------------------------------------------------------------------------------------- |
| Role              | `client_admin`, signed in as a person                                                                                 |
| Identity provider | **Microsoft Entra ID**, **Okta**, **Google Workspace**, **SAML 2.0** or **OpenID Connect**                            |
| Limit             | Up to five identity providers per tenant, in addition to the one-time PIN; refused as `too_many_providers` above that |
| Registration      | An application registered in the identity provider with the values LightHouse shows                                   |

## Client secret

The client secret is sent to Cloudflare Access in the provider’s configuration and is then discarded. LightHouse does not store, log, audit or return it, and Cloudflare Access does not return it. Atlantic staff have no access to it. To change it, use **Replace secret**.

## Values for the identity provider

Under **What to enter in your identity provider**, the page shows:

| Value                      | Use                                                                                                        |
| -------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Redirect URI (ACS URL)** | The address the provider returns the person to after sign-in. For SAML, the assertion consumer service URL |
| **Entity ID (audience)**   | For SAML, the service provider’s entity ID                                                                 |

Register an application with these values, then enter the provider’s details under **Connect an identity provider**.

**Microsoft Entra ID**

In the Microsoft Entra admin centre, register an application (**App registrations → New registration**) with a **Web** redirect URI set to the value LightHouse shows. Create a client secret under **Certificates & secrets**. Grant the delegated Microsoft Graph permissions `openid`, `email`, `profile` and `User.Read`, with administrator consent, and `GroupMember.Read.All` if sign-in rules will use Entra groups.

In LightHouse, enter the **Client ID** (the application ID), the **Directory (tenant) ID** and the **Client secret**.

**Okta**

In the Okta admin console, create an **OIDC – OpenID Connect** app integration of type **Web Application**, with the sign-in redirect URI set to the value LightHouse shows, and assign it to the people or groups who will use LightHouse.

In LightHouse, enter the **Okta organisation URL** (such as `https://example.okta.com`), the **Client ID** and the **Client secret**. For a custom authorisation server, also enter its **Authorisation server ID**.

**Google Workspace**

In the Google Cloud console for the Workspace organisation, create an **OAuth client ID** of type **Web application**, with the authorised redirect URI set to the value LightHouse shows.

In LightHouse, enter the **Client ID**, the **Client secret** and the **Google Workspace domain**.

**SAML 2.0**

In the identity provider, create a SAML application with the ACS URL and entity ID that LightHouse shows, and release the person’s email address as an attribute.

In LightHouse, paste the provider’s **metadata XML**. LightHouse reads the sign-in URL, the issuer and the signing certificates from it. If the email address is released under a non-default attribute name, enter it as **Email attribute**.

**OpenID Connect**

In the identity provider, register a confidential web client with the redirect URI that LightHouse shows.

In LightHouse, enter the **Client ID**, the **Client secret**, the **Issuer URL**, the **Authorisation URL**, the **Token URL** and the **JWKS URL**. If the email address is in a claim other than `email`, enter it as **Email claim**.

## Testing

A new provider starts in the state **Testing**. In this state its Cloudflare Access policy admits only the administrator who connected it, so a misconfigured provider (for example, one that points at the wrong directory or releases a claim that matches every user) admits no other user.

1. Choose **Connect**.

   Result: the provider shows **Testing**, and only the connecting administrator can sign in through it.

2. Sign out, sign in again and choose the new provider.

3. Return to **Access → Single sign-on** and choose **Confirm the test**.

   Result: the provider shows **Tested, ready to turn on**.

The test is accepted only from a session that Cloudflare Access admitted through that provider. A confirmation from any other session or provider is refused.

## Turning it on

Choose which people the provider admits, then choose **Turn on for the organisation**:

| Option                             | Admits                                                         | Condition                                                                                        |
| ---------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| **Everyone with an address at**    | People at one or more [verified domains](/enterprise/domains/) | An unverified domain is refused                                                                  |
| **Everyone the provider signs in** | Every user of the provider                                     | The provider is the organisation’s own: Entra ID, Okta, Google Workspace, SAML or OpenID Connect |

Turning a provider on admits these people at the edge. Each person’s role in LightHouse comes from the sign-in rules on the **Access** page or from a [directory group](/enterprise/provisioning/#directory-group-sign-in-rules). A person whom no rule admits is refused.

| Provider                               | Second factor                 |
| -------------------------------------- | ----------------------------- |
| Entra ID, Okta                         | Proved by the provider        |
| Google Workspace, SAML, OpenID Connect | Required by Cloudflare Access |

`GET /api/v1/me` shows how a person’s second factor was proved.

## One-time PIN, secrets and disconnection

| Action                             | Effect                                                                                                                                                           |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Stop offering the one-time PIN** | Retires the email one-time PIN that a tenant created by sign-up starts with. Available once a provider the administrator connected has been tested and turned on |
| **Replace secret**                 | Sends a new client secret to Cloudflare Access; the previous secret is no longer used                                                                            |
| **Disconnect**                     | Removes the provider, its Access policy and its entry on the tenant’s sign-in page                                                                               |

A provider can be disconnected, or the one-time PIN retired, only while another active sign-in method remains for the tenant’s administrators.

Providers configured by Atlantic before self-service single sign-on was available are shown as **Set up by Atlantic** and remain in use. Changes to them are made through Atlantic support.

## API

| Route                          | Role                                     | Action                                                                     |
| ------------------------------ | ---------------------------------------- | -------------------------------------------------------------------------- |
| `GET /api/v1/sso`              | `client_admin`                           | Lists the providers, their states and the values for the identity provider |
| `POST /api/v1/sso`             | `client_admin`, a person                 | Connects a provider in the state **Testing**                               |
| `POST /api/v1/sso/{id}/test`   | A person signed in through that provider | Confirms the test                                                          |
| `POST /api/v1/sso/{id}/enable` | `client_admin`, a person                 | Turns the provider on: `{"email_domains": [...], "all_users": false}`      |
| `POST /api/v1/sso/{id}/secret` | `client_admin`, a person                 | Replaces the client secret                                                 |
| `DELETE /api/v1/sso/{id}`      | `client_admin`, a person                 | Disconnects the provider                                                   |
| `POST /api/v1/sso/otp/retire`  | `client_admin`, a person                 | Retires the one-time PIN                                                   |

## Audit

Each step is recorded in the tenant’s audit log with the person who made it: `sso_provider_connected`, `sso_provider_tested`, `sso_provider_enabled`, `sso_secret_replaced`, `sso_provider_removed` and `sso_otp_retired`. The client secret is not written to the log.

Source: https://docs.atlanticagenticlabs.com/enterprise/single-sign-on/
