What Is SAML for Secrets Management?
SAML is a single sign-on standard that governs who is allowed to reach your secrets — the identity layer in front of a secrets manager, not the encryption itself.
Definition
SAML (Security Assertion Markup Language) is an open standard for single sign-on: an identity provider — Okta, Entra ID, Google Workspace — authenticates a user once and asserts that identity to other applications, so people log in to many tools with one set of credentials. In the context of secrets management, SAML is the layer that decides who is allowed to reach the secrets, not the layer that stores or encrypts the secrets themselves.
The distinction matters because the two are easy to conflate. SAML answers “is this really Jordan from engineering, and should Jordan have access?” A secrets manager answers “given that it is Jordan, hand over the decrypted database password.” SAML governs the front door — authentication and, via group assertions, coarse authorization. It does not encrypt a single secret. A complete setup uses SAML for identity and a secrets manager for the values, with the two wired together so access follows from identity.
Why it matters
Tying secret access to a central identity provider via SAML is what makes access management scale and stay auditable. Instead of every tool keeping its own user list, access is granted by group membership in one place. When someone joins, the right groups give them the right secrets; when they leave, deprovisioning them in the identity provider cuts access everywhere at once — no per-tool offboarding checklist to forget.
That centralization is also why SAML SSO is a near-universal requirement for selling into larger organizations and passing security review. Auditors want to see that access to sensitive systems is governed by enforced, MFA-backed identity rather than shared passwords. But SAML has a well-known limitation worth naming: it controls who can authenticate to the secrets manager, not what the manager itself can read. If the secrets backend can decrypt your values, then SSO governs access to a system that still holds plaintext — strong identity in front of a vault that can be breached behind it.
Examples
How SAML and secrets management fit together in practice:
- SSO into the secrets dashboard — engineers reach the secrets manager by authenticating through Okta or Entra ID, with MFA enforced by the identity provider rather than a separate password.
- Group-to-access mapping — SAML group assertions map to roles in the secrets manager, so membership in
eng-paymentsgrants access to the payments project's secrets automatically. - One-step deprovisioning — removing a departing employee in the identity provider revokes their path to every connected secrets store at once.
- Audit trail — authentication events flow through the identity provider, giving a central log of who accessed what and when for compliance evidence.
The gap to keep in mind: SAML can prove it was really Jordan logging in, but it cannot stop the secrets backend from reading the values Jordan fetched. Identity and confidentiality are separate guarantees, and a robust setup needs both.
Related terms
- Secrets in DevOpsCredentials like API keys, passwords, and tokens that grant access and must stay confidential — and how they differ from config.
- Secret RotationReplacing credentials on a schedule to cap their exposure — the patterns, the cutover problem, and how automation helps.
- Environment Variables vs SecretsWhy a delivery mechanism and a sensitive credential are not the same thing — and how to store each one safely.
How Capy helps
Capy approaches the identity-versus-confidentiality split from the other side. Where SAML strengthens who can authenticate, Capy strengthens what a breach can expose: every value is encrypted on the client before it leaves, so the service stores ciphertext it cannot decrypt. Strong SSO and a backend that cannot read your secrets are complementary — one governs the front door, the other ensures there is nothing readable behind it.
Capy also makes the offboarding step that SAML triggers actually cryptographic. When access should be removed, capy kick destroys the service-side wrap on that person's key, rendering their local key material inert rather than just flipping a permission flag on a value they may already hold. For the rotation that complements revocation, see secret rotation, and for the underlying categories, see what are secrets in DevOps.
Frequently asked questions
Does SAML encrypt my secrets?+
No. SAML is an authentication standard — it proves who a user is and asserts that identity to applications. It governs access to the secrets manager but does not encrypt the secrets themselves. Encryption is the job of the secrets manager; SAML is the identity layer in front of it.
What is the difference between SAML and a secrets manager?+
SAML answers 'who is this user and should they have access?' A secrets manager answers 'store this value securely and hand it back to authorized requesters.' SAML governs the front door through SSO and group assertions; the secrets manager stores, encrypts, and serves the values. A complete setup uses both together.
Why do enterprises require SAML SSO for secrets tools?+
Centralizing access through one identity provider makes it auditable and consistent: access is granted by group membership, MFA is enforced in one place, and deprovisioning a departing employee cuts access everywhere at once. Security reviews expect sensitive systems to sit behind enforced identity rather than shared passwords.
Is SSO enough to keep secrets safe?+
SSO is necessary but not sufficient. SAML controls who can authenticate to the secrets manager, but if the backend can decrypt your values, a breach of that backend exposes plaintext regardless of how strong the login is. Pairing SSO with client-side encryption — where the service stores only ciphertext it cannot read — closes that gap.
Install Capy in 30 seconds
brew install capysc/tap/capynpm i -g @capy/cli