So I've done a little research into the topic through some slides done by Matt Hamilton, watched his video as-well.
My current stance in understanding how this works is in that:
Windows -> Active Directory -> Plone SSO Plug-in -> Plone site
Linux -> Kerberos -> Plone SSO Plug-in -> Plone site
Unfortunately most of the packages designed for handling SSO are designed on Plone 4 and I've had a little trouble finding something relevant to the current state of Plone 5.
Would someone be able to point me in the best suitable direction for handling SSO in an environment running Kerberos, Active Directory and Plone. What's the most up-to-date method?
Sorry I'm not completely clued up on the subject. In the demo by Matt Hamilton he mentions something called SPNEGO? I want to authenticate the user to Plone through a Windows Active Directory and Linux Kerberos system... I'll check out those things you've mentioned...
We at FHNW (and some other universities I know) use https://pypi.python.org/pypi/Products.AutoUserMakerPASPlugin for SSO authentication in Plone. The authentication is delegated to a Webserver which does the actual authentication through Shibboleth, SPNEGO, whatever. The product was updated recently and is proven to work with Plone 5.
I did not test the mentioned plugins. PAS is very stable over the 4 -> 5 version change in Plone, so I'd overall expect the plugins to work. The configuration panels may have minor issues. Upgrade work should be minimal.
Recently I implemented a custom SAML2 integration for a large customer from Salzburg. It is not public yet and has some specifics for their environment. Since we're using it probably in a second project of the same customer and starting to generalize it in the next months, I can ask if we may make it public. All this works in Plone 5.1.
@jensens any reason dm.saml2 didn't work for you? It's been pretty flexible for us.
@Netroxen The brief summartiy is that there are many methods of SSO so you need to tell us what you want to integrate with. For example one of the most common is SSO in windows environment where the aim is to use the same login/auth as the user used to login into their PC with. There are a few ways to do this such as KERBEROS or running plone behind IIS and getting IIS to magically talk to windows to find out who the user is.
However I suspect this not very popular anymore. Now days I think most people are switching to a federated authentication, normally saml2 based in the enterprise. This works similar to how you can log into a web app using facebook or google. Your login gets redirected to the identity provider (such as google suite, Microsoft active directory federated services (ADFS), you login in to that webpage and then get redirected back to your plone site. And if you have already authenticated with the identity provider then you see the screen flicker as it gets redirected over and then back again but effectively it feels like you didn't have to login again. Hence it's SSO. The reason why this is a nicer solution is that there is no need for a VPN or backchannel between Plone and ADFS. They can be on completely different networks and on the other side of the world from each other. Trust is setup via keys and exchanged at login time.
The downsides of all this is that:
a) you no longer get access to groups and other info from active directory which means plone can't list users or groups.
b) SAML2 is one of those big standards that no one ends up implementing all of, so even though there are a lot of different identity providers and service providers (the big that redirects to the login) software, getting them to talk to each other can be a pain.
c) SAML2 often doesn't get mentioned by name. For example Shiboleth is SAML2. ADFS is SAML2, they just don't mention it much.
One other thing to note. dm.saml2 (and hence collective.saml2) can act as both an identity provider and a service provider. We've used it successfully to have a single plone site be what everyone logs into and then goes off to 4 other apps which all used saml2 to get SSO auth into from plone.
Well, I took a rough look, but for the project we based all on python-saml which is a widely used and well supported base library in the python world, while dm.saml2 seems to be less supported. Also recent dm.zope.saml2 releases are stuck in betas. Having such a great base library as python-saml2 makes it really simple to write a PAS plugin for, eventually simpler than understanding a base like dm.zope.saml2 and finding which adapter to override. It resulted in a streamlined non-bloated plugin, fairly manageable by the development team of my customer.
And forgot one thing: there is no official public repository for dm.zope.saml2 where I can do pull requests. At least my google did not find one. Also, there is no statement by the author if he accepts patches nor what the process is. This is usually a bad sign fo a project with high probability to stall or even disappear at some point in future.
AD can be done via LDAP, i.e. using pas.plugins.ldap.
Once (with Plone 2.5) I had a Linux -> LDAP -> Kerberos setup running, where LDAP did all Kerberos specific communication and Plone just talked to LDAP. Probably this is not what you want.
Agreed. @dieter is... @dieter. He has refused a public repo no matter how many times I've asked. He has accepted some patches from me and others but not all. You email him and try to convince him. That is the process.
I suspect python-saml2 was not around when dm.saml2 started. If your plugin has the same capabilities and is well supported then I may switch and contribute to yours instead. Especially if you support custom properties and if you can solve the issue of syncing groups across saml2.
BTW dm.saml2 doesn't use adapters, but rather TTW configuration which is very convenient. For example to configure a custom attribute you can just use a python script if you want.
After modest success with pas.plugins.ldap and Plone v5.0.7 I'm attempting SSO. It's been a rocky road thus far.
I added the netsight.windowsauthplugin and rebuilt . When I attempt to start Plone I'm hitting the wall with this error at the bottom of the stacktrace:
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/opt/plone/zinstance/parts/instance/etc/site.zcml", line 12.2-12.39
ZopeXMLConfigurationError: File "/opt/plone/buildout-cache/eggs/Products.CMFPlone-5.0.7-py2.7.egg/Products/CMFPlone/meta.zcml", line 46.4-50.10
ImportError: No module named kerberos
I figured the error didn't like my python environment. So I installed the Kerberos package in my Debian OS box with the following steps:
There are two quite different notions of SSO: SSO between different internet/intranet sites and SSO between an intranet and the desktop. You seem to be interested in the second type of SSO. There has recently been a discussion about this type in this forum.
Typically, Plone is set up to use its own Python installation; in those situations, it cannot use Python packages installed with "apt-get". Maybe, you are in such a situation?
I am also a bit surprised by the pip3 above. To me, this suggests installing something for Python3 - and Plone is using Python 2.
There could be cross over. For example ADFS might be set to integrate with the desktop login and then a service like plone might be set to use ADFS via SAML2 to login. This would effectively give you SSO from a desktop login without having to deal directly with kerberos/ntlm or whatever the desktop stuff uses (which from memory is a huge pain
Doing direct Kerberos authentication with the netsight.windowsauthplugin is indeed a complicated and painful set up, but it does work, I got it running in 2015 for a customer intranet.
this is direct kereros from the server where plone runs to Active Directory, As mentionned above ADFS might be a better decoupled solution. I don't know because I already had huge problems convincing sysadmins to do anything to their AD-domain, let alone having them install ADFS just for me at this customer.
A few tips & buildout snippets:
the Plone plugin needs kerberos, which needs kerberos on the server you're running Plone. I was at the time struggling with an older debian linux with even older Kerberos system packages. What you can do is download the latest stable Kerberos sources, compile them in a separate directory and have the python-kerberos bindings link to this kerberos install, then you're independent from lagging buggy kerberos libraries. I also need this because only newer kerberos versions supported logging, which proved valuable to figure out encryption mismatches later on.
When you start Zope you can set a number of environment variables that kerberos will use to fetch its configuration, notably KRB5_KTNAME and KRB5_CONFIG . You can add these to the buildout section for the zeoclient in the environment-vars. Then you can create your own custom kerberos config and link to the keytab containg the keyfile with which Zope/Plone will be able to authenticate itself to the kerberos domain.
make an internal release from the github-repo from netsight.windowsauthplugin, the latest public release on pypi is not enough. Matt Hamilton did 2 modifications (I think I chatted with him about those) so that you can set the service property again and another fix with proxying. It also has a fix by me so you can still run your site on a development machine without the kerberos libraries being present.
the GSSAPI service value is important, it's in the properties sheetof the spnego plugin installed in your acl_users folder in Zope. it should be the format HTTP@server.domain.org, this is kerberos speak and not a domain name and should match what you enter to create the keytab on the windows server (follow Matt's screencast and instructions from netsight.windowsauthplugin for that).
Enabling logging helps. A lot. Especially when you have to figure out encryption mismatches.
This is part of my kerberos.cfg that I use as a kind of mix to my normal buildout config to enable kerberos and compile a custom python-kerberos binding to my kerberos install in /var/zope/kerberos :
[conf]
kerberos_keytab = ${buildout:directory}/var/service_kerberos.keytab
[zeoclient]
eggs += ${python-kerberos:egg}
# loaded by default in base.cfg, otherwise we cannot run local devel
# installs where the PAS plugin is in the data.fs
# netsight.windowsauthplugin
environment-vars += KRB5_KTNAME ${conf:kerberos_keytab}
KRB5_CONFIG ${krb5-config:output}
[python-kerberos]
recipe = zc.recipe.egg:custom
egg = pykerberos
include-dirs = /var/zope/kerberos/include
/usr/local/include
/usr/include
library-dirs = /var/zope/kerberos/lib
/usr/local/lib/
/usr/lib
rpath = ${:library-dirs}
[krb5-config]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/krb5.conf.in
output = ${buildout:directory}/parts/conf/krb5.conf
This is the kerberos-config template I am using, the important parts are getting the encryption right, the kerberos domain and the kerberos <-> dns domain mapping.
[libdefaults]
default_realm = YOUR.ORG.DOMAIN
dns_lookup_kdc = no
dns_lookup_realm = no
ticket_lifetime = 24h
rdns = false
; Don't use this, we set the KRB5KTNAME variable in the zeoclient setup env-vars
; default_keytab_name = ${buildout:directory}/var/service_kerberos.keytab
; for Windows 2008 with AES
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac
permitted_enctypes = rc4-hmac
; default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
; default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
; permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
[realms]
YOUR.ORG.DOMAIN = {
kdc = kdc.server.name:88
admin_server = kdc.server.name:749
default_domain = YOUR.ORG.DOMAIN
}
[domain_realm]
.your.org.domain = YOUR.ORG.DOMAIN
your.org.domain = YOUR.ORG.DOMAIN
[logging]
default = FILE:${buildout:directory}/var/log/krb5lib.log
admin_server = FILE:${buildout:directory}/var/log/kadmin.log
kdc = FILE:${buildout:directory}/var/log/krb5kdc.log