Authentication (IAP / OIDC / SAML)

Authentication answers who is making this request. Authorization (what they may do) is handled separately by RBAC.

Authentication answers who is making this request. Authorization (what they may do) is handled separately by RBAC. This page covers how the product establishes the caller's identity.

The identity-aware-proxy model

The product does not implement its own login screen for operators. Instead, operator access flows through an identity-aware proxy (IAP) sitting in front of the admin services on your internal load balancer. The proxy authenticates the user against your identity provider and then forwards the authenticated identity to the admin API as trusted request headers.

On Google Cloud the forwarded headers are:

X-Goog-Authenticated-User-Email — the authenticated user's email
X-Goog-Authenticated-User-Groups — the user's group memberships (comma-separated)

The admin API reads these headers to establish identity, then resolves the role per RBAC. Because the runtime and admin services have internal-only ingress, these headers can only be set by the trusted proxy in front of them — there is no public path that could inject them directly.

Local / non-production fallback. For local development and non-production bring-up, the product also accepts compatibility headers X-User-Email and X-User-Groups. These are for non-production use only and must not be relied on where the IAP is in place.

Supported identity surfaces

At GA:

Google IAP — the primary, fully-exercised path on the GCP-native deployment.
Azure AD — for installations fronted by Azure's identity-aware access.
Standard SAML / OIDC — for organizations standardizing on those federation protocols through an identity-aware proxy that emits the authenticated-user headers.

These cover the mainstream identity setups the product targets for v1.0.

On the roadmap (post-GA):

Additional identity providers including Okta and Keycloak
Custom SAML profiles

These are scoped as later work; v1.0 standardizes on the IAP / Azure AD / SAML / OIDC surface above.

Emergency / break-glass modes

Two deliberate fallbacks exist for situations where the normal identity path is unavailable. Both are for controlled use only:

Bootstrap principal env vars — map specific actor emails directly to roles when group headers are not forwarded. See RBAC.
Auth-disabled emergency mode — a last-resort mode (S2R_ADMIN_AUTH_DISABLED=true) intended only for the narrow window where a trusted TLS/identity front door is broken during bring-up. In this mode all /admin/v1/* calls are treated as admin. Revert immediately once the identity-aware proxy and trusted certificate are active. This mode is not a steady-state configuration.

Relationship to runtime traffic

This page is about operator/admin access to the control plane. The data-plane runtime (the REST↔SOAP conversion path) authenticates differently — to backends, using the encrypted backend credentials configured per service. Inbound runtime callers are governed by your own network's access controls, since the runtime has no public endpoint.

All Specaria SOAP to REST docs

Loading…