Sorry if ranting, in the past week I spent some time attempting to implement SSO on Plone6 and I'm a tad exhausted from the experience...
My scenario is as follows:
intranet on Plone6 classic
users who are signed in to their (Windows / Mac / Linux) workstations with their organizational M$ Active Directory credentials
My goal is to have these users log on automatically to the Plone instance, given that they are already logged in to their workstation. i.e. very much along the lines of Matt Hamilton's presentation:
I was able to get quite far (in retrospect very quickly) using pas.plugins.ldap - where the plugin lets me select specific AD groups and give these users specific Plone roles. These users can now log in to Plone using their AD credentials. Nice!
Next, I looked at collective.saml2 using AD Federated Services. This implementation actually requires three servers: a domain controller with the AD FS role, a windows web application proxy on a different server, and finally Plone as the service provider. After a lot of stumbling on my part, I was finally able to let Plone redirect the user to the IdP where they are prompted with a login prompt... (After which the process fails because the M$ SAML2 consumer requires my Plone server to be reachable over https). Summary: too many complicated prerequisites, new introduction of points of failure, future maintenance hassles (certificate renewals, etc). Despite the wonderful work on dm.zope.saml2 and collective.saml2 to make the concept even work, this is where I give up.
Earlier on, I saw an Event error AD FS 273 on my DC that mentioned the requirement to set up a specific assertion consumer service. This event was followed immediately with AD FS 364.
I'll go through my steps once more from the very beginning, as I suspect the missing cookies are the result of a browser extension.
But, I now doubt that collective.saml2 is the correct plugin to achieve my goal: even if successfully deployed, would my users still have to log in on the AD server when they are already logged in to their workstations?
https might be required but that doesn't mean both sites need to be on the public internet and have a direct connection between them. The exchange of credentials is done via the browser redirecting back and forth between the two sites, not by any direct connection. As long as your user can access both the SP and IdP it will work. It's basically the same idea as when you login via facebook or a google account or oauth. Google and authomatic don't talk to each other, instead the users browser does the redirect back and forth.
As long as logging into their workstation also logs them into the AD server then yes. I'm not sure how that works in MS world but I assume that's a solved problem. Otherwise why would AD be a SSO solution?
I've tried the older ways of MS authentication running plone on IIS and using it's proprietary auth mechanisms that only work with IE. It's way worse than saml2.
BTW. One thing that might be confusing is that saml2 can use a direct connection to exchange metadata occasionally. But you can handle that in other ways like moving that metadata to a location that is directly accessible to your plone site, such as inside plone itself if you want.
You are correct, the HTTPS requirement looks to me as an arbitrary M$ hurdle to push customers to use their cloud based ADFS.
In fact, if one would only expose the XML certificate over HTTPS on the public internet (temporarily), the regular XML update cycle could be also automated. We already do something similar for our LE certificate renewals.
Once logged in via the redirect, the browser stores a cookie with an authentication token. I presumed that this is also the mechanism to authenticate with other services provided by the same AD, and hence "SSO" - i.e. not transparently (what I want) but still a single sign on to access multiple services deployed via the M$ proxy.
Seems what you are talking about here is the metadata exchange which isn't how the login happens so the login doesn't require a direct server to server connection.
I've worked with servers that don't have the XML metadata available on a URL so you just make it up yourself and put it on a different server somewhere. Point is it can be anywhere, as long as it's got the right public key and urls inside the XML.
@mtrebron Do you have collective.saml2 working (or at least starting) in a viable plone 6 buildout? If so, with which Python version?
I am getting c segfaults that kill the plone client with no tracebacks when using dm.zope.saml2 or collective.saml2 (implementing the supposed python 3 fixes from its repo) and assumed that they were just too incompatible with python3.8. My environment may be missing something.
I did not get any segfaults, but had to install a prerequisite package libxmlsec1-dev
Maybe also check that you have PyXB==1.2.6
Collecting dm.xmlsec.binding>1.1
Downloading dm.xmlsec.binding-2.2.tar.gz (153 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 153.1/153.1 kB 2.2 MB/s eta 0:00:00
Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [1 lines of output]
Error: cannot get XMLSec1 pre-processor and compiler flags; do you have the `libxmlsec1` development package installed?
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
(Plone6) user@example.com@kallisti:/usr/local/Plone6$ sudo apt install libxmlsec1-dev
