> ## Documentation Index
> Fetch the complete documentation index at: https://seal-d2ca5bea.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Single sign-on (SSO)
> Enterprise authentication with Microsoft Azure AD and support for additional identity providers. Seal supports enterprise SSO, integrating with your existing identity provider for centralised authentication.
## Supported identity providers
| Provider | Protocol | Status |
| --------------------------------- | -------------------------- | -------------------- |
| **Microsoft Azure AD (Entra ID)** | OAuth 2.0 / OpenID Connect | Available |
| Okta | SAML / OIDC | Available on request |
| Google System | OIDC | Available on request |
| Custom SAML/OIDC | SAML 2.0 / OIDC | Available on request |
For other identity providers, contact [support@seal.run](mailto:support@seal.run).
## How SSO works
### Domain-Based Routing
SSO is configured per organisation with specific email domains. Users with SSO-enabled domains are automatically redirected to the identity provider — password login is disabled for these domains.
## Configuration options
| Option | Description | Example |
| --------------------- | ----------------------------------------- | -------------------------------------- |
| **Identity Provider** | SSO provider | Microsoft Azure AD |
| **Email Domains** | Domains requiring SSO | `acme.com`, `acme.co.uk` |
| **Tenant ID** | Organisation's Azure AD tenant (optional) | `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` |
Multiple domains can be configured per organisation — useful for subsidiaries, regional variations, or acquisitions. All domains route to the same IdP.
## Security
| Feature | Details |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Enforced SSO** | Password login disabled for SSO domains |
| **No password storage** | Seal never receives or stores SSO user passwords |
| **MFA inheritance** | Users inherit MFA requirements from IdP |
| **Session timeout** | Optional organisation-level inactivity timeout. We recommend leaving this off when suitable device lock policies are in place. Applies to all authentication methods — SSO and native login. |
**21 CFR Part 11 Compliance**
SSO strengthens Part 11 compliance by leveraging your organization's existing password policies, MFA requirements, and centralized access control. Seal also requires re-authentication or signature confirmation for sensitive actions. Optional inactivity timeout presets are available for shared GMP workstations or environments without suitable device lock controls, but we recommend leaving them off when endpoint lock policies are working. See [21 CFR Part 11](/regulatory-standards/21-cfr-part-11) for full details.
## Setup
To enable SSO, provide:
1. Email domains for SSO enforcement
2. Azure AD Tenant ID
3. Technical contact
Contact [support@seal.run](mailto:support@seal.run) to begin SSO setup.
##### Step 1: Find Your Azure Tenant ID
1. Log in to the [Azure Portal](https://portal.azure.com)
2. Go to **Microsoft Azure** → **Manage Microsoft Entra ID**
3. On the **Overview** page, locate the **Tenant ID** field
4. Copy the Tenant ID (it will be a GUID format like `12345678-1234-1234-1234-123456789abc`)
##### Step 2: Grant Admin Consent for Seal's Microsoft App
Seal's Microsoft sign-in uses a multi-tenant OAuth application. A tenant admin needs to grant a one-time admin consent before users from your tenant can sign in. You do **not** need to register a separate app in your tenant or share any client credentials with Seal.
If your tenant disables end-user consent (the default in many enterprise environments), admin consent is **required** — without it, sign-ins will fail with `AADSTS65001` ("the user or administrator has not consented to use the application"). If end-user consent is allowed, the first user to sign in will see a consent prompt and admin consent only saves them that one click.
A tenant admin should open this URL (signed in as a tenant admin) and approve the consent prompt:
```
https://login.microsoftonline.com/{YOUR_TENANT_ID}/adminconsent?client_id=4d54ef09-f3c4-44a6-8d99-d111519f1fe7
```
Replace `{YOUR_TENANT_ID}` with the Tenant ID from Step 1. The `4d54ef09-…` client ID is Seal's Firebase Microsoft OAuth app — it's the same value for every customer.
After consent is granted, the application appears in **Microsoft Entra ID → Enterprise Applications**. You can apply Conditional Access policies, restrict access to specific user groups, or otherwise govern sign-ins to it from there.
##### Step 3: Provide Information to Seal
Send the following information to your Seal contact:
1. **Azure Tenant ID** (from Step 1)
2. **Email Domains** (e.g., `yourcompany.com, yourcompany.co.uk`)
3. **Technical contact**
#### What Happens After You Provide the Information
Once Seal receives your information, we will configure SSO for your organization and notify you when it's ready. This typically takes 1-2 business days.
#### Testing SSO
After Seal completes the configuration:
1. Go to the Seal login page
2. Enter an email address with one of your configured domains
3. You should see a **"Sign in with Microsoft"** button
4. Click the button and sign in with your Microsoft credentials
5. You should be redirected back to Seal and logged in successfully
If you have an existing Seal account with a password, you may need to link your accounts on first SSO login. The system will guide you through this process.
## User provisioning
| Method | Description |
| ---------------------- | ----------------------------------------------------------- |
| **Just-in-Time (JIT)** | Users auto-created on first SSO login |
| **Manual** | Admins pre-create accounts |
| **SCIM** | Automated provisioning/deprovisioning from IdP (enterprise) |
SCIM enables automated user lifecycle management — users are created when they join and removed when they leave, with role synchronisation from your IdP.
## FAQ
**Can users still use password login after SSO is enabled?**
No. SSO domains enforce IdP authentication only.
**What if our IdP is unavailable?**
Users cannot authenticate until IdP service is restored.
**Can we mix SSO and password users?**
Yes. SSO is per-domain — other domains can use password login.
**Does SSO work with MFA?**
Yes. MFA is enforced at your IdP level. When SSO is enabled for your organization, Seal's 2FA is automatically disabled, as SSO users rely on their Identity Provider's MFA instead.
**Can we use our own Azure AD tenant?**
Yes. Provide your tenant ID.
**What is the purpose of providing Tenant ID?**
Providing your Tenant ID ensures only users from your Azure tenant can sign in, adding an extra layer of security.
**Do we need to create an app registration in our Azure tenant?**
No. Seal's Microsoft sign-in goes through a shared, multi-tenant Firebase OAuth app. The only action required on your tenant is the one-time admin consent in Step 2 above. No client credentials are exchanged.
**Can we apply Conditional Access policies to Seal sign-ins?**
Yes. After admin consent in Step 2, Seal's Firebase Microsoft application (client ID `4d54ef09-f3c4-44a6-8d99-d111519f1fe7`) appears in your Enterprise Applications list. Apply CA policies to that application — or to "all cloud apps" — to gate Seal sign-ins.
**How does SSO work with electronic signatures?**
SSO users re-authenticate via their Identity Provider at the point of signing, inheriting any MFA requirements configured by your organization. This satisfies 21 CFR Part 11 requirements for signature verification.