Single Sign-On (SSO) for your firm

What SSO does

With SSO enabled, your colleagues sign in to LeyApp through your company's identity provider instead of remembering a separate password. New hires get access the moment IT adds them to the right IdP group; offboarded staff lose access the moment IT removes them.

SSO does not replace LeyApp's user accounts — it links them. Existing accounts on your firm's verified email domains start authenticating via SAML once you switch enforcement on.

Before you can configure SSO

• Your firm must be **verified** (verification badge visible in the firm header). SSO is gated to verified firms because authentication routing is sensitive.
• Your firm must have at least one **email domain** added under Settings → Firm. SSO only routes users whose email matches a configured domain.
• Only firm **owners and admins** see the SSO page. Members get a read-only view that hides metadata and danger-zone controls.

How configuration works

Configuration is a one-time exchange of metadata between your IdP and LeyApp. You give the IdP our Service Provider info (ACS URL and Entity ID), and you give LeyApp your IdP metadata (either as raw XML or a hosted metadata URL).

Step-by-step

1. Open **Dashboard → Firm → SSO**. Copy the ACS URL and Entity ID — these go into your IdP when you create a new SAML application.
2. In your IdP, create a SAML 2.0 application for LeyApp using the values you copied. Configure the user attributes so the email field maps to NameID.
3. Export your IdP's metadata as XML, or copy its hosted metadata URL.
4. Back on the LeyApp SSO page, paste the metadata XML into the **IdP metadata** box (or paste the URL into the metadata URL field) and click **Configure provider**.
5. Test the login by signing out and signing back in with a colleague's domain email. They should be redirected to your IdP.

Enforcement levels

After provisioning, choose how strictly LeyApp enforces SSO for users on your domains:

**Optional** — users on your domain can choose SSO or password. **Preferred** — SSO is offered by default, password fallback still works. **Required** — only SSO logins are accepted; password logins on your domain are blocked.

Domain conflicts

Each email domain can be claimed by only one firm. If you add a domain that another organisation already verified, you will see an error and need to file a dispute via support. The conflict resolution mirrors the firm-claim process — proof of domain ownership wins.

Disabling or deleting SSO

**Disable** keeps the configuration but stops routing new logins through it — useful while debugging an IdP outage. **Delete** removes the SAML provider entirely; users on your domain go back to password login. Both actions live in the danger zone at the bottom of the SSO page and require confirmation.