Skip to main content

​
Supported identity providers

ProviderProtocolStatus
Microsoft Azure AD (Entra ID)OAuth 2.0 / OpenID ConnectAvailable
OktaSAML / OIDCAvailable on request
Google WorkspaceOIDCAvailable on request
Custom SAML/OIDCSAML 2.0 / OIDCAvailable on request
For other identity providers, contact [email protected].

​
How SSO works

SSO Authentication Flow Diagram

​
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

OptionDescriptionExample
Identity ProviderSSO providerMicrosoft Azure AD
Email DomainsDomains requiring SSOacme.com, acme.co.uk
Tenant IDOrganisation’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

FeatureDetails
Enforced SSOPassword login disabled for SSO domains
No password storageSeal never receives or stores SSO user passwords
MFA inheritanceUsers inherit MFA requirements from IdP
Session timeout15-minute default for Part 11 compliance (configurable)
21 CFR Part 11 ComplianceSSO strengthens Part 11 compliance by leveraging your organization’s existing password policies, MFA requirements, and centralized access control. The 15-minute session timeout is enabled by default to meet Part 11 requirements. See 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 [email protected] to begin SSO setup.
Step 1: Find Your Azure Tenant ID
  1. Log in to the Azure Portal
  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: Create an OAuth 2.0 App Registration in Azure
  1. In the Azure Portal, use the search bar to navigate to App registrations
  2. Click New registration
  3. Fill in the registration details:
    • Name: Seal Platform SSO (or any descriptive name)
    • Supported account types: Select “Accounts in this organizational directory only” (single tenant)
    • Redirect URI:
      • Select Web as the platform type
      • Enter: 
        https://opvia-platform-prod.firebaseapp.com/__/auth/handler
  4. Click Register
The redirect URI must match exactly. Ensure there are no trailing slashes and that the protocol is https.
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

MethodDescription
Just-in-Time (JIT)Users auto-created on first SSO login
ManualAdmins pre-create accounts
SCIMAutomated 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. 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.