Organizations Overview

Organizations represent your customers. Each organization is a container for members, verified email domains, SSO connections, and authentication policies. Your application uses organizations to enforce per-customer security requirements and route users to the correct identity provider during sign-in.

Create and manage organizations

An organization requires a name. You can optionally provide an external_id to link the organization to a record in your own system.

The portal provides a dashboard for managing organizations at Organizations in the sidebar. From there you can:

Create a new organization
View and update the organization name
Configure authentication policies
Manage domains, SSO connections, and members

Each organization is scoped to an environment. Organizations in one environment are isolated from organizations in another.

Domain management

Domains associate an email domain (for example, acmecorp.com) with an organization. A verified domain enables two features:

Home realm discovery — when a user signs in with an email matching a verified domain, Seal routes them to the organization’s SSO identity provider automatically
Email trust — users who authenticate through SSO with a verified domain are treated as email-verified without a separate verification step

Add a domain

To add a domain, navigate to Organizations > (select organization) > Domains and enter the domain name. Seal generates a DNS verification token for the domain.

Domain statuses

A domain transitions through the following statuses:

Status	Meaning
`PENDING`	Domain has been added but ownership is not yet confirmed
`PROVISIONING`	Verification is in progress
`VERIFIED`	Domain ownership is confirmed and the domain is active

Only verified domains trigger home realm discovery. If a domain is pending or provisioning, users with matching email addresses sign in using standard authentication methods.

How home realm discovery uses domains

When a user enters their email address during sign-in, Seal extracts the domain portion and checks whether it matches a verified organization domain. If a match is found and the organization has an enabled, published SSO connection, Seal redirects the user to the organization’s identity provider.

For a detailed explanation of how domain routing interacts with different login methods, see the authentication flow page.

Authentication policies

Each organization has three policy flags that control how users authenticate. Configure these from the organization’s overview page in the portal.

Policy	Effect
Require SSO for domain members	Users whose email matches a verified organization domain must authenticate through the organization’s SSO connection. Password, magic link, and other methods are blocked for these users.
Require SSO for guests	Users whose email does not match a verified organization domain must also authenticate through SSO.
Require MFA for non-SSO users	Users who sign in without SSO (password, magic link) must enroll in multi-factor authentication.

These policies are evaluated during the authentication flow. For example, if Require SSO for domain members is enabled and a user with a matching email domain attempts to sign in with a password, Seal redirects them to the organization’s SSO identity provider instead.

Domain-level authentication controls

In addition to organization-level policies, each organization can configure a domain policy that controls which authentication methods are available:

Setting	Description
`allow_sso`	Allow enterprise SSO authentication
`allow_password`	Allow password-based sign-in
`allow_passkey`	Allow WebAuthn passkey authentication
`allow_magic_link`	Allow magic link (email code) sign-in
`allowed_oauth_providers`	List of permitted social login providers (Google, Microsoft, GitHub)
`require_mfa`	Require multi-factor authentication
`auto_membership_enabled`	Automatically add users with matching email domains as members

SSO connections

Each organization can have one SSO connection that links it to an external identity provider. Seal supports two protocols and multiple providers:

Protocols: SAML, OIDC

Providers: Okta, Microsoft Entra ID, Google Workspace, or a generic provider for other SAML/OIDC-compatible identity providers

SSO connection statuses

Status	Meaning
`DRAFT`	Connection is being configured and is not yet active
`PUBLISHED`	Connection is fully configured and available for authentication

A connection must be both published and enabled for Seal to use it during authentication. Draft connections and disabled connections are ignored by home realm discovery.

Just-in-time provisioning

When the should_auto_provision_user flag is enabled on an SSO connection, Seal creates a user account automatically the first time someone authenticates through that connection. This eliminates the need to pre-create user accounts before enabling SSO.

Attribute mapping

SSO connections support attribute mapping to translate identity provider attributes to Seal user fields. Each mapping defines a pair:

IdP attribute name — the attribute key from the SAML assertion or OIDC claims
Environment attribute key — the corresponding field in Seal

This allows Seal to populate user profile data (name, email, department) from the identity provider during authentication.

Members

Members are users who belong to an organization. A user connects to an organization through a membership record that tracks the organization_id, organization_user_id, and a status field.

How users become members

Users join an organization through several paths:

Direct addition — add existing users from the environment to the organization through the portal at Organizations > (select organization) > Members
Just-in-time provisioning — when a user authenticates through an SSO connection with auto-provisioning enabled, Seal creates the user and the membership automatically
Auto-membership — when auto_membership_enabled is set in the domain policy, users with matching email domains are added as members on sign-in

Remove a member

Removing a member deletes the membership record that links the user to the organization. The user account itself is not deleted and can still belong to other organizations.

Multi-organization membership

A single user can belong to multiple organizations. When this user signs in, the authentication flow includes an organization selection step. The user chooses which organization to authenticate into, and the selected organization is included in the access token’s organization claim.

Audit log

Each environment maintains an audit log that records security-relevant events. You can filter audit events by organization to see activity scoped to a specific customer.

Viewing the audit log

The portal provides an audit log viewer at Organizations > (select organization) > Audit Log. You can also view environment-wide audit events from the Audit Logs section in the main sidebar.

The audit log supports filtering by:

Event type — filter by specific event name or search across event types
Date range — filter events by time window
Outcome — filter by SUCCESS, FAILURE, DENIED, or ERROR

Event types

Seal tracks the following categories of events:

Category	Events
Authentication	Password, magic link, SSO, OAuth, MFA, and email verification — both succeeded and failed
Users	Created, updated, deleted
Organizations	Created, updated
Organization domains	Created, deleted
Organization memberships	Created, deleted
SSO connections	Activated, deactivated, deleted
Sessions	Created, revoked, revoked all
Password resets	Created, succeeded

Event structure

Each audit event records:

Field	Description
`event_type`	The type of event (for example, `AUTHENTICATION_SSO_SUCCEEDED`)
`actor`	Who performed the action — includes type (`USER` or `API_KEY`), ID, name, and email
`target`	The resource acted upon — includes type, ID, and name
`outcome`	Result of the action (`SUCCESS`, `FAILURE`, `DENIED`, `ERROR`)
`ip_address`	IP address of the request
`user_agent`	Browser or client user agent string
`occurred_at`	When the event happened
`payload`	Additional event-specific data in JSON format

Click any event row in the portal to view the full detail panel, including actor information, target details, request context, and payload data.

Next steps

Users and Organizations — understand the data model for users, organizations, and memberships
Authentication flow — learn how Seal routes users through sign-in based on organization policies
Enterprise SSO — set up SAML or OIDC connections for your customers