uBix Vault, Beta 12 — Identity, and a Second Dependency

After “Done”

Last time, I landed a strange milestone: uBix Vault was, by my own list, engineering-complete for 1.0 — and still not done, because the last gate is an outside security review I’m not allowed to perform on my own work. That’s still true. The review is still the gate.

So what do you build when the finish line is a door someone else has to open? I picked the honest answer: keep closing the gap between “my secrets manager” and “the secrets manager people already know.” Vault’s free, open-source tier has a handful of things uBix Vault didn’t. Beta 12 is me working down that list. None of it moves the 1.0 gate. All of it makes this something you could actually switch to.

Knowing Who You Are

The headline is identity.

Until now, every way you logged in was its own island. Log in with a username and password, and you got a token with some policies. Log in from CI with a signed token, and you got a different token with different policies — and nothing connected the two, even if they were the same person. Want to grant “the platform team” access to a new path? You edited every login method they used, one at a time.

Identity fixes that. Now there’s a subject behind a login — an entity — and every method you authenticate through is an alias that resolves to it. Log in five different ways; you’re still one person to the vault. Attach a policy to the entity, and it applies no matter how you logged in — and it takes effect on tokens you were already issued, not just new ones.

On top of that sit groups: collect entities, give the group a policy, done. Groups nest. And they can be external — driven by your identity provider. If your OIDC login carries a groups claim, or your LDAP user is in a directory group, uBix Vault will place you in the matching group automatically. Your IdP stays the source of truth for who’s on the team; the vault just maps that to what the team can reach.

The piece I’m happiest with is templating. One policy:

secret/data/users/{{identity.entity.name}}/*

That single rule gives every user their own private drawer and no one else’s — the vault substitutes each caller’s own identity at request time. What used to be one policy per person is now one policy, period. And it fails closed: if there’s no identity to fill in, the rule grants nothing.

The Second Dependency

Here’s the part I owe you an honest paragraph about.

Every one of these posts has ended with some version of the same brag: still one dependency. From the first commit, uBix Vault had exactly one third-party library — a MySQL driver — and everything else, all the crypto and protocol work, was the standard library or hand-written. Signing without a signing library. Verifying JWTs without a JWT library. Reaching a KMS without a KMS library. The count never moved.

Beta 12 moves it. Adding LDAP / Active Directory login — the last login method Vault’s free tier has that I didn’t — took the project’s second dependency, a real LDAP client.

I thought hard about not doing it. I could have hand-rolled the protocol; LDAP is just ASN.1 over a socket. But LDAP’s wire format (BER) is genuinely finicky, and this is a login path — the code that decides whether your password is correct. Hand-writing a security-critical binary parser to protect a bragging right is the exact trade the “minimal dependencies” rule was supposed to prevent, not cause. The whole point of avoiding dependencies is fewer places for surprises to hide; a from-scratch BER decoder in the authentication path is more surprise, not less.

So I wrote it down as a decision — with the alternatives and why they lost — and spent the dependency deliberately, the same way I spent the first one on the MySQL driver two years of design-decisions ago. It’s confined to a single thin adapter; the login logic around it is still plain Go I can read in one sitting. Two dependencies now, both earned, both recorded. I’d rather tell you exactly why the number changed than quietly pretend it didn’t.

The Rest of the List

Identity and LDAP are the big two, but beta 12 swept up several smaller gaps:

TLS client-certificate login — authenticate with a mutual-TLS client cert, verified against a CA you trust. No password, no token: the certificate is the credential.
OIDC discovery — point the JWT method at an issuer, and it finds the signing keys itself from the provider’s discovery document, instead of you wiring them by hand.
Cubbyhole — a private scratch space per token that no other token, not even root, can read, and that’s destroyed the moment the token is revoked.
Transit key derivation and convergent encryption — one encryption key can now produce a separate key per context, and optionally encrypt the same input to the same output, so you can dedup or match ciphertexts without ever decrypting them. (That one, for the record, added zero dependencies — it’s built on a standard-library primitive.)

Where It Is

uBix Vault is BSD 3-Clause, on GitHub at github.com/cwolsen7905/uBixVault, tagged v0.2.0-beta.12, with signed images and a roadmap whose “catch up to the free tier” column is now nearly empty.

The engineering for 1.0 was finished last time, and it still is — this is a different kind of work: not can it stand up, but would you switch to it. After beta 12, a Vault user’s answer to “but does it have…” is a lot more often yes. The one honest “not yet” is the same as it was: someone who isn’t me still has to look hard at the crypto. That door hasn’t opened. Everything I can build while I wait, I’m building.