Enterprise SSO

Enterprise onboarding is a persistent step-by-step flow at Enterprise setup. It shows one task at a time, with Back/Continue navigation and the current step in the URL. Owners and admins can leave it and resume later. The first choice is:

• Standard access: Google and email/password are one path.
• SSO: guided SAML configuration and just-in-time membership.

Okta, OneLogin and Google Workspace SAML are available. Microsoft Entra ID and Other SAML provider are shown as in progress and cannot be selected yet.

Configure Okta

1. Optionally request a dedicated Slack onboarding channel.
2. Xainvault derives one company email domain from the signed-in work address: alex@example.com authorizes example.com. Add the displayed DNS TXT record and verify it. Each completed domain proof can belong to only one Enterprise Vault at a time.
3. Copy Xainvault's ACS URL and Entity ID/Audience into a SAML 2.0 app. Use an email NameID.
4. Send email, firstName, lastName and groups. Assign the users/groups who should use the app, and filter the groups assertion to the relevant set.
5. Paste the provider's public HTTPS metadata URL. Xainvault does not ask for certificates or endpoints separately.
6. Test sign-in by provider ID. The domain is not discoverable during testing.
7. Review the identity and group names received.
8. Select which groups to sync and map each to member or admin. Admin wins when several mapped groups apply; no recognized mapping defaults to member.
9. Activate the connection. Domain-based SSO login becomes available and the activation is audited.

Step 4 includes a How to configure Okta guide for the identity administrator. It shows the current Okta Admin Console path, every SAML field and Xainvault value, copy controls for the ACS URL and Entity ID, the exact case-sensitive attribute mappings, the recommended scoped group filter, app assignment and assertion-preview checks, and both places where Okta may expose the Identity Provider metadata URL.

For a custom Okta application, use these mappings:

Okta field	Xainvault value
Single sign-on URL	The ACS URL shown in setup
Audience URI (SP Entity ID)	The Entity ID shown in setup
Name ID format	EmailAddress
Application username	Email
Attribute statement email	user.email
Attribute statement firstName	user.firstName
Attribute statement lastName	user.lastName
Group Attribute Statement groups	A narrow filter such as ^xainvault-.*

Assign one test user before testing and verify the assertion contains all four attributes. Then copy Metadata URL from the app's Sign On → Metadata details area. Some Okta layouts label the same resource Identity Provider metadata under View SAML setup instructions. Paste that public HTTPS URL, not Okta's Sign-On URL. Never send Xainvault a certificate or private key.

Configure OneLogin

1. Optionally request a dedicated Slack onboarding channel and verify the company email domain with the displayed DNS TXT record.
2. In OneLogin Administration, open Applications → Add App, add SAML Custom Connector (Advanced), and name it Xainvault.
3. Set Audience (EntityID) to the Entity ID shown by Xainvault. Set both Recipient and ACS (Consumer) URL to the displayed ACS URL. Leave Default RelayState empty.
4. Copy the exact ACS (Consumer) URL Validator from Xainvault. It is the regex-escaped ACS URL anchored with ^ and $; Preview and Production show different values.
5. In Parameters, set NameID to Email with SAML NameID format emailAddress. Add email, firstName and lastName and include them in the assertion.
6. Add groups, turn on Include in SAML assertion and Multi-value parameter. We recommend OneLogin Roles beginning xainvault-, filtered by an application rule. MemberOf with CN extraction is an alternative.
7. Assign one test user first. Verify the assertion contains separate values for each group, not one comma-separated value.
8. Copy the public URL shaped like https://app.onelogin.com/saml/metadata/..., paste it into Xainvault, then complete the provider-ID test and activation. Do not paste the login endpoint or upload a certificate.

The in-product How to configure OneLogin dialog shows and copies the current environment's ACS, Entity ID and exact validator. The supported public login flow starts from Xainvault; the OneLogin application tile / IdP-initiated flow is not part of the current contract.

Configure Google Workspace

1. Optionally request a dedicated Slack onboarding channel and verify the company email domain with the displayed DNS TXT record.
2. As a Google Workspace super administrator, open Apps → Web and mobile apps → Add app → Add custom SAML app and name it Xainvault.
3. Download the IdP metadata XML from Google Identity Provider details.
4. Copy Xainvault's ACS URL and Entity ID into the custom application. Use EMAIL Name ID format and Basic Information → Primary email as Name ID.
5. Map Primary email to email, First name to firstName, and Last name to lastName.
6. Under Group membership, select only the groups Xainvault needs and map them to the app attribute groups. We recommend xainvault-admins and xainvault-members. Google supports up to 75 selected groups.
7. Turn on access for one test user, group or organizational unit. Access changes can take time to propagate.
8. Upload the downloaded XML, complete the provider-ID test, map received groups to member/admin, and activate the verified domain.

The XML must be valid UTF-8 SAML IdP metadata and no larger than 256 KiB. Xainvault rejects binary input and DTD/entity declarations, sends the document directly to Supabase, and stores only its SHA-256 fingerprint. Replacing it disables domain discovery until a new test succeeds.

The TXT check looks for the exact host and value shown in setup. Xainvault checks public DNS as a fallback when its normal resolver still caches the old "record not found" result. The button stays in a visible Checking public DNS… state until the check finishes, and tells you separately if DNS could not be reached or if the verified result could not be saved.

The domain is read-only and comes from the signed-in work email: alex@eu.example.com authorizes only eu.example.com. The server repeats that check and rejects www., full email addresses, URLs, paths and malformed hostnames. A TXT value expires after 48 hours. Generate new TXT value creates a fresh value and invalidates the previous one, while an abandoned pending attempt does not reserve the domain.

A completed proof belongs to one Enterprise Vault. Before an SSO connection is registered, an owner/admin can expand Release this company domain, type the domain exactly and release it for another Vault. Once a connection exists, it must be offboarded first. Changing between Okta, OneLogin or Google Workspace does not by itself require proving the same Vault domain again.

If an older setup shows a verified value beginning with www., Xainvault treats it as unverified and keeps the Identity step locked. Enter the exact suffix used by member email addresses and complete the new TXT verification. Xainvault does not remove www. automatically because control of that hostname does not prove which domain appears after @.

Enterprise v1 connects one verified domain and one provider. Activating SAML only enables SSO discovery for that exact domain; it does not affect accounts on other domains. Activation also does not force SSO. Owners and admins can turn on Require single sign-on separately in Settings → Security, after reviewing the sign-in impact.

Private, local, credential-bearing or non-HTTPS Okta and OneLogin metadata URLs are rejected. Google XML is bounded and validated as described above. SAML provider metadata and Supabase Management API access remain server-only.

Replacing any provider's metadata temporarily removes domain discovery, clears the previous bounded identity/group preview and test, and requires a new provider-ID login before reactivation.

Login and capacity

Every SSO login updates the membership role and selected externally managed groups. SSO and IdP groups can never grant owner. If a person is already an owner, group synchronization never downgrades them.

SSO membership takes one licensed seat at first login. A full workspace blocks the membership without buying a seat automatically, and notifies owners. An IdP assignment alone does not reserve capacity.

SSO identities are separate from Google/password identities with the same email. Use an assigned test user for the provider-ID test, then return with the owner/admin account to map groups and activate the domain.

There is no SCIM, provider directory sync or complete SAML single logout in v1. Removing an assignment in OneLogin blocks future OneLogin authentication, but does not delete the Xainvault membership or revoke an existing Xainvault session. An owner or admin must remove the membership in Team → People.

Finish setup

Finish Enterprise setup marks the persistent flow complete and opens the Enterprise Vault. It does not start a new charge, change license capacity, or require SSO. Billing continues according to the trial or subscription shown at the top of onboarding.

Dedicated Slack onboarding channel

The dedicated Slack channel is recommended for SSO onboarding. The request records the provider, blocked step, requesting owner/admin, message and contact emails. It is saved first and emailed to Xainvault support; the status card shows whether that support email is pending, sent or failed. The listed contacts are included for follow-up but are not automatically emailed. The Xainvault support team creates the channel manually and coordinates setup with the listed identity administrators. A saved request and its email delivery never block activation.