Trong Huu Nguyen 34d90d2c78 fix(autologin): do not return ambiguous 3xx redirect
If autologin is enabled, check for headers that indicate that the request is a navigation request
and respond appropriately.

A navigation request is assumed to match all of the following:

- uses the GET HTTP method
- either:
  - a) sends the fetch metadata headers, specifically
    `Sec-Fetch-Mode=navigate` and `Sec-Fetch-Dest=document`, or (if
    unsupported by the browser)
  - b) sends the `Accept` header with a value that contains
    `text/html` (which most browsers do by default for navigation
    requests, the exception being IE8 AFAIK)

Non-navigation requests (e.g. fetch / xhr / ajax requests) will receive a
401 Unauthorized, with the Location header set to the login endpoint.
The redirect parameter is also set to point back to the URL found in the
Referer header (though with the scheme and host removed to only allow
redirects relative to the origin host.)

With this fix, autologin will also intercept requests other than GET.
This is to improve the security posture of upstreams that assume that autologin
enforces authentication for all methods.

Fixes #156.
2023-09-22 14:51:35 +02:00
2021-10-01 10:28:44 +02:00
2022-02-03 11:41:43 +01:00
2023-08-10 13:41:44 +02:00
2023-08-10 13:41:44 +02:00
2021-08-17 13:57:06 +02:00

wonderwall

anyway here's wonderwall

Wonderwall is an application that implements an OpenID Connect (OIDC) relying party/client in a way that makes it easy to plug into Kubernetes applications as a sidecar.

As such, this is OIDC as a sidecar, or OaaS, or to explain the joke:

Oasis - Wonderwall

Wonderwall functions as a reverse proxy that should be placed in front of your application; intercepting and proxying requests. It provides endpoints to perform logins and logouts for end users, along with session management - so that your application does not have to.

Features

Wonderwall aims to be compliant with OAuth 2.1, and supports the following:

  • OpenID Connect Authorization Code Flow with mandatory use of PKCE, state and nonce
  • Client authentication using client assertions (private_key_jwt) as per RFC 7523, Section 2.2
  • OpenID Connect RP-Initiated Logout
  • OpenID Connect Front-Channel Logout
  • Encrypted sessions with XChaCha20-Poly1305, stored using Redis as the backend
  • Two deployment modes:
    • Standalone mode (default) for zero-trust based setups where each application has its own perimeter and client
    • Single sign-on (SSO) mode for shared authentication across multiple applications on a common domain

Documentation

At a glance, end-user authentication using Wonderwall is fairly straightforward:

  • If the user does not have a valid local session with the sidecar, requests will be proxied to the upstream host as-is without modifications.
  • In order to obtain a local session, the user must be redirected to the /oauth2/login endpoint, which will initiate the OpenID Connect Authorization Code Flow.
    • If the user successfully completed the login flow, the sidecar creates and stores a session. A corresponding session cookie is created and set before finally redirecting user agent to the application.
    • All requests that are forwarded to the upstream host will now contain an Authorization header with the user's access_token as a Bearer token, as long as the session is not expired or inactive.
  • In order to log out, the user must be redirected to the /oauth2/logout endpoint.

Detailed documentation can be found in the documentation directory:

Running Locally

Binary

Requires Go 1.21

make wonderwall and ./bin/wonderwall

Docker Compose

See the docker-compose file for an example setup:

  • You need to be able to reach host.docker.internal to reach the identity provider mock, so make sure you have 127.0.0.1 host.docker.internal in your /etc/hosts file.
  • By default, the setup will use the latest available pre-built image.

Run docker-compose up. This starts:

Try it out:

  1. Visit http://localhost:3000
    1. The response should be returned as-is from the upstream.
    2. The authorization header should not be set.
  2. Visit http://localhost:3000/oauth2/login
    1. The authorization header should now be set in the upstream response.
    2. The response should also include the decoded JWT from said header.
  3. Visit http://localhost:3000/oauth2/logout
    1. The authorization header should no longer be set in the upstream response.

Verifying the Wonderwall image and its contents

The image is signed "keylessly" using Sigstore cosign. To verify its authenticity run

cosign verify europe-north1-docker.pkg.dev/nais-io/nais/images/wonderwall@sha25:<shasum> \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
--certificate-identity "https://github.com/nais/wonderwall/.github/workflows/deploy.yml@refs/heads/master"

The images are also attested with SBOMs in the CycloneDX format. You can verify these by running

cosign verify-attestation --type cyclonedx \
--certificate-identity "https://github.com/nais/wonderwall/.github/workflows/deploy.yml@refs/heads/master" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
europe-north1-docker.pkg.dev/nais-io/nais/images/wonderwall@sha25:<shasum>
Description
openid connect relying party as a sidecar/service
Readme MIT 3.9 MiB
Languages
Go 97.7%
Smarty 1.5%
Nix 0.4%
CSS 0.3%
Dockerfile 0.1%