dadrus / heimdall Goto Github PK

A cloud native Identity Aware Proxy and Access Control Decision service

Home Page: https://dadrus.github.io/heimdall/

License: Apache License 2.0

Go 99.57% Dockerfile 0.11% Shell 0.08% Just 0.08% Smarty 0.17%

api-gateway authentication authorization golang iap oauth2 openid-connect policy-enforcement access-control access-management

heimdall's Introduction

Heimdall

Background

Heimdall is inspired by the Zero Trust idea and also by Pomerium and Ory's OAthkeeper. Some experience with both and my inability to update the latter one to include the desired functionality and behavior was Heimdall's born hour.

What is heimdall

Heimdall authenticates and authorizes incoming HTTP (HTTP 1.x and HTTP 2.0) requests as well as enriches these with further contextual information and finally transforms resulting subject information into a format, required by the upstream services.

It can do so

standalone as a proxy in front of your service or web server that rejects unauthorized requests and forwards authorized ones to your end points, or
integrated into any other proxy, ingress controller or API gateway, like Kong, NGNIX, Envoy, Traefik, Contour, Ambassador and many more. Here that other proxy will forward the incoming request to heimdall and depending on its response either forward the original request, verified and updated by heimdall to your upstream service, or reject it with the information provided by heimdall.

In both cases is acts as a Policy Enforcement and to some degree a Policy Decision Point according to NIST Zero Trust Architecture (SP 800-207)

How does authentication, authorization and transformation happen

The above said decision and transformation process happens via rules, respectively rule sets, which can be controlled by each and every upstream service individually and loaded by heimdall from different sources, like

the local file system,
any HTTP endpoint,
cloud storages, like AWS S3, Google's GC, etc. and
RuleSet kubernetes resources (a corresponding CRD is shipped with the helm chart)

That way, these rule sets can not only be managed centrally, but be deployed together with each particular upstream service as well without the need to restart or redeploy heimdall. Indeed, these rule sets are optional first class citizens of the upstream service and allow:

implementation of secure defaults. If no rule matches the incoming request, a default decision and transformation, if configured, is applied. This is the reason for "optional first class citizens" above.
configuration of as many authentication (e.g. OpenID Connect), authorization (e.g. via CEL expressions, or via OPA, or OpenFGA), contextualization (by e.g. communicating to some specific endpoint) and finalization mechanisms (e.g. creation of a JWT out of the available subject information), supported by heimdall, as required for the particular system. So, if your system requires integration with multiple authentication providers, or you want to migrate from one to another - it is just a matter of configuring them in heimdall.
reuse and combination of these mechanisms in as many rules, as required for the particular system.
partial reconfiguration of a particular mechanism in a rule if required by the upstream service.
authentication mechanism fallbacks
implementation of different decision process schemes by combining e.g. authentication mechanisms with error handlers to drive authentication mechanism specific error handling strategies.
execution of authorization and contextualization mechanisms in any order; that way, if the information about your subject, available from the authentication system, is not sufficient to make proper authorization decisions, you can let heimdall call other services to retrieve that additional information.
conditional execution of authorization, contextualization and finalization mechanisms is possible, e.g. if depending on the available information about the subject you would like heimdall to either block the request, or let the upstream return different representations of the requested resource.

Beyond the functionality

Heimdall's main focus points beyond its functionality are:

Performance - To achieve this, heimdall does use any http routing frameworks and does not load or convert data during execution whenever possible. This is also true for reflection use.
Clear abstractions - To allow extensibility and even replacement of components without side effects.
Simplicity - To allow better understanding of code to everybody, who would like to contribute.

Where can I find more details

Head over to the documentation for details or if you would like to give it a try.

Current state

The current implementation is a late alpha version. That means it does not solve all the problems heimdall aims to solve. With other words a lot of functionality is missing. In addition, alpha version means, there will be breaking changes. Nevertheless, the code base is very stable and pretty good tested. Functionality already supported can be found in Release descriptions. Planned features can be found in the defined Milestones.

If you ...

... like the project - please give it a ⭐
... miss something, or found a bug, file a ticket. You are also very welcome to contribute 😉
... would like to support, reach out to me via Discord
... need help, head over to Discord as well

heimdall's People

Contributors

Stargazers

Watchers

Forkers

sja ephemerecreative netthier vinerich tk-innoq martin31821 davidspek fnd godrin reabmax ebano step-security-bot

heimdall's Issues

Write integration guide for nginx

Return HTTP "404 NotFound" instead of "500 InternalServerError" when no default rule is configured and no rule matches

Write a guide on how to integrate with open policy agent for authorization purposes

Support x509 certificates (incl chain) in key store for JWT signature creation purposes.

This implies the implementation for #1 should also return certificates in the corresponding JWKS document

Switch from opentracing to opentelemetry for tracing

This will make #16, #174 and #175 obsolete, as well as make the implementation of #142 much easier.

Enhance configuration implementation and add more tests

Refactor configuration properties to reflect their meaning and enhance understanding

Implement readyness & lifeness probes

Compile pipeline related scripts and templates on rule loading

Currently these are compiled during execution.

Write integration guide for envoy proxy

Add support for loading rules from AWS S3 buckets

Implement Access-Logs

The logs, which are currently there are not meant as access logs and do not include all information, which is usually expected from an access log, like

remote IP address
client "user name"
request method
request path
request protocol
origin server HTTP status
origin server content size
request referrer
request user agent
request duration in ms

Document available pipeline handler and provide examples

Write a quick start guide

Add support for loading rules from http endpoints

Make use of hadolint to ensure we build Docker images adhering to best practices

Deal with multiple entries for the same kid in responses from jwks endpoints

The jwks rfc is open for multiple kids in the jwks documents, even it does not recommend it. As of today heimdall raises an error in such situations. Multiple kids could however appear if the jwks document contain a plain key, as well as a certificate containing it as well. In such situations heimdall should be able to deal with multiple entries with same kid. That implies however that heimdall shall support x509 certificates to verify JWT signatures, which is not supported as of now.

Setup documentation templates

Extend template implementation to enable the usage of the heimdall context

As of today only the subject is available. This is very often not enough, especially for authorization purposes, where access to the original request is required.

Implement support for zipkin

Write a guide on how to integrate with Ory Keto for authorization purposes

Write integration guide for traefik

Change the errors raised by authenticators to "unauthenticated" to enhance comprehensibility

As of today the authenticators raise "unauthorized" error if the verification of subject's authentication status fails. The name of the error has been taken from the HTTP Unauthorized used for the same purpose. Nevertheless it is misleading as we're talking about authentication and not authorization. This especially hits in, when configuring error handlers and it becomes unclear, whether the error resulted from an issue in an authenticator or authorizer.

Enable fallback of Authenticators even if the verification of the given credentials fails

As of today fallback of authenticators works only if the pipeline configures authenticators which expect different credentials as input. E.g. if one authenticator expects a cookie and the other one an access token. If however different authenticators expect same credential input. E.g. they are expecting an an access token in the Authorization header, fallback doesn't work.

Such fallback is however required if different Auth Providers are used to protect same resource. E.g. the system is configured to work with something like "Login with Google" and "Login with GitHub".

In principle the configuration can be done in a rule already today with something like this:

execute:
 - authenticator: verify_google_token
 - authenticator: verify_github_token

The problem with the above example is however, that if the login has been done with GitHub, the verify_github_token authenticator will never be executed, as the verify_google_token authenticator will be executed first (according to the sequence above) and fail to verify the token, leading to an authentication error for the entire pipeline.

This can be enabled by introducing a specific configuration property for the authenticators, e.g.: allow_fallback_on_error, which would allow the pipeline to fallback to the next configured authenticator even the previous one failed. So the above pipeline configuration would become

execute:
 - authenticator: verify_google_token
   config:
     allow_fallback_on_error: true
 - authenticator: verify_github_token

Potential Workaround Today: If there is a chance to configure the used Auth Providers to set the credentials into different fields, fallback works. This is always possible for cookies, as these are usually named provider specifically. This might be however problematic for providers issuing Auth2/OIDC tokens. As these are usually put into the Authorization header.

The layout and styling of the current documentation template needs an update

It is not usable on mobile devices
The layout is weird and there is just a simple basic bootstrap style.

Fix code scanning alert - CVE-2022-27191

Tracking issue for:

https://github.com/dadrus/heimdall/security/code-scanning/1

Add information about the failed authenticator to the error context

This way the definition of an error handler can make use of it, e.g. to redirect to different auth providers, if a rule defines multiple different authenticators and one of these fails.

Configuration of `trusted_proxies` is not possible

The schema file used to verify the configuration does not include trusted_proxies property for decision api and proxy configurations. So cannot be used in configuration (leads to a validation error)

If no KID is present in the JWT header, iterate over the received JWKs and try validating the signature until one fits

Some provider do not set the KID in the JWT header (which is discouraged by the RFC). As of today heimdall will not be able to verify JWTs without a KID.

Make usage of `trusted_proxies` mandatory to enable usage of "X-Forwarded-*" and "Farwarded" headers

On one hand, due to #94 the configuration of trusted_proxies is not possible. On the other hand the available decision api does only make use of some of the X-Forwarded-* headers (if present) to build the url to match against configured rules and does not forward or use this information otherwise. With the introduction of the proxy implementation (#4), the acceptance of such headers by default will introduce a security issue. To avoid this and to have the same behavior and configuration for both - decision api and proxy operation modes, the configuration of trusted_proxies should become mandatory.

Links and references to stylesheets and content pages are broken when deployed as GitHub pages

The current page looks weird, as most of the links (inkl css and content are broken)

Imlement JWKS endpoint to let upstream services verify signatures of generated JWTs

Authenticators should fallback by default only if the required authentication data is not present in the request

As of today, if you configure a rule to have multiple authenticators, the pipeline implementation always falls back to the next one if the previous fails. E.g.

...
execute:
  - authenticator: a
  - authenticator: b
  - authenticator: c

So if "a" fails (regardless the reason), "b" is executed etc. This fallback should however by default only happen if the authentication data, like a specific cookie, or header, etc is not present in the request, but not when the actual verification of that data fails.

Write introductory document about heimdall

Enable usage of environment variables in config file to ease usage

Even the entire configuration can be done via environment variables, there is no possibility to make use of environment variables in the config file itself. This would be very helpful especially for configuration of endpoint related security properties, like api keys etc.

A promising implementation is envsubst, which can be used while loading configuration from yaml files

Some examples and definitions in the description of configuration options don't have "heimdall" as top level element

Affected pages are at least

the descriptions of all mutators
the description of remote authorizer

Implement support for Radis as an alternative to the available in-memory cache

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

deps: update chainguard-dev/actions digest to dd6006a

Detected dependencies

dockerfile

docker/Dockerfile

golang 1.22.3-bookworm@sha256:5c56bd47228dd572d8a82971cf1f946cd8bb1862a8ec6dc9f3d387cc94136976

docker/debug.Dockerfile

golang 1.22.3-bookworm@sha256:5c56bd47228dd572d8a82971cf1f946cd8bb1862a8ec6dc9f3d387cc94136976

docker/docs.Dockerfile

uwebarthel/asciidoctor 1.70.0@sha256:8f4f7f21bc972a3fb1841bb210921e4adf42348592cc8b41b5934393051747eb

github-actions

.github/workflows/ci.yaml

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

technote-space/get-diff-action v6.1.2@f27caffdd0fb9b13f4fc191c016bb4e0632844af

technote-space/get-diff-action v6.1.2@f27caffdd0fb9b13f4fc191c016bb4e0632844af

technote-space/get-diff-action v6.1.2@f27caffdd0fb9b13f4fc191c016bb4e0632844af

technote-space/get-diff-action v6.1.2@f27caffdd0fb9b13f4fc191c016bb4e0632844af

technote-space/get-diff-action v6.1.2@f27caffdd0fb9b13f4fc191c016bb4e0632844af

technote-space/get-diff-action v6.1.2@f27caffdd0fb9b13f4fc191c016bb4e0632844af

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

actions/setup-go v5.0.1@cdcb36043654635271a94b9a6d1392de5bb323a7

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

reviewdog/action-golangci-lint v2.6.1@00311c26a97213f93f2fd3a3524d66762e956ae0

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

actions/setup-node v4.0.2@60edb5dd545a775178f52524783378180af0d1f8

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

reviewdog/action-hadolint v1.41.1@13c293e6679cd4c90fa41dd5155fb067a28c0a5f

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

yokawasa/action-setup-kube-tools v0.11.1@5fe385031665158529decddddb51d6224422836e

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

actions/setup-go v5.0.1@cdcb36043654635271a94b9a6d1392de5bb323a7

codecov/codecov-action v4.4.1@125fc84a9a348dbcf27191600683ec096ec9021c

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

googleapis/release-please-action v4.1.1@f3969c04a4ec81d7a9aa4010d84ae6a7602f86a7

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

actions/setup-go v5.0.1@cdcb36043654635271a94b9a6d1392de5bb323a7

actions/upload-artifact v4.3.3@65462800fd760344b1a7b4382951275a0abb4808

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

actions/setup-go v5.0.1@cdcb36043654635271a94b9a6d1392de5bb323a7

sigstore/cosign-installer v3.5.0@59acb6260d9c0ba8f4a2f9d9b48431a222b68e20

CycloneDX/gh-gomod-generate-sbom v2.0.0@efc74245d6802c8cefd925620515442756c70d8f

goreleaser/goreleaser-action v5.1.0@5742e2a039330cbb23ebf35f046f814d4c6ff811

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

sigstore/cosign-installer v3.5.0@59acb6260d9c0ba8f4a2f9d9b48431a222b68e20

actions/setup-go v5.0.1@cdcb36043654635271a94b9a6d1392de5bb323a7

CycloneDX/gh-gomod-generate-sbom v2.0.0@efc74245d6802c8cefd925620515442756c70d8f

docker/setup-qemu-action v3.0.0@68827325e0b33c7199eb31dd4e31fbe9023e06e3

docker/setup-buildx-action v3.3.0@d70bba72b1f3fd22344832f00baa16ece964efeb

docker/metadata-action v5.5.1@8e5442c4ef9f78752691e2d8f8d19755c6f78e81

docker/build-push-action v5.3.0@2cdde995de11925a030ce8070c3d77a52ffcf1c0

docker/login-action v3.1.0@e92390c5fb421da1463c202d546fed0ec5c39f20

docker/login-action v3.1.0@e92390c5fb421da1463c202d546fed0ec5c39f20

docker/build-push-action v5.3.0@2cdde995de11925a030ce8070c3d77a52ffcf1c0

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

sigstore/cosign-installer v3.5.0@59acb6260d9c0ba8f4a2f9d9b48431a222b68e20

actions/setup-go v5.0.1@cdcb36043654635271a94b9a6d1392de5bb323a7

CycloneDX/gh-gomod-generate-sbom v2.0.0@efc74245d6802c8cefd925620515442756c70d8f

docker/setup-qemu-action v3.0.0@68827325e0b33c7199eb31dd4e31fbe9023e06e3

docker/setup-buildx-action v3.3.0@d70bba72b1f3fd22344832f00baa16ece964efeb

docker/login-action v3.1.0@e92390c5fb421da1463c202d546fed0ec5c39f20

docker/login-action v3.1.0@e92390c5fb421da1463c202d546fed0ec5c39f20

docker/metadata-action v5.5.1@8e5442c4ef9f78752691e2d8f8d19755c6f78e81

docker/build-push-action v5.3.0@2cdde995de11925a030ce8070c3d77a52ffcf1c0

peter-evans/dockerhub-description v4.0.0@e98e4d1628a5f3be2be7c231e50981aee98723ae

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

stefanprodan/helm-gh-pages v1.7.0@0ad2bb377311d61ac04ad9eb6f252fb68e207260

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

peaceiris/actions-hugo v3.0.0@75d2e84710de30f6ff7268e08f310b60ef14033f

actions/setup-node v4.0.2@60edb5dd545a775178f52524783378180af0d1f8

ruby/setup-ruby v1.177.1@943103cae7d3f1bb1e4951d5fcc7928b40e4b742

jacobtomlinson/gha-find-replace v3@a51bbcd94d000df9ca0fcb54ec8be69aad8374b0

peaceiris/actions-gh-pages v4.0.0@4f9cc6602d3f66b9c108549d475ec49e8ef4d45e

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

peaceiris/actions-hugo v3.0.0@75d2e84710de30f6ff7268e08f310b60ef14033f

actions/setup-node v4.0.2@60edb5dd545a775178f52524783378180af0d1f8

ruby/setup-ruby v1.177.1@943103cae7d3f1bb1e4951d5fcc7928b40e4b742

jacobtomlinson/gha-find-replace v3@a51bbcd94d000df9ca0fcb54ec8be69aad8374b0

jacobtomlinson/gha-find-replace v3@a51bbcd94d000df9ca0fcb54ec8be69aad8374b0

peaceiris/actions-gh-pages v4.0.0@4f9cc6602d3f66b9c108549d475ec49e8ef4d45e

peaceiris/actions-gh-pages v4.0.0@4f9cc6602d3f66b9c108549d475ec49e8ef4d45e

peaceiris/actions-gh-pages v4.0.0@4f9cc6602d3f66b9c108549d475ec49e8ef4d45e

chainguard-dev/actions ba1a9c9ffe799736883d58f31caff18d85b2800e

peter-evans/create-pull-request v6.0.5@6d6857d36972b65feb161a90e484f2984215f83e

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

ubuntu 22.04

.github/workflows/scorecard.yml

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

ossf/scorecard-action v2.3.3@dc50aa9510b46c811795eb24b2f1ba02a914e534

actions/upload-artifact v4.3.3@65462800fd760344b1a7b4382951275a0abb4808

github/codeql-action v3.25.6@9fdb3e49720b44c48891d036bb502feb25684276

.github/workflows/security.yaml

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

aquasecurity/trivy-action 841fb371db7b5cd339e5b2d55c92f5dbd730ac9f

github/codeql-action v3.25.6@9fdb3e49720b44c48891d036bb502feb25684276

step-security/harden-runner v2.8.0@f086349bfa2bd1361f7909c78558e816508cdc10

actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29

actions/setup-go v5.0.1@cdcb36043654635271a94b9a6d1392de5bb323a7

github/codeql-action v3.25.6@9fdb3e49720b44c48891d036bb502feb25684276

github/codeql-action v3.25.6@9fdb3e49720b44c48891d036bb502feb25684276

ubuntu 22.04

ubuntu 22.04

gomod

go.mod

go 1.22.3

github.com/Masterminds/sprig/v3 v3.2.3

github.com/alicebob/miniredis/v2 v2.32.1

github.com/dlclark/regexp2 v1.11.0

github.com/drone/envsubst/v2 v2.0.0-20210730161058-179042472c46@179042472c46

github.com/elnormous/contenttype v1.0.4

github.com/envoyproxy/go-control-plane v0.12.0

github.com/evanphx/json-patch/v5 v5.9.0

github.com/felixge/httpsnoop v1.0.4

github.com/fsnotify/fsnotify v1.7.0

github.com/go-co-op/gocron/v2 v2.5.0

github.com/go-http-utils/etag v0.0.0-20161124023236-513ea8f21eb1@513ea8f21eb1

github.com/go-jose/go-jose/v4 v4.0.2

github.com/go-logr/zerologr v1.2.3

github.com/go-playground/locales v0.14.1

github.com/go-playground/universal-translator v0.18.1

github.com/go-playground/validator/v10 v10.20.0

github.com/go-viper/mapstructure/v2 v2.0.0-alpha.1

github.com/gobwas/glob v0.2.3

github.com/goccy/go-json v0.10.3

github.com/google/cel-go v0.20.1

github.com/google/uuid v1.6.0

github.com/gorilla/websocket v1.5.1

github.com/grpc-ecosystem/go-grpc-middleware/v2 v2.1.0

github.com/iancoleman/strcase v0.3.0

github.com/inhies/go-bytesize v0.0.0-20220417184213-4913239db9cf@4913239db9cf

github.com/instana/go-otel-exporter v1.0.0

github.com/jellydator/ttlcache/v3 v3.2.0

github.com/johannesboyne/gofakes3 v0.0.0-20240513200200-99de01ee122d@99de01ee122d

github.com/justinas/alice v1.2.0

github.com/knadh/koanf/maps v0.1.1

github.com/knadh/koanf/parsers/yaml v0.1.0

github.com/knadh/koanf/providers/confmap v0.1.0

github.com/knadh/koanf/providers/env v0.1.0

github.com/knadh/koanf/providers/rawbytes v0.1.0

github.com/knadh/koanf/providers/structs v0.1.0

github.com/knadh/koanf/v2 v2.1.1

github.com/ory/ladon v1.3.0

github.com/pkg/errors v0.9.1

github.com/pquerna/cachecontrol v0.2.0

github.com/prometheus/client_golang v1.19.1

github.com/redis/rueidis v1.0.37

github.com/redis/rueidis/rueidisotel v1.0.37

github.com/rs/cors v1.11.0

github.com/rs/zerolog v1.33.0

github.com/santhosh-tekuri/jsonschema/v5 v5.3.1

github.com/spf13/cobra v1.8.0

github.com/stretchr/testify v1.9.0

github.com/tidwall/gjson v1.17.1

github.com/tonglil/opentelemetry-go-datadog-propagator v0.1.2

github.com/undefinedlabs/go-mpatch v1.0.7

github.com/wI2L/jsondiff v0.5.2

github.com/ybbus/httpretry v1.0.2

github.com/yl2chen/cidranger v1.0.2

github.com/youmark/pkcs8 v0.0.0-20240424034433-3c2c7870ae76@3c2c7870ae76

go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.52.0

go.opentelemetry.io/contrib/instrumentation/host v0.52.0

go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.52.0

go.opentelemetry.io/contrib/instrumentation/runtime v0.52.0

go.opentelemetry.io/contrib/propagators/autoprop v0.52.0

go.opentelemetry.io/otel v1.27.0

go.opentelemetry.io/otel/bridge/opentracing v1.27.0

go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.27.0

go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp v1.27.0

go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.27.0

go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.27.0

go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.27.0

go.opentelemetry.io/otel/exporters/prometheus v0.49.0

go.opentelemetry.io/otel/exporters/zipkin v1.27.0

go.opentelemetry.io/otel/metric v1.27.0

go.opentelemetry.io/otel/sdk v1.27.0

go.opentelemetry.io/otel/sdk/metric v1.27.0

go.opentelemetry.io/otel/trace v1.27.0

go.uber.org/fx v1.21.1

golang.org/x/exp v0.0.0-20240506185415-9bf2ced13842@9bf2ced13842

google.golang.org/genproto/googleapis/rpc v0.0.0-20240521202816-d264139d666e@d264139d666e

google.golang.org/grpc v1.64.0

google.golang.org/protobuf v1.34.1

gopkg.in/yaml.v3 v3.0.1

k8s.io/api v0.30.1

k8s.io/apimachinery v0.30.1

k8s.io/client-go v0.30.1

k8s.io/klog/v2 v2.120.1

helm-values

charts/heimdall/values.yaml

npm

docs/package.json

@mermaid-js/mermaid-cli ^10.0.0

bootstrap ^5.3.0

bootstrap-icons ^1.8.3

hugo-flexsearch 1.0.2

Check this box to trigger a request for Renovate to run again on this repository

Support x509 certificates in JWKS responses and use them to verify JWT signatures in addition to plain keys

As of today heimdall can only use RSA or ECDSA keys to verify JWT signatures. If a certificate or the corresponding chain is present in the jwk, it is ignored.

This feature should introduce the verification of the chain if it is present according to RFC 5280, section 6.1 and also ensure, the corresponding private key is allowed to be used for signature creation purposes.
Beyond that the behavior should be configurable, like were to get the root certificate from, etc.

Revocation check is out of scope for this enhancement.

This issue relates to #5

Change the error raised by authorizers from forbidden to "unauthorized" to enhance comprehensibility

As of today the authorizers raise "forbidden" error if the verification of subject's authorization status fails. The name of the error has been taken from the HTTP Forbidden used for the same purpose. Nevertheless it is not really lean.

This related to #51

Access token is extracted from cookie by default as well if it is not present in header or query parameter

This is actually prohibited by the oauth2 threat model.

Extend remote authorizer to verify the payload of the response from the authorization system in place

As of today, the remote authorizer doesn't allow verification of the response payload received from the authorization system. There is a way to achieve this - by using a local authorizer in the next step. Nevertheless it should be simplified as many authorization systems does not always respond with on/not ok via HTTP status codes, but also provide the corresponding information in a response body by setting the HTTP response code to 200 (which is perceived as "authorized" by Heimdall).

So to simplify rules, the remote authorizer should receive a new property, named e.g. verify_response_script, which can then be configured with an ECMAScript to let the authorizer itself verify the response. If the response contains any properties, required e.g. by the mutator (to forward to the upstream), the script should also be able to respond with a JSON.