Single sign-on

Sablefort Keyvault supports single sign-on (SSO) through SAML 2.0 and OpenID Connect (OIDC), and automated user lifecycle management through SCIM 2.0. SSO lets members authenticate to Sablefort with your existing identity provider (IdP); SCIM keeps membership in sync as people join, move, and leave.

Prerequisites

• Organization owner or administrator access to the Sablefort admin console.
• At least one verified email domain (configured during deployment).
• Administrator access to your IdP (for example Okta, Entra ID, Google Workspace, or any SAML/OIDC-compliant provider).

Option A: SAML 2.0

SAML is the most widely supported option and works with virtually every enterprise IdP.

1. Gather Sablefort's service provider details

In the admin console, open Settings → Single sign-on and choose SAML. Sablefort displays the values your IdP will need:

Field	Example value
SP Entity ID / Audience	https://sso.sablefort.com/saml/metadata
ACS (Reply) URL	https://sso.sablefort.com/saml/acs
SP metadata URL	https://sso.sablefort.com/saml/<org-id>/metadata.xml
Name ID format	EmailAddress

2. Create the application in your IdP

Add a new SAML application in your IdP and paste in the SP Entity ID and ACS URL above. Configure the assertion to send these attributes:

email        => user.email
firstName    => user.givenName
lastName     => user.familyName

3. Return the IdP metadata to Sablefort

Copy your IdP's metadata URL — most providers expose one such as https://idp.example.com/app/exk1a2b3c/sso/saml/metadata — and paste it into the Sablefort SSO settings, or upload the metadata XML directly. Sablefort reads the sign-in URL and signing certificate from it.

4. Test and enforce

1. Use Test connection to run a round-trip login with your own account.
2. When the test passes, set the policy to SSO required for members on verified domains.
3. Keep at least one owner account on password + two-factor as a fallback in case the IdP is unavailable.

Option B: OpenID Connect (OIDC)

OIDC is a good fit for providers built around OAuth 2.0. In Settings → Single sign-on, choose OIDC and register Sablefort as a confidential client in your IdP.

Sablefort's redirect URI is:

https://sso.sablefort.com/oidc/callback

Then supply the following from your IdP into the Sablefort settings:

Field	Example value
Issuer / Discovery URL	https://idp.example.com/.well-known/openid-configuration
Client ID	sablefort-keyvault
Client secret	(generated by your IdP)
Scopes	openid email profile

Sablefort uses the discovery URL to locate the authorization, token, and JWKS endpoints automatically. Save, then run Test connection.

SCIM provisioning

With SCIM 2.0 enabled, your IdP creates, updates, and deactivates Sablefort members automatically, so you no longer invite or remove people by hand. This keeps access aligned with your directory: when someone is offboarded in your IdP, their Sablefort membership is deactivated.

1. Enable SCIM in Sablefort

Under Settings → Provisioning, turn on SCIM. Sablefort shows the connection details for your IdP:

Field	Value
SCIM base URL	https://scim.sablefort.com/v2
Auth	Bearer token (generated once; copy it immediately)

2. Configure provisioning in your IdP

Paste the SCIM base URL and bearer token into your IdP's provisioning settings, then enable Create, Update, and Deactivate operations. Map at minimum:

userName        => email
name.givenName  => first name
name.familyName => last name
active          => account status

3. Assign groups (optional)

If your IdP pushes groups over SCIM, you can map an IdP group to a Sablefort team so that team membership follows your directory. Vault access is still granted per team inside Sablefort; SCIM controls who is in the team, not what the team can decrypt.

What SSO and SCIM do not change

• Members still set and hold their own master password on their device.
• Deactivating a user removes their access to sync and to the org, but does not transmit their plaintext anywhere.
• Recovery still follows the org recovery process — see Backup & recovery.