Documentation Index
Fetch the complete documentation index at: https://docs.seal.run/llms.txt
Use this file to discover all available pages before exploring further.
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.
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 |
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. |
Setup
To enable SSO, provide:- Email domains for SSO enforcement
- Azure AD Tenant ID
- Technical contact
Contact support@seal.run to begin SSO setup.
Step-by-step guide for configuring SSO
Step-by-step guide for configuring SSO
Step 1: Find Your Azure Tenant ID
- Log in to the Azure Portal
- Go to Microsoft Azure → Manage Microsoft Entra ID
- On the Overview page, locate the Tenant ID field
- 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.{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:- Azure Tenant ID (from Step 1)
- Email Domains (e.g.,
yourcompany.com, yourcompany.co.uk) - 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:- Go to the Seal login page
- Enter an email address with one of your configured domains
- You should see a “Sign in with Microsoft” button
- Click the button and sign in with your Microsoft credentials
- 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) |
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 ID4d54ef09-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.