Following suggestions from the forum we've decided to use collective.saml2 for SAML authentication with Plone. Unfortunately, it looks like it was compiled five years ago for Plone 4, as the buildout on the master branch extends Plone 4.1. Building with Plone 5.1's stops with the following error:
Error: The requirement ('zope.formlib>=4.4') is not allowed by your [versions] constraint (4.0.6)
Has anyone seen this before? I can update zope.formlib, but then I quickly end up in dependency hell with all the conflicts.
If I update zope.formlib then it wants zExceptions to be updated. If I do that it wants another package, and another, and so on. So "ended up" is probably the best term.
The buildout for this module extends the 4.1 test build, but even after changing that to the plone-5.1.x.cfg test build it still does the same thing.
Do you know of an alternative that would handle multiple identity providers?
https://github.com/collective/collective.saml2/blob/master/setup.py doesn't have a constraint on formlib. It looks like the buildout does but the buildout is just there for testing. This package does very little so it could well work with plone5. It may no longer be the recommended way to install the required dependencies.
I'm not sure the main package https://pypi.org/project/dm.zope.saml2/ has been tested on plone 5 but it has no plone dependencies only zope so there is a greater chance of it working. It does seem to have specific formlib dependencies however.
Note that the dm.zope.saml2 package is not on github or the collective. PRs are not accepted. and if @dieter is not interested in supporting later versions of zope then it might not happen.
Several forks exist however. Some have extra features like support for office 360. Im not sure which is the latest one but there is one in the collective https://github.com/collective/dm.zope.saml2
Porting dm.zope.saml2 for Zope 4/Python 3, I recognized that is has severe problems with Plone's recent CSRF protection: at various places, it uses the ZODB internally for caching and therefore harmless requests (without valid "authentication token") could write to the ZODB, triggering the CSRF protection.
Those problems are fixed in the latest version of dm.zope.saml2. However, this version is tested only against Plone 5.2 and depends on new versions of five.formlib, zope.schema. Potentially, it cannot be used with Plone 5.1 (at least different version pins will be necessary).
The earlier version should work for Plone 5.1 -- apart from CSRF protection problems. Those problems could be tackled outside of dm.zope.saml2, e.g. by disabling CSRF protection globally or by registering the affected views as CSRF safe.
I think I understand... It seems as if collective.saml2 pulls in the latest version of dm.zope.saml2, and you're right, that has some challenges with Plone 5.1. I was able to get it to build with a bunch of version pins and other weird tricks, but running it ran into more challenges.
Just to confirm, would that be dm.zope.saml2 4.0.3?
My customers would LOVE support for Office 360.... I looked through the forks working backward from the collective and didn't see much in the way of documentation, however, and a cursory Google search didn't find it... do you know where I can find the fork supporting Office 360, or do I need to hunt through commit messages?
BTW, @djay, I stole your trick of using tables and Diazo rules to add Material Design CSS styles to user-generated content. The customers like it and are using it all over the place.
At the end of the "pypi" page, you see a section "History". It describes the major releases. For 4.0, you read Plone 5 compatibility; for 5.0, Python 3/Zope 4/ Plone 5.2 compatibility. Third level (micro) releases are typically not described: they contain minor fixes for the previous minor release.
At the end was a PR to collective.saml2 which I never merged. I've now merged it but don't really have a way to test it at the moment.... so if it breaks things let me know.
