Discussion about expandeded SAML protocol support prior to PR

[janhalen]

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?

[BeryJu]

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

[janhalen]

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?

[BeryJu]

I'm assuming python3-saml uses xmlsec under the hood too? I think I mentioned this somewhere else but the main reason for not using python3-saml from the beginning was that at the time it was on one side very much focused for a single SAML provider/source and used a lot of file paths for certificates instead of having the ability to load them from string/db. Also I'm very much not a fan of their code style since they try to keep all their SDK APIs very close to the PHP SDK, which doesn't fit well with python.

[janhalen]

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.

[nicolas-semaphor]

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)

[nicolas-semaphor]

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,
Nicolas

[BeryJu]

I'd like to have a look at a rough authentik implementation using python3-saml to better decide on this. If anything, when going with python3-saml it would make sense to use that for both the existing source and provider. Implementing it as an outpost was an idea that I had a long time ago (as in having an outpost for every protocol), however there'd have to be an easier method for running that within the main authentik deployment (and also there's a bunch of overhead with policies and property mappings via the API, etc)

[nicolas-semaphor]

Thanks for getting back so quickly! As a quick first-look there's a django-example in the python3-saml repository, although you've most likely seen this already: https://github.com/SAML-Toolkits/python3-saml/tree/master/demo-django

The process of preparing, sending and handling the response would need to be cut and rewritten to the response and request processors and the metadata generator would be moved to metadata.py I think the most interesting issue to resolve is the init_saml_auth function that utilizes a path to a folder on the server and if this could be done more in line with AK's current, and imo. better, system of storing config and certs in the Database.

I've not spent much time looking at the SAML provider yet, as I've mainly utilized AK's SAML Federation Source and the OIDC provider. But I would need to have a look at that as well. I will get back to you with more specifics.

Cheers,
Nicolas

[nicolas-semaphor]

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,
Nicolas

[nicolas-semaphor]

It seems Python3-saml only adds Service Provider support, which means it won't do for the SAML provider, at least not easily.. This could be an issue...

There's another python saml library, that supports both SP and IdP functionality..
https://github.com/IdentityPython/pysaml2/tree/master

Seems the repo is more active than python3-saml, but might not be as elegant.