Administration tiers

Administering Cardinal is governed by the same policy set as everything else. The shipped rules split it three ways.

Group	Action	What it covers
user-admins	ManageUsers	create and disable accounts, issue invitations, grant and revoke membership
security-admins	ManageApplications	register relying parties, hostnames, group projection
directory-admins	all three, plus AdministerDirectory	everything, including policy and recovery

The narrower two are empty until somebody is granted them, and an existing administrator keeps exactly what they had. Narrowing is a deliberate act rather than something discovered after an upgrade.

Registering applications is separate from managing people because choosing an application's redirect URIs is enough to build a phishing surface inside the organisation's own identity provider, a different blast radius from adding somebody to a group.

An endpoint added without a tier in mind falls to the broad one, which is the strictest of the three.

The forbids, which no tier escapes

@id("admin-requires-fresh-device-bound-auth")
forbid (principal, action in [AdministerDirectory, ManageUsers,
                              ManageApplications], resource)
unless { context has adminWindowSeconds && principal.deviceBound &&
         principal.authAgeSeconds <= context.adminWindowSeconds };

Cedar's forbid beats any permit, so this holds however broadly somebody is permitted. Two separate requirements, both load-bearing: device-bound excludes a synced passkey, and freshness excludes a working-day session left open on an unlocked laptop.

Two more guard hosts: SSH certificate issuance requires a device-bound credential, and becoming root requires authentication within fifteen minutes.

Where the guarantee stops, stated on purpose

Provisioning is deliberately not in that list. An identity provider synchronising at 3am has neither a device-bound credential nor a recent ceremony and never will, so Provision is excluded from the step-up forbid.

Anybody auditing that rule and concluding "no unattended credential can change the directory" would be wrong, and the shipped policy says so at the rule rather than leaving it to be discovered. What bounds provisioning instead is its own scope and the system-group refusal.

The other place it stops is the CLI, which is not governed by policy at all. Two ways in.