Skip to main content

Authentication

Every principal in System9 is crypto-bearing. Authentication is not a password check bolted onto a directory. It is the presentation of cryptographic material that was issued to the principal when it was created, and, for machines and devices, verified on every operational call.

Crypto material every principal holds​

When a principal's directory row is created, an issuance orchestrator provisions identity material in three formats through per-format algorithm managers:

FormatUsed for
X.509Mutual TLS on gRPC, REST, and WebSocket calls
SSHSSH-tunnel transport authentication
OpenPGPSigning and verifying offline bundles

Issuance is data-driven from a crypto-policy table, a new algorithm or purpose is a declaration, not a code change, and idempotent, so material can be re-issued when a certificate authority becomes available during bootstrap.

Mutual TLS as the default​

Machine and device principals authenticate with mutual TLS on every operational call. On the cell, a single identity-binding middleware is the sole authority that stamps the acting principal onto a request; it derives identity from a session, an mTLS/SPKI principal, or upstream-stamped state, first match wins, and it is deny-by-default, a request that arrives with no principal is refused once setup is complete. Two authenticated non-entity principals are recognized: a verified system token (a peer cell acting for nobody) and a verified mTLS service principal.

On a device, the private key is generated on-device and never transits the wire; the device authenticates with a leaf certificate bound to a delegation token, and a hardware fingerprint binds that identity to the physical machine. The full device enrollment flow is in Authorization and delegation.

Human authentication​

For people, the cell supports password with history and reset, TOTP-based multi-factor authentication with single-use recovery codes, WebAuthn, and device authentication with device fingerprinting. Adaptive, risk-based step-up raises the authentication requirement per request based on a risk score, and conditional access can require a stronger authenticator for a stronger action.

Federate with what you already run​

System9 federates with the customer's existing identity provider rather than asking them to maintain a second one. Microsoft Entra ID, Okta, Google Cloud, Ping Identity and AWS IAM Identity Center connect over OIDC; anything else that speaks OIDC or SAML 2.0 connects generically; LDAP binds directly to a domain controller; and CAC/PIV smartcards authenticate either through a federal identity provider or directly against the node.

A federated provider is a governed object, not a configuration file: it has a lifecycle, it cannot be enabled without a passing conformance test over the exact configuration being enabled, it carries its own hash-chained audit, and disabling it drains the sessions it minted.

Two properties are worth carrying away:

  • Federation is additive. Local authentication is the baseline, not a failure mode. A deployment with no providers is complete; a deployment with ten still has a local administrator path that no policy can remove.
  • The login page is the least interesting part. What matters is that a federated person lands as a directory entity, so people, machines, devices and agents share one authorization model. The customer keeps their identity provider and their joiner-mover-leaver process.

See Identity Federation and SSO for the provider registry, claim and group mapping, SCIM provisioning, assurance floors and break-glass, and connect an identity provider for the task runbook with Entra ID worked end to end.

Programmatic authentication​

The sections above cover humans and machines that hold long-lived crypto material or federate from an external directory. A program that calls the public API directly authenticates with one of two sovereign credential families instead, scoped API keys (s9k_live_…) or OAuth 2.1 access tokens (self-signed EdDSA JWTs a node issues and verifies offline). OAuth here runs the node's own authorization server: client-credentials, authorization-code with PKCE, and the device grant, plus token introspection, revocation, and DPoP sender-constrained tokens, no external identity provider on the request path.

See Programmatic authentication for the credentials, grants, and how a resource server verifies each one.