Re: [SOGo] SAML2 authentication requirements

[Christoph Kreutzer]

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 

Re: [SOGo] SAML2 authentication requirements

[Christoph Kreutzer]

> 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:
https://wiki.auf.org/wikiteki/Projet/SOGo/TestsSAML 


Christoph.
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] SAML2 authentication requirements

[Christoph Kreutzer]

> Am 01.07.2013 um 20:10 schrieb Stephen Ingram :
> 
> On Sat, Jun 29, 2013 at 6:13 AM, Ludovic Marcotte  > wrote:
> On 2013-06-29 1:57 AM, Stephen Ingram wrote:
>> The makefile in SoObjects/SOGo (line 149) indicates the presence of this 
>> metadata file, but there is none. The code in SOGoSAML2Session also appears 
>> to look for this file (SOGoSAML2Metadata.xml). Does this need to be added 
>> before compiling? I've tried adding it to the WebserverResources directory, 
>> but SOGo still doesn't pick it up.
> Try placing it in /usr/sbin/Resources/sogod/Resources/  (adjust depending on 
> where your sogod binary is located and create the Resources directory).
> 
> That is just to some brain damage in the bundle loading code.
> 
> That doesn't work, but it did give me a hint as to where it should be. The 
> magic location is /usr/lib/GNUstep/Frameworks/SOGo.framework/Resources/. I 
> can now see the metadata when browsing to 
> https://webmail.4test.net/SOGo/saml2-metadata 
> . If I try to login at 
> https://webmail.4test.net/SOGo  I am 
> correctly re-directed to the IdP for authentication.
> 
> I still don't have a working system as once authenticating at the IdP, SOGo 
> apparently doesn't receive what it's looking for and tries to login with 
> nothing:
> 
> EXCEPTION:  NAME:NSInvalidArgumentException 
> REASON:Tried to add nil value for key 'login' to dictionary INFO:{}
> 
> which results in a proxy error:
> 
> The proxy server received an invalid response from an upstream server. The 
> proxy server could not handle the request POST /SOGo/saml2-signon-post.
> 
> Looking at the code, I see that SOGo maybe only wants either the uid or mail 
> attributes encoded in a SAML2NameID format. I'm not sure if the endpoint 
> /SOGo/saml2-signon-post is correct or not as I gleaned it from error logs 
> listing typical SOGo requests. Are /SOGo/saml2-metadata and 
> /SOGo/saml2-signon-post the only two endpoints?
> 
> Steve


Hi,

I know that was long ago, but maybe someone can help. I tried setting up SOGo 
3.1.5 on Debian Jessie with SAML Auth (SimpleSAMLphp IdP is working properly 
with Shibboleth SP).
Following Configuration:

// SAML
SOGoAuthenticationType = saml2;
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“;

I also tried it without SOGoSAML2LoginAttribute, but I get the same error as 
above:

Sep 16 19:01:00 sogod [17999]: <0x0x7f7b1f9a4fc0[SOGoCache]> Cache 
cleanup interval set every 300.00 seconds
Sep 16 19:01:00 sogod [17999]: <0x0x7f7b1f9a4fc0[SOGoCache]> Using 
host(s) 'localhost' as server(s)
EXCEPTION:  
NAME:NSInvalidArgumentException REASON:Tried to add nil value for key 'login' 
to dictionary INFO:{}
Sep 16 19:01:00 sogod [17945]: <0x0x7f7b1fc00530[WOWatchDogChild]> 
child 17999 exited
Sep 16 19:01:00 sogod [17945]: <0x0x7f7b1fc00530[WOWatchDogChild]>  
(terminated due to signal 6)
Sep 16 19:01:00 sogod [17945]: <0x0x7f7b1fa1c190[WOWatchDog]> child 
spawned with pid 18002

How could you resolve this, Stephen?


Thanks,
Christoph

PS: There is a typo in the documentation: SOGoSAML2CertiTicateLocation ;) Cost 
me half an hour to find out.
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] SAML2 authentication requirements

[Stephen Ingram]

I'm trying to setup SAML2 authentication for SOGo and not sure of the
requirements. According to the installation guide, only changes to to the
SOGo configuration are necessary. Of course, you must then use something
like the crudesaml plugin to handle the authentication to the IMAP server,
but that is not necessary for SOGo itself. I set
SOGoAuthenticationType=saml2 along with all of the cert and Idp metadata
information, but nothing seems to happen. I get a proxy error when trying
to bring up the login page with the log saying:

GLib-GObject-WARNING **: invalid cast from `LassoLibAuthnRequest' to
`LassoSamlp2AuthnRequest'

The installation manual leads you believe that everything is automatic
beyond the SOGoSAML2... configuration lines in sogo.conf. Does SOGo
actually do everything including SP functionality or do you have to setup
something like a Shibboleth SP to get things working?

Also, the metadata link turns up a HTTP 200 with a blank page. Is there
another way to get the metadata as the IdP obviously needs it to work
properly?

Steve
-- 
users@sogo.nu
https://inverse.ca/sogo/lists