SAML 2.0 authentication via authentication server

[Manuthor]

Summary (G-18 · SAML 2.0 Authentication)

Large enterprises federate employee identities via SAML 2.0 (Okta, Ping Identity, ADFS, Shibboleth). This issue adds SAML as an authentication backend to the authentication server. Because the KMS already delegates authentication to the authentication server via the session cookie middleware (#879), no KMS-side changes are required.

Impact

• Enterprises with SAML-only identity federations can authenticate to the KMS without an OIDC bridge
• Common in financial services, healthcare, and government where SAML IdPs are the organizational standard
• OIDC bridge solutions introduce latency, single points of failure, and additional credentials to manage

Architecture

SAML Client (browser / ckms)
  │ GET /saml/login?realm=kms  → SP-initiated SSO redirect to IdP
  ▼
SAML IdP (Okta / ADFS / Shibboleth)
  │ POST /saml/acs?realm=kms  (signed SAML assertion)
  ▼
Authentication server
  │ validates XML signature, extracts NameID + attributes, upserts session
  ▼
Authentication server issues _ea_ session cookie

KMS receives request + cookie → AuthServerAuth middleware (#879) validates session → username injected

Implementation plan (in the authentication server)

1. New SamlAuth strategy in the authentication server:
   • GET /saml/login?realm={realm} — SP-initiated SSO redirect to IdP.
   • POST /saml/acs?realm={realm} — validates XML signature using xmlsec/samael, extracts NameID and attribute statements, upserts a session.
2. New per-realm SAML config (IdP metadata URL, SP entity ID, ACS URL, IdP signing certificate).
3. SP metadata endpoint GET /saml/metadata?realm={realm} for IdP registration.
4. Map SAML attribute statements to authentication server realm roles; realm roles propagate to KMS RBAC roles (requires Full RBAC + Namespace / Multi-Tenant Isolation #651).

Effort: Medium (3-4 weeks, in authentication server) | Requires #879 (authentication server session middleware in KMS)