Forward-auth (proxy-gated, no native SSO)

Some tools cannot speak OIDC or SAML at all, yet must not be left open behind a separate login. Forward-auth covers them: the tool is placed behind the ResorsIT reverse proxy, and the proxy – not the tool – authenticates the user against the platform IdP before any request reaches the application.

This means a tool with no SSO support whatsoever can still be gated by platform identity. The user signs in once at the IdP, and the proxy carries that proven identity forward.

How ResorsIT integrates it

• The tool runs behind the platform reverse proxy on the platform network
• The proxy checks the session with the IdP before proxying the request
• Once authenticated, the proxy passes the user’s identity to the tool as a trusted request header (the tool trusts the proxy for who the user is)
• Access to the route is an authorization decision, enforced by the platform policy engine (Cedar), so entitlement is checked as well as identity
• The tool never sees a password and runs no federation of its own

When a tool uses this

Forward-auth fits self-hosted tools that expose a web UI but implement no standard SSO: admin consoles, dashboards, and appliance-style apps whose only built-in option is a local login or basic auth. Rather than surfacing such a tool as an unauthenticated link, the platform fronts it and supplies the identity gate the tool lacks.

If the tool does speak OIDC or SAML, prefer single sign-on – forward-auth is the fallback for tools that cannot. If the tool cannot be placed behind the proxy at all, it falls back to a plain link or, where the platform holds the login, a vaulted credential.