Replies: 8 comments 4 replies
-
Hi, sorry I meant to reply to the issue above. Please feel free to just create a PR and then we can do everything in there |
Beta Was this translation helpful? Give feedback.
-
Wonderfull! Thanks @BeryJu. I have just discussed this with the developer @nicolas--semaphor. There are another functionality missing regarding forced logout. Both the EncryptedAssertion and Forced Logout fucktionality is as far I am aware allready implemented in https://github.com/SAML-Toolkits/python3-saml maintained by OneLogin. But before we start new work and base an upcoming PR on this code instead, we would like to know: What are the maintainers position regarding pulling in this library dependancy to replace the built in SAML code in Authentik? I gather that the biggest advantage for the Authentik project (given that the py3-saml dependency is a good fit) is that the maintenance work would be lowered for the Authentik maintainers.. We are open to discussion of pros/cons.. How do we move this issue along? |
Beta Was this translation helpful? Give feedback.
-
As far as i understand the change then, apart from the changes to the SAML implementation (with or without upstream py3-SAML dependencies) there would need to be made a UI change in the Django UI to include a tick for the ForceLogout setting.. But ill let @nicolas-semaphor clarify this. @BeryJu i fully understand that you are a busy main maintainer, if the discussion should be directed at other maintainers or contributors, please tag them here. |
Beta Was this translation helpful? Give feedback.
-
What I'm mainly looking at implementing at the moment, is adding the option to reuse the SP signing key-pair as an encryption keypair as well. I assume this could be handled by a tick in the UI, something like "Want Assertions Encrypted", which would simply be a booleanfield in the SAMLSource model. Setting this to "True" would then append the public key as an "encryption" key in the metadata, and enable decryption login in the response processor. Of course, it might be better to implement this change such that another key-pair could be chosen, but to begin with, I believe using the same key-pair for signing and encryption is okay. Aside from that, and I reckon this would be more difficult, but adding support for IdP-initiated logout as well, would be great. I'm not entirely sure how I would go about this. The IdP would need to be able to invalidate the session in Authentik somehow, maybe the API could help here? The option to ask for custom attributes would be a great addition as well, down the line. (Also yes, Python3-Saml depends on xmlsec and libxml2) |
Beta Was this translation helpful? Give feedback.
-
We are at somewhat of a crossroads.. We're really in love with Authentik's interface and user management, as well as policy features and provider setup with custom attributes and such. On the one hand I really appreciate the foundation of Authentik's current SAML implementation. It's extremely neatly written and easily understandable and well laid out, but unfortunately it also lacks in some essential SAML features that we are in need of, such as EncryptedAssertion Support, Option for IdP-initiated logout and the option to ask for custom attributes, not to mention support for a more advanced metadata configuration, such as "WantAssertionsSigned" SSPODescriptor attributes and multiple SSO endpoint in case of both Redirect and Post-bindings being available, to mention a few. I would love to assist with implementing these features but at the same time, I'd feel that I'm "re-inventing" the wheel, when Python3-Saml already has many of these (if not all) features covered. Would it be acceptable for us to look at adding the option for choosing Python3-SAML as a second SAML federation source? This would initially be a little more hands on with the configuration for sure, but I hope this would allow organisations with more advanced SAML IdPs to still use Authentik as a great Open Source IAM solution. Maybe this would make more sense as an Outpost? Would love to know your thoughts on this @BeryJu Kind Regards, |
Beta Was this translation helpful? Give feedback.
-
I should have some time to start with the rough implementation soon. We discussed the python3-saml framework's way of handling settings in json files on the application server as an issue. I might have an idea for this, as the settings don't actually need to be located in files on the server. I was thinking of adding a method on the SAMLSource called "compile_settings(self)" "generate_settings(self)" or something like that. This option would dynamically build and a return a python3-saml compliant settings-dictionary based on the SAMLSource model, as created in the Authentik UI. When the SAMLRequest is prepared in the request processor, the settings argument would simply be a call to SAMLSource.compile_settings() instead of a file path. Of course, we would still need to implement more model fields on the SAMLSource along the way, to allow for complex SAML setups, but I feel that additions like these should be simple enough, i.e. add a new model field and update UI to allow configuration of them. Any thoughts on this @BeryJu ? Kind Regards, |
Beta Was this translation helpful? Give feedback.
-
I've made some adjustments on the following branch: https://github.com/OS2sandbox/sandbox-myndighedsidentitet-authentik/tree/9172-backend-support-for-encrypted-assertions I'm in the planning phase of adding the option to specify custom requested attributes (as an example see https://logon.semaphor.dk/saml/metadata/ - look for the AttributeConsumingService element). I'm considering adding a field to the SAMLSource, which will contain a list of dicts, i.e. [ { attr1 }, { attr2 }, ... ]. Where if the length of the list is greater than zero, an AttributeConsumingService element is added to the metadata, and custom attribute subelements are added iteratively. My only concern is how hard it will be to modify the UserConnection to map the User email, name etc. from the attibutes returned by the IdP. Currently, as far as I can tell, only the Subject NameID in the assertion is used when a user is federated. Are you able to confirm this @BeryJu ? Cheers, |
Beta Was this translation helpful? Give feedback.
-
@BeryJu: Thanks for the discussion and guidance... The PR is now ready: #10099 |
Beta Was this translation helpful? Give feedback.
-
Hello!
We have expanded the SAML implementation to include encrypted assertions.
What is the correct procedure to start a conversation about how we have solved and coded the contribution, and eventually resulting in a PR?
We have tried this approach: #9172 but Im in doubt that we have done it the right way, as there is no feedback og answers in the isuue.
What should we do to start the conversation please?
Beta Was this translation helpful? Give feedback.
All reactions