Who can reach what, and why, for web applications and Linux machines. One policy set decides, and every answer names the rule that made it.
v0.7.0 · pre-1.0 · not yet auditedWhat that meansOne directory, three jobs
Web access, machine access and the directory that governs both read the same people and groups, and one policy set decides all of them. So “who can reach what, and why?” has one answer, in one place.
Sign people in to every web application with a passkey, and decide which ones they may open. Applications with their own login use OpenID Connect; the ones without one sit behind your proxy and need no code at all.
Decide who may log in to which host, as whom, and with what sudo rights, from the same policy. The decision is made when a short-lived SSH certificate is issued, so a login never waits on the directory.
People and groups with memberships that end on a date, a policy you version and roll back like code, and a record of every decision and every change that you can check has not been rewritten.
Explainable by design
Most identity systems can say yes or no. Cardinal keeps the reason: which rule allowed it, which rule forbade it, or that nothing granted it at all. Pick a request and watch it decided.
Allowed by policy staff-web-access.
Example requests. The explanations use the wording Cardinal computes on the server (explain in the decision API), so the console, the CLI and the API all say the same thing.
Console and command line
A console for the questions that want a screen, and a CLI for the ones asked while something is broken. Both go through the same API, so neither can drift into being the real one. Every screen and every transcript below came off a running Cardinal.
Every decision is recorded with the rule that produced it, including the refusals where nothing matched, which are the ones hardest to explain and the ones most systems drop.
What it does
The rest of the picture in brief. Each links to the page that goes deep.
An application that has never heard of Cardinal is protected by it: your reverse proxy asks on every request, no integration code.
Read the guide →ssh certificatesWho may log in where, as whom, with what sudo, decided when a short-lived SSH certificate is issued. Logins never wait on the directory.
Host access →cedarCedar decides web access, SSH, sudo and the directory’s own administration. Versioned in git, rolled back like code.
Policy →valid_periodMembership carries a validity period, so “production for two weeks” stops being true because the data says so, not because a job ran.
Time-bounded access →passkeysPasskeys only, hardware-key administration, and a hash-chained journal you can verify. A deployment starts where most end up after an audit.
Security →standardsOpenID Connect, SCIM, WebAuthn, ACME and Shared Signals. PostgreSQL and nothing else, no telemetry, built in the EU.
Standards →Before you rely on it
Everything on this site runs, and an end-to-end suite drives it against a real stack on every change. That does not make it finished, and this page says so as loudly as it says the rest.
Driven against a real stack on every change
Required before 1.0, not done yet
Each release’s notes say what to do
Not yet decided, and no warranty
A pilot on services nobody would miss for an afternoon
Cardinal is developed by Londer and is not distributed yet. The documentation describes everything that runs today, the limits included, so you can judge the design before there is anything to deploy.