The name is the identity
In LDAP the distinguished name is the person. Rename someone, or move them to another unit, and every reference to them breaks.
Why it exists
Why we decided to build Cardinal
Every organisation we looked at ran the same stack: a directory for the accounts, a portal in front of the applications, and access rules in two or three other places. It works. It also cannot tell you who had access in March, or why somebody was refused today.
The problem
What the usual stack gets wrong
None of this is a bug in any one product. It is what happens when the directory, the portal and the rules are three systems that each know a third of the story.
Access never ends by itself
A grant is permanent until somebody remembers to remove it. "Who had access in March?" means digging through logs, if they were kept.
Three rule languages, none testable
LDAP ACLs, host rules and role mappers each decide part of the answer, in their own syntax, and none of them runs in CI.
No answer to "why was I refused?"
The systems say yes or no. The reason, which rule decided, is not something they keep.
So Cardinal is both the directory and the portal, with one policy engine across web, SSH, sudo and its own administration. That is the whole bet, and everything below follows from it.
The difference
Four decisions, made differently
Each one is a design choice in the data model, not a feature added on top. Watch what each one changes.
Identity is an immutable UUID
A name is an ordinary attribute. Renaming somebody is one UPDATE, and every group, decision and journal entry still points at the same person.
Access is time-bounded in the data model
Membership carries a validity period rather than a boolean. It stops being true because the data says so, and “was this person in this group in March?” is a query.
One policy engine decides everything
Cedar answers every question with one reviewable, versioned, testable policy set: reach this URL, log in to this host and as whom, run this as root, change the directory.
Every decision carries its reason
The exact rule that produced a decision is logged with it, refusals included. The wording tells a person what to do next.
Honest comparison
Next to what already exists
Where Cardinal is ahead, and where it is not. The established projects are more mature; Cardinal is pre-1.0 and has not been audited. Its advantages are in how access is modelled, not in feature count.
Swipe the table sideways to compare all four.
| Capability | Cardinal | Kanidm | FreeIPA | Keycloak |
|---|---|---|---|---|
| Who it is for | ||||
| Holds the accounts (a directory) | ✓it is the directory | ✓ | ✓ | ◐own store, usually federates a directory |
| Passwordless sign-in | ✓passkeys only, no password column | ✓passkey-first | ✕ | ◐optional |
| Linux host login | ✓short-lived SSH certificates | ✓ | ✓SSSD and Kerberos | ✕ |
| How access is modelled | ||||
| Access that expires on its own | ✓a validity period in the data model | – | ✕ | – |
| One policy for web, SSH, sudo and administration | ✓Cedar, versioned and tested in CI | – | ✕HBAC and sudo rules | ✕web only |
| "Why was I denied?" names the rule | ✓ | – | ✕ | ✕ |
| Tamper-evident audit journal | ✓hash-chained | – | ✕ | – |
| Running it | ||||
| Storage | PostgreSQL, the only datastore | its own storage engine | an LDAP directory server | a relational database |
| LDAP for legacy applications | ✕not built, by design | ✓ | ✓ | ✕ |
| SAML | ✕not built, by design | – | – | ✓ |
| Internal DNS and Kerberos | ✕never in scope | – | ✓ | ✕ |
| Ready for production today | ✕pre-1.0, not yet audited | ✓ | ✓ | ✓ |
✓ yes · ✕ no · ◐ partly, or another way · – not compared here. Based on Cardinal’s own comparison notes; check each project’s documentation before you decide.
You want one policy for web and Linux access, grants that expire because the data says so, and an answer to "why" for every decision. And you can run pre-1.0 software on services you could lose for an afternoon.
You need something to run today. It covers much of the same ground, is further along, and supports LDAP for legacy applications. Evaluate it first.
You need internal DNS, a Kerberos KDC or LDAP for legacy applications. Cardinal will never build DNS or Kerberos.
You need SAML, identity brokering, or something with commercial support behind it. Cardinal deliberately does not implement SAML.