Documentation
Getting started
Guides
Docs / Organization SSO
Organization SSO
Connect a SAML identity provider, link existing members, and require organization sign-in after testing recovery and credentials.
Configure SAML
Organization SSO is available to organizations enabled for the rollout. An administrator opens the organization SSO settings and enters the identity provider entity ID, HTTPS SSO URL, signing certificate, and email claim name. You can upload identity provider metadata XML instead. BoringCache shows its service provider metadata URL on that page.
Configure the identity provider to send a signed SAML assertion to the assertion consumer URL in the BoringCache metadata. The assertion must include a stable NameID and the configured email claim. BoringCache uses the NameID within this organization for returning sign-ins. The email claim must match the existing BoringCache account when a member links for the first time.
Members first create and confirm their BoringCache accounts, accept their invitations, and link those accounts with a recent independent sign-in and an SAML response. An SAML assertion does not create a BoringCache account or assign an organization role.
Enable enforcement
The primary organization administrator tests the current connection using their account, registers a BoringCache passkey, and saves the recovery codes. That administrator then reviews existing organization and workspace tokens and MCP connections. Revoke or replace legacy scoped credentials and reconnect MCP clients before selecting Required mode.
Optional mode lets members link and use organization SSO while existing account sign-in still works. Required mode requires a current organization SSO grant for browser, CLI, and MCP access. An ordinary account sign-in still permits access to a personal account and organizations that do not require SSO.
Updating the identity provider URL, entity ID, certificate list, or email claim invalidates the connection test and existing organization grants. Upload new signing certificates before retiring old ones, then test the updated connection before relying on it.
CLI and machine access
Choose an organization workspace in the CLI browser approval flow after signing in with that organization's SSO. Human CLI tokens and MCP connections expire no later than the organization SSO proof, up to eight hours. Repeat organization sign-in to issue a new human credential after expiry. User-wide tokens cannot access a required SSO organization.
Organization administrators can approve scoped machine credentials after recent organization SSO. Machine credentials have their own expiry and revocation. Removing the approving member does not revoke an approved machine credential; administrators should review and rotate any reusable secret the departing member knew. Workload OIDC remains available for CI where configured.
Recovery and offboarding
If the identity provider connection stops working, the primary organization administrator can sign in to the BoringCache account with a passkey and use one unused recovery code to change the connection mode to Optional or Off. Recovery changes enforcement; it does not grant organization access. BoringCache emails the primary administrator after recovery.
Removing a member or disabling their linked SSO identity revokes their organization grants and human credentials. A registry bearer token already issued can remain valid for up to five minutes. A direct storage URL already issued can remain valid for up to 24 hours, depending on the storage connection and transfer size. An operation already in progress may finish. Provider-side account disablement is detected at the next SAML sign-in. Existing BoringCache organization grants can remain valid for up to eight hours unless an administrator removes the member or disables the linked identity. This release does not provide automatic directory provisioning or SAML Single Logout.
Need help or found something unclear? Open an issue or browse the CLI repo.