This is a fork of keycloak-gatekeeper, maintained by Oneconcern Inc.
We try our best to contribute back fixes, enhancements and new features to the main repo.
Keycloak Gatekeeper is a transparent authentication proxy that integrates with the Keycloak authentication service.
Gatekeeper may run as a reverse proxy or as a forwarding proxy.
Our primary use case is reverse proxy: this means that you may setup a defense-in-depth and protect API resources behind this proxy, with users authenticated against Keycloak.
Our primary target is browser apps (e.g. react) directly using this proxy to access API resources.
Disclaimer: although we try not to regress on what we see as non-goals, we don't provide any further testing than the one already in place on forward proxying, backend session-stores and login UI with templates.
Authentication is stateful: gatekeeper creates a session for authenticated users. This session may be either stored in some backend or in (encrypted) cookies.
The service supports both access tokens in browser cookie or bearer tokens.
This means that traditional clients using a bear token in Authorization
header may pass through the proxy, as well as modern browser-based clients
which acquire a token through the proxy authentication service, then use a cookie to authenticate.
Protected resources may be unauthenticated, authenticated with custom headers deduced from the token claims or carry out full authentication again from
the Authorization
header (defense in depth).
NOTE: gatekeeper expects to be listed in the audience claim of ID tokens brought back by keycloak. So you should ensure your gatekeeper client in keycloak is configured with a proper "audience" token mapper.
Protected resources (URIs) may be guarded with some basic RBAC rules checking groups and roles provided by keycloak.
NOTE: group rules support trailing wildcards, so you may configure group claims to be the full group hierarchical path. This requires your token mapper in keycloak to map groups in claim with path rather than group name.
/oauth/authorize
endpoint)/oauth/refresh
endpoint)/oauth/logout
endpoint)/oauth/token
endpoint)/oauth/expired
endpoint)The reverse proxy may be deployed either as a gateway or as a sidecar.
When used as gateway, you may route to different upstreams, with some basic path prefix stripping rules.
When relying on cookies, and when used as sidecar or when set with multiple instances on different upstreams, you must ensure that cookies domain and cookies encryption key are shared by all instances.
Multiple gatekeepers may be set up: if you are using cookies to authenticate, you must:
All the below endpoints may be optionally exposed on a separate port, or restricted to localhost requests.
Gatekeeper exposes prometheus metrics and health status endpoint. Metrics are enabled by default.
enable-metrics: true
/oauth/metrics
/oauth/health
There is an opt-in live profiler endpoint for debugging performance issues:
enable-profiling: true
/debug/pprof/{name}
This serves commands from the pprof handler described here.
Tracing may be enabled with the --enable-tracing
flag.
Opencensus tracing may be enabled with the enable-tracing: true
parameter. When enabled a trace collecting agent must be configured (e.g. Jaeger agent).
The datadog agent is supported (--tracing-exporter datadog
). By default, the exporter is for Jaeger.
The admin listener (or main listener if a specific admin listener is not enabled) exposes zpages (rpcz, tracez):
/oauth/trace/rpcz
/oauth/trace/tracez
There is still quite some room for improvement:
If you've found a security vulnerability, please report back to us
This fork:
Resources associated to the original repo: