-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for message signatures (RFC 9421) #1493
Comments
Just to ensure my assumptions are correct as we didn't talk about the actual usage options. I see the following ones:
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? |
Preflight checklist
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
The text was updated successfully, but these errors were encountered: