Open nicolas-semaphor opened 2 months ago
This is a requirement for our Open Source foundation to adopt Authentik as our IDP middleware for our modern application portfolio.
What can i do to help move this along?
@BeryJu: To move things along, I will fork the code into a repo under our foundations sandbox org. then @nicolas-semaphor can add the changes we have made and maybe make it easier to understand and test the proposed changes, eventually leading up to a PR.
Heres the fork: https://github.com/OS2sandbox/sandbox-myndighedsidentitet-authentik
Next time @nicolas-semaphor has a timeslot for the project, the code can be merged into the fork..
First bit of code is comitted to this branch: https://github.com/OS2sandbox/sandbox-myndighedsidentitet-authentik/tree/9172-backend-support-for-encrypted-assertions.
Comments and suggestions are welcome. Its a bit hard to get answers from the maintainers at the moment, but in this was we can openly collaborate on a PR in a seperate fork, before submitting it..
This will contain the backend code, for it to be configurable in the UI, more work should be done outside of this issue.
I have submitted a PR: https://github.com/goauthentik/authentik/pull/10099
Is your feature request related to a problem? Please describe. Some SAML IdP's will deny your SAMLRequest if you do not require the Assertion to be encrypted in the SAMLResponse. I would like to add support for requiring and supporting the EncryptedAssertion element when setting up SAML Federation sources.
Describe the solution you'd like A "simple" solution would be adding the option to use the signing key-pair for encryption and decryption when creating a SAML source. When enabled the metadata should be updated with an encryption Key Descriptor:
When the SAMLResponse is received it should then contain an "EncryptedAssertion" element in the EncryptedData section. This needs to be decrypted, one could go about it this way:
After the EncryptedAssertion element has been decrypted and replaced by the decrypted Assertion element, the flow should be able to continue as normal. I've tested the above to work but it is a "raw" implementation.
Describe alternatives you've considered An alternate solution could be to make use of Authentiks API and maybe use something like OneLogins Ruby-SAML library (which has support for Encrypted Assertions) to federate and create users, but off course I would like to stick with the Python implementation. Maybe what I describe above is related to Outposts, but I'm not entirely certain.