> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ultra.security/llms.txt
> Use this file to discover all available pages before exploring further.

# Single Sign-On (SSO)

> Configure enterprise SSO for your organization

Ultra Hub supports enterprise Single Sign-On (SSO) via SAML and OIDC identity providers, as well as Google social sign-in. SSO allows your team to authenticate using your organization's existing identity provider instead of email verification codes.

## SSO Options

Ultra supports two types of SSO:

* **Enterprise SSO** — SAML or OIDC connections with identity providers like Okta, Azure AD, Google Workspace, and others. Requires an Enterprise plan.
* **Google Sign-In** — "Continue with Google" for organizations using Google Workspace. Available on all plans.

## Enterprise SSO

Enterprise SSO integrates with your organization's identity provider via SAML 2.0 or OpenID Connect (OIDC). Ultra delegates IdP protocol handling to its SSO service, so your users authenticate at their familiar corporate login page.

### Supported Providers

| Provider            | Protocol       |
| ------------------- | -------------- |
| Auth0               | SAML           |
| Azure AD (Entra ID) | SAML           |
| Google Workspace    | SAML           |
| JumpCloud           | SAML           |
| Microsoft AD FS     | SAML           |
| Okta                | SAML           |
| OneLogin            | SAML           |
| PingOne             | SAML           |
| Rippling            | SAML           |
| Generic SAML 2.0    | SAML           |
| OIDC Provider       | OpenID Connect |

Any SAML 2.0 or OIDC-compliant identity provider can be connected using the generic options.

### Setting Up Enterprise SSO

<Steps>
  <Step title="Generate a setup link">
    Navigate to **Settings > Security** in the Ultra Hub dashboard. Under **Enterprise SSO**, click **Generate Setup Link** to create a self-service configuration URL.

    The setup link URL appears with a **Copy** button and a **Revoke** button. Copy this link and share it with your IT team if they manage your IdP. The link opens a guided wizard where they can enter your IdP details (metadata URL for SAML, or discovery URL and client credentials for OIDC).

    <Note>
      Setup links have an expiration date displayed below the URL. You can revoke an active link and generate a new one at any time.
    </Note>
  </Step>

  <Step title="Configure your identity provider">
    Open the setup link and follow the guided wizard. The wizard provides provider-specific instructions for each supported identity provider, including the exact values to enter in your IdP's admin console.

    Select your provider from the list and follow the step-by-step instructions within the wizard to complete the connection.
  </Step>

  <Step title="Verify the connection">
    After completing the wizard, the connection details appear in the **Enterprise SSO** section of the Security tab showing:

    * **Connection** -- The connection name (e.g., "Ultra SSO Setup")
    * **Type** -- The protocol badge (SAML or OIDC)
    * **Status** -- The connection status (ACTIVE when working)

    Click **Test Connection** to verify the SSO flow works before rolling it out to users. If something is misconfigured, you can click **Disable SSO** and re-do the setup.
  </Step>
</Steps>

### SSO Login Flow

Once SSO is enabled, the login experience changes based on your policy settings:

1. A user enters their email address on the Ultra Hub login page
2. Ultra detects the user's email domain and looks up the matching SSO connection
3. The user is redirected to their identity provider to authenticate
4. After successful authentication, the user is redirected back to Ultra Hub with an active session

If the user doesn't exist in Ultra Hub yet and [JIT provisioning](#just-in-time-provisioning) is enabled, their account is created automatically on first login.

<Note>
  **Existing users**: If a user previously signed in with a magic link (email code) and then SSO is enabled, their account is automatically linked on first SSO login. No manual action is required -- the user signs in through the IdP and their existing Ultra Hub account is preserved with all data intact.
</Note>

### Policy Settings

Configure SSO behavior in **Settings > Security > SSO Policy**.

**Enforce SSO** — When enabled, users with matching email domains must authenticate via SSO. Magic link (email code) login is blocked for those users. This ensures all authentication goes through your IdP.

**Just-in-Time (JIT) Provisioning** — When enabled, new users who authenticate via SSO are automatically provisioned in Ultra Hub with the Member role and added to your organization. When disabled, users must be pre-provisioned (via [SCIM](/hub/scim) or manual invitation) before they can log in.

**Required Domains** — Email domains that must use this SSO connection. Users with matching domains are routed to SSO. If left empty, domain routing falls back to the organization's allowed domains setting.

<Warning>
  Before enabling **Enforce SSO**, verify that your SSO connection is working correctly using the **Test Connection** button. If the connection is misconfigured, users with matching domains will be unable to log in.
</Warning>

### CLI Authentication with SSO

The Ultra CLI supports SSO authentication:

```bash theme={null}
# Standard login (auto-detects SSO if available for your email domain)
ultra login

# Explicit SSO login
ultra login --sso
```

When SSO is detected for your email domain, `ultra login` redirects through your identity provider in the browser. The `--sso` flag skips email entry and goes directly to SSO authentication.

### Managing SSO Connections

Once SSO is enabled, the **Enterprise SSO** section in **Settings > Security** shows the active connection with its type and status. From here you can:

* **Test Connection** -- Verify the SSO flow is working by triggering a test authentication
* **Disable SSO** -- Remove the SSO connection and revert users to magic link authentication

To update the SSO configuration (e.g., change SAML metadata or IdP settings), generate a new setup link and re-run the wizard. The new connection replaces the existing one.

## Google Sign-In

Google sign-in provides a lightweight SSO option for organizations using Google Workspace. Users see a **Continue with Google** button on the login page and can authenticate with their Google account.

### How It Works

1. User clicks **Continue with Google** on the Ultra Hub login page (or enters an email with a matching domain)
2. User authenticates with their Google account
3. Ultra Hub creates or links their account and starts a session

### Configuring Google Sign-In

Navigate to **Settings > Security > Google** to configure:

* **Enforce for domains** — Require users with matching email domains to sign in with Google instead of magic links
* **JIT provisioning** — Automatically create accounts for new users who sign in with Google
* **Domains** — Email domains for Google Sign-In enforcement and JIT provisioning (e.g., `yourcompany.com`)

<Note>
  Public email domains (gmail.com, outlook.com, yahoo.com, etc.) cannot be used for SSO domain enforcement. Only corporate/organizational domains are accepted.
</Note>

### Domain Validation

When configuring SSO domains (for both enterprise SSO and Google sign-in), Ultra enforces two levels of validation:

1. **Public email blocklist** — Common free email providers (Gmail, Outlook, Yahoo, etc.) are rejected to prevent accidental enforcement on personal accounts
2. **Allowed domains subset** — If your organization has an allowed domains list configured, SSO domains must be a subset of that list

## Security

Ultra SSO includes several security measures:

* **CSRF protection** — Login flows use cryptographic state parameters to prevent cross-site request forgery
* **Flow expiration** — SSO login flows expire after 10 minutes. Expired flows are automatically cleaned up
* **Webhook signature verification** — SCIM webhooks are verified using HMAC-SHA256 signatures with timestamp validation to prevent replay attacks
* **Deactivated user blocking** — Users deactivated via SCIM or by an admin are blocked from SSO login even if their IdP session is still valid

## Permissions

SSO configuration requires the `org:update` permission. Only **Owners** and **Admins** can manage SSO settings. See [RBAC](/hub/rbac) for the full permissions matrix.
