Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.anyshift.io/llms.txt

Use this file to discover all available pages before exploring further.

​
What SSO Provides

Single Sign-On lets your team sign in to Anyshift using your existing identity provider. This centralizes authentication and enforces your organization’s login policies.

​
Supported Providers

Anyshift supports SSO with any SAML or OIDC-compatible identity provider, including:
  • Okta
  • Azure AD (Microsoft Entra ID)
  • Google Workspace

​
Setting Up SSO

Organization admins can configure SSO from the Settings page under the Security section.
1

Select your identity provider

Choose your provider from the list or select a custom SAML/OIDC configuration.
2

Exchange metadata

Follow the guided setup to exchange metadata between Anyshift and your identity provider.
3

Test the connection

Verify that authentication works correctly before enabling SSO for your organization.
4

Enable SSO

Activate SSO for your organization. Users with your company’s email domain will sign in via your identity provider.

​
Sign-In Flows

Anyshift supports two SSO sign-in methods:
  • SP-initiated — users go to the Anyshift sign-in page, enter their email, and are redirected to your identity provider.
  • IdP-initiated — users click the Anyshift app directly from their identity provider’s portal (e.g., Okta dashboard) and are signed in automatically.
Both flows are supported out of the box once SSO is configured.

​
User Provisioning

By default, users must be invited to your organization before they can sign in with SSO. Organization admins can change this behavior in the SSO settings.

​
Require Invitation (default)

Users must be invited by an admin before they can sign in. If an uninvited user tries to SSO, they will see a message asking them to contact their administrator.

​
Auto-Provisioning

When enabled, any user who authenticates through your identity provider is automatically added to the organization as a member. No invitation needed. Auto-provisioned users are:
  • Created with member role (not admin)
  • Assigned to a default project if one is configured (see Default Project Assignment)
  • Immediately active — no email verification step required
To enable auto-provisioning, go to Settings > Security > SSO and select Auto-provision users under User Provisioning.

​
Domain Management

Organization admins can manage email domains from the Settings > Security > Domains section. This section shows all email domains present in your organization (based on your members’ email addresses).

​
Claiming a Domain

When you claim a domain, new users with that email domain cannot create their own separate accounts. Depending on your SSO configuration:
  • SSO with auto-provisioning — new users with that domain will be redirected to SSO and automatically provisioned into your organization.
  • SSO without auto-provisioning — new users with that domain must be invited before they can sign in via SSO.
  • No SSO — new users with that domain must be invited to join your organization.
Consumer email domains (gmail.com, outlook.com, yahoo.com, etc.) cannot be claimed.

​
Unclaiming a Domain

Unclaiming a domain allows users with that email to sign up independently again. Existing members are not affected.

​
Default Project Assignment

For organizations with multiple projects, admins can configure which project auto-provisioned users are assigned to.

​
How It Works

Default project assignment is configured in the Domains section of the Security settings. You can set:
  • Org-wide default — all auto-provisioned users are assigned to this project regardless of their email domain.
  • Per-domain defaults — users from specific email domains are assigned to specific projects. This is useful when different teams use different email domains.

​
Priority Order

When a new user is auto-provisioned, the system determines their project assignment in this order:
  1. Domain-specific default — if a default project is set for the user’s email domain, they are assigned to that project.
  2. Org-wide default — if no domain-specific default exists but an org-wide default is set, they are assigned to that project.
  3. Single-project org — if the organization has only one project and no defaults are configured, the user is automatically assigned to it.
  4. No assignment — if none of the above apply, the user gets organization membership only with no project assignment. An admin must manually add them to a project.

​
Important Notes

  • Email matching is case-insensitive. The email in your identity provider is normalized to lowercase.
  • SSO can be combined with MFA enforcement for additional security.
  • Disabling SSO reverts all users to email/password sign-in.
  • Auto-provisioned users can be promoted to admin after joining.