IdP device-trust integration groundwork — authentik as first target, vendor-neutral core

[PaulDotterer]

Context

authentik has shipped an Endpoint Devices area (agent with Linux local login + SSH auth, device compliance, IdP-side connectors incl. Fleet, and since 2026.5 agentless device verification via device certificates + mTLS stage). We want a first-class integration while it is early — but the core stays vendor-neutral: plenty of orgs run other IdPs, and shipping our own NSS/PAM modules for a one-stop shop remains a possible future direction. Integration therefore lives at the edges (definitions, docs, adapters, generic APIs), never as authentik-specific fields in core proto/schema.

Work items

Ship now (no new action types needed)

• Marketplace definition "Deploy authentik Agent": REPOSITORY (their apt/dnf repo + key) → PACKAGE (authentik-cli, authentik-agent, authentik-sysd, libnss-authentik, libpam-authentik) → FILE (nsswitch.conf + pam.d config on non-Debian families — their docs leave this manual; our idempotent FILE actions across the distro matrix are the value-add) → SERVICE. Optional catrust step for private-CA authentik installs. Test across the distro matrix.
• Docs page "Integrating with authentik": OIDC login to PM (works today, verify + document), SCIM provisioning from authentik → our SCIM server (verify their SCIM provider against our endpoint incl. trust_email_assertions semantics), agent deployment via the definition, licensing note (local device login = authentik Enterprise; SSH auth = OSS).
• Coexistence guidance (docs + possibly a UI warning): two user sources on one box (libnss-authentik vs PM user provisioning) — recommended split: IdP owns interactive human login, PM owns LPS/break-glass, service accounts, machine policy. Sudo collision: authentik agent sudo authorization vs ADMIN_POLICY — document; consider inventory-driven detection (agent reports libpam-authentik presence → surface a conflict hint when ADMIN_POLICY targets the same device).

Vendor-neutral groundwork (the strategic part)

• Device posture export API: read-only, token-scoped surface exposing compliance status (COMPLIANT / IN_GRACE_PERIOD / NON_COMPLIANT) + selected inventory facts per device, consumable by ANY IdP/connector — authentik's Fleet connector is the shape to match, but the API itself carries no authentik assumptions. This is also exactly the primitive our own future NSS/PAM modules would consume.
• Evaluate purpose-bound, browser-presentable device certificates (separate CA domain per WS4 conventions — NOT the agent's gateway mTLS identity) for agentless conditional access via IdP mTLS stages. Works with authentik 2026.5's cert-based verification; equally usable by any mTLS-capable IdP.

Upstream

• Study the Fleet connector implementation in goauthentik/authentik (connectors have no public SDK yet; Fleet is early preview) and open the conversation about a Power Manage connector (device facts + compliance signals, later cert-based verification).

Non-goals

• No authentik-specific fields in core proto/schema.
• No bundling of the authentik agent into the PM agent.
• Own NSS/PAM modules are a separate future decision — this issue only ensures the primitives (posture export, purpose-bound certs) don't preclude it.

References

• https://docs.goauthentik.io/endpoint-devices/
• https://docs.goauthentik.io/endpoint-devices/authentik-agent/agent-deployment/linux/
• https://docs.goauthentik.io/releases/2026.5/ (agentless cert-based device verification)