What it offers
Three jobs, one directory
Cardinal does three things, and the point is that they are not three products. They read the same people and groups, and one policy set decides all of them, so “who can reach what, and why?” has one answer.
Web access
Sign people in, and decide what they reach
A passkey gets a person in; policy decides which applications they may open, whether the application has its own login or none at all.
Passkeys, and nothing else
Nobody signs in with a password. An account gains its first credential through an invitation, and recovers with codes or two administrators.
Docs →forwardAuthApplications with no login
Behind a reverse proxy that asks Cardinal before every request. The application needs no code, and someone refused is shown why, on a page only they can read.
Docs →openid connectApplications with their own login
Through Cardinal’s OpenID Connect provider. What an application is told about groups can be narrowed to the ones that concern it.
Docs →access tokensScripts and pipelines
Scoped access tokens that never exceed their owner’s own access.
Docs →security eventsAccess that ends, everywhere
A revoked session or a disabled account is pushed to the applications that asked to hear about it.
Docs →sessionsSessions with an expiry
A validity period on every session, and policy that can demand a fresher sign-in for what matters.
Docs →Linux machines
Who logs in where, as whom, with what rights
Decided when a short-lived certificate is issued, so a machine never asks a directory at login and a login never waits on one.
A machine is a directory entity
With its own key. It joins groups and is named in policy, like a person.
Docs →ssh certificateCertificates that last minutes
Issued when policy allows the login, so nothing durable is left on the host to steal or revoke.
Docs →sudosudo from the same policy
Rendered from the one policy set and validated with visudo before it is installed.
Docs →agentA small agent per host
Serves that host’s users and groups through systemd’s userdb. It holds the host key and nothing that can administer Cardinal.
Docs →acmeInternal TLS over ACME
Certificates for names the directory says the machine holds, with no challenge to answer.
Docs →shadow modeAdopt a fleet that has accounts
Shadow mode reports what a machine believes against what Cardinal would serve, and enforces nothing until you say so.
Docs →The directory, governed
The people both read, and the record of what happened
One directory for web and machines alike, one policy set that governs it, and a journal of every decision and change that you can check has not been rewritten.
People and groups
An immutable identifier, nested groups, and memberships that end on a date.
Docs →scimAccounts from upstream
Provisioned over SCIM 2.0, which cannot make anybody a Cardinal administrator.
Docs →policyOne policy set
Versioned, published and rolled back like code, written in Cedar or composed with the rule builder.
Docs →decisionsEvery decision, with its rule
Logged with the exact rule that produced it, refusals included.
Docs →auditA journal you can verify
Every change hash-chained in the same transaction, with a fingerprint kept off the host and alerts to administrators.
Docs →erasureErasure that keeps history
Removes the person and their credentials, and leaves the audit chain intact.
Docs →How it fits together
Five pieces, one of them yours
A small, boring deployment: one binary, one database, your own proxy, and an agent on each managed host.
cardinal-serverOne containerThe API, the console, the OpenID Connect provider, the forwardAuth endpoint, the ACME directory and the event transmitter.
PostgreSQL 18+Beside itThe only datastore. No cache, no broker, nothing else to back up.
your proxyIn frontTerminates TLS, routes to applications, and asks Cardinal before serving a protected one.
cardinalAn admin machineThe command line. It signs in like a person; the few break-glass commands open the database instead.
cardinal-agentEach Linux hostUsers, groups and sudo for that host, fetched with the host’s own key.