Hi Steve,
I was also afraid of patching common libraries, but I also tried following the
AUF recipe (without success). I also thought about the OpenChange way (allow
access without password from localhost [or other SOGo host]), but that wasn’t
really what I wanted, as you noted by yourself ;) As for EAS, this works fine
for me out of the box, but I’m not using OpenChange.
I researched a bit further and documented my steps as good as I can remember
(forgot to take notes sometimes).
Christoph.
SAML with SOGo and Dovecot
==========================
SOGo SAML configuration
-----------------------
I am using the following configuration, which is pretty straightforward:
SOGoAuthenticationType = saml2;
NGImap4AuthMechanism = PLAIN;
SOGoSAML2PrivateKeyLocation = "/etc/sogo/saml.pem";
SOGoSAML2CertificateLocation = "/etc/sogo/saml.crt";
SOGoSAML2IdpMetadataLocation = "/etc/sogo/idp-metadata.xml";
SOGoSAML2IdpPublicKeyLocation = "/etc/sogo/idp.crt";
SOGoSAML2IdpCertificateLocation = "/etc/sogo/idp.crt";
SOGoSAML2LoginAttribute = "mail";
SOGoSAML2LogoutEnabled = YES;
SOGoSAML2LogoutURL = "https://example.com";;
idp-metadata.xml and idp.crt come from the IdP.
saml.pem and saml.crt are your certificate and private key, possible generated
like this:
openssl req -newkey rsa:2048 -new -x509 -days 3652 -nodes -out saml.crt
-keyout saml.pem
Most important is the IMAP part.
>From the SOGo installation guide: "if you make use of the CrudeSAML SASL
>plugin, you need to make sure that NGImap4AuthMechanism is configured to use
>the SAML mechanism. If you make use of the CrudeSAML PAM plugin, this value
>may be left empty."
That suggests, if you are using PAM, you can leave the defaults. At least with
Dovecot, this doesn't work out of the box.
SOGo will use the LOGIN command and sends the full SAML assertion as password.
Dovecot will fail to authenticate, because the "password" is larger than the
reserved memory.
But you can use AUTHENTICATE PLAIN, because for AUTHENTICATE a larger buffer is
reserved (for using Kerberos tickets, etc.). To get SOGo/SOPE to do this, add
the NGImap4AuthMechanism = PLAIN as I did above.
Dovecot SAML authentication (PAM)
---------------------------------
1. crudesaml, as listed in SOGo documentation
1.1 UCS crudesaml & liblasso3
(Univention Corporate Server, Debian based enterprise Linux)
- Issue crudesaml deb-Build:
https://forge.univention.org/bugzilla/show_bug.cgi?id=39315
- crudesaml deb:
http://updates.software-univention.de/4.1/maintained/4.1-0/amd64/pam-saml_1.5.0-4.12.201510061230_amd64.deb
Also needs patched liblasso3 installed (see issue, and:
https://dev.entrouvert.org/issues/8042).
I just added the Repository in APT and pinned it, so that only the specific
packages where installed.
However, segfaults while processing the PAM request on Debian Jessie.
1.2 Custom build crudesaml against default liblasso3
Gives "Undefined symbol: lasso_provider_verify_saml_signature" (as expected)
1.3 Custom build liblasso3 from upstream and crudesaml
- patched using the patches by Inverse/AUF
(https://wiki.auf.org/wikiteki/Projet/SOGo/TestsSAML)
- second build patched using UCS patch (https://dev.entrouvert.org/issues/8042)
Sometimes segfaulted, but most of all flooded logs with: GLib-GObject-WARNING
**: cannot register existing ... (clashed with installed liblasso3 by Debian)
Worked for some requests, for most not (I would say 1 of 4, because of glib
problem)
1.4 liblasso3 using deb-src package and patching
I tried it once, but I didn't like it ;) Build failed even without patching
(but I think only because all bindings where compiled, too)
Didn't tried any longer then, as I don't want to have to patch every single
release.
2. pam-script
https://packages.debian.org/en/jessie/libpam-script
2.1 bash implementation of crudesaml
I started with it, only using minimal dependencies (xmllint, openssl, xmlsec).
But then realized, that it would be hard to implement the whole SAML protocol
with XML extraction using xmllint --xpath and verifying signatures using xmlsec.
2.2 pam-script-saml
Is a PHP implementation using the LightSAML library
(https://www.lightsaml.com/LightSAML-Core/), accepts nearly the same arguments
like pam-saml.
Available on GitHub: https://github.com/ck-ws/pam-script-saml
Time will tell if it is performing good enough. For the moment it works good
enough in a test environment.
DAV Access
----------
DAV access for Cal/CardDAV will usually not support SAML authentication. The
simplest solution is to keep your default authentication source in place, on
which SOGo should rely nevertheless.
I, however, don't really want my users passwords in some apps. So I built
something like Googles App Passwords, stored in a MariaDB/MySQL database. SOGo
currently only checks the first result row for a given uid (but I think it
should be easily changeable, see feature request #3820).
I currently work around it by creating multiple views for authentication
sources, each returning only one password per user. This is a bit tricky (at
least as long MariaDB doesn't support analytical window functions), but if
somebody is interested, I could document it.
> Am 19.09.2016 um 14:53 schrieb Stephen Ingram <sbing...@gmail.com>:
>
> On Sun, Sep 18, 2016 at 4:09 AM, Christoph Kreutzer
> <kreutzer.christ...@gmail.com <mailto:kreutzer.christ...@gmail.com>> wrote:
>
>> Am 16.09.2016 um 19:11 schrieb Christoph Kreutzer
>> <kreutzer.christ...@gmail.com <mailto:kreutzer.christ...@gmail.com>>:
>>
>> How could you resolve this, Stephen?
>
> I found it out (after adding a consent:Consent to simpleSAMLphp):
> As the Shibboleth SP wants OID attributes, I had added a name2oid
> AttributeMap. I just added a oid2name in the SP metadata in simpleSAMLphp and
> it works now :)
>
> Now I only have to find out how to make SAML work with Dovecot, hopefully
> without patching and recompiling:
> https://wiki.auf.org/wikiteki/Projet/SOGo/TestsSAML
> <https://wiki.auf.org/wikiteki/Projet/SOGo/TestsSAML>
>
> Christoph-
>
> Glad to hear you got things working at least on the front end. Unfortunately,
> I never was able to get either of the solutions recommended by the SOGo
> manual working on the backend to the mail store (in your case Dovecot). Both
> solutions are sort of a mess in that they use non-standard patches that don't
> seem to be supported by any distribution packages. You could setup in a
> similar way to how they developers advocate using EAS by simply allowing all
> access to the mail server from SOGo. Even though it's really difficult to
> pass the password, the username seems to be passed properly so if you tell
> Dovecot to accept the connection, so you should end up with the correct user.
> Certainly not the best considering that you are obviously trying to setup a
> secure solution by not exposing the password at all. I'm guessing not too
> many schools have deployed SOGo (with Shibboleth), or they are keeping very
> quiet about how they are doing it. I never heard back from anyone at auf.org
> <http://auf.org/> again. If you do find a good solution, I would love to hear
> what you did.
>
> Steve
--
users@sogo.nu
https://inverse.ca/sogo/lists
