dadrus
Support for message signatures (RFC 9421)
Preflight checklist
- [X] I agree to follow this project's Code of Conduct.
- [X] I have read and am following this repository's Contribution Guidelines."
- [X] I have discussed this feature request with the community.
Describe the background of your feature request
https://datatracker.ietf.org/doc/html/rfc9421#name-introduction
TL;DR
Add the ability for heimdall to sign the message for payloads. This signature provides a layer of protection ensuring that the message originated from a known source and has not been modified.
Describe your idea
Add configuration options for both symmetric and asymmetric message signing. A pre-shared HMAC key could be used for symmetric signatures and would require the least scaffolding for both parties but provides a larger attack surface as the key has a greater chance of being leaked. For an asymmetric example, a jwks.json could serve as the public key for some PKI infra that provides a private key to heimdall for signing the message. The message's signature could be verified by the recipient via standard /.well-known/jwks.json key id.
The RFC mentioned has most of the relevant details for implementation.
Are there any workarounds or alternatives?
No
Version
v0.14.2-alpha
Additional Context
No response
Just to ensure my assumptions are correct as we didn't talk about the actual usage options.
I see the following ones:
- Using a finalizer, which would sign parts of the request according to the RFC 9421, and depending on the operation mode either (in proxy mode) forward the corresponding headers to the upstream, or (in decision mode) reply with the corresponding headers, which the proxy heimdall is integrated with would forward to the upstream.
- Using an authenticator, which would verify the signature over the request parts and derive a subject out of it.
- Additional auth option heimdall could make use of while communicating to other systems, like idps, authorization systems, or endpoints, latter to gather information about the subject before the request is forwarded to the actual upstream.
I assume, the request is about option 1 as the FR talks about creating signatures.
Do you already have an idea about how the configuration of such mechanism (if my assumption from above is correct) could look like?
Just to ensure my assumptions are correct as we didn't talk about the actual usage options.
I see the following ones:
- Using a finalizer, which would sign parts of the request according to the RFC 9421, and depending on the operation mode either (in proxy mode) forward the corresponding headers to the upstream, or (in decision mode) reply with the corresponding headers, which the proxy heimdall is integrated with would forward to the upstream.
- Using an authenticator, which would verify the signature over the request parts and derive a subject out of it.
- Additional auth option heimdall could make use of while communicating to other systems, like idps, authorization systems, or endpoints, latter to gather information about the subject.
I assume, the request is about option 1 as the FR talks about creating signatures.
Do you already have an idea about how the configuration of such mechanism (if my assumption from above is correct) could look like?
My particular use case is more likely to be 3. than 1. or 2. This is because in addition to hydrating data about the subject, the other systems mentioned can also perform actions in their own datasources regarding the subject that would arguably need to be secured. In my exact case, those systems are legacy and cannot reasonably be updated to support the latest basic security standards so a signed payload is a simple way to ensure that the request originated form a trusted source.
Ok. Thank you for clarification. In that case we're talking about the so called authentication strategy which can be applied to an endpoint (https://dadrus.github.io/heimdall/v0.14.2-alpha/docs/configuration/types/#_authentication_strategy). Should we rename the FR to make it obvious?