General discussion on installation and configuration of SOGo

Text archives Help


Re: [SOGo] SAML2 authentication requirements


Chronological Thread 
  • From: "Christoph Kreutzer" ( ) < >
  • To: Stephen Ingram < >
  • Cc:
  • Subject: Re: [SOGo] SAML2 authentication requirements
  • Date: Thu, 20 Oct 2016 15:15:32 +0200
  • Dmarc-filter: OpenDMARC Filter v1.2.0 mail.inverse.ca C80B61206287

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)
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

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.
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 < >:

On Sun, Sep 18, 2016 at 4:09 AM, Christoph Kreutzer < > wrote:

Am 16.09.2016 um 19:11 schrieb Christoph Kreutzer < >:

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:

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 again. If you do find a good solution, I would love to hear what you did.

Steve



  • Re: [SOGo] SAML2 authentication requirements, Christoph Kreutzer, 10/20/2016

Archive powered by MHonArc 2.6.18.

Top of page