|Anonymous | Login | Signup for a new account||2017-06-24 11:33 EDT|
|My View | View Issues | Change Log | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003933||SOGo||Web General||public||2016-12-08 14:50||2017-06-16 16:10|
|Platform||[Server] Linux||OS||Debian||OS Version||8 (Jessie)|
|Target Version||Fixed in Version|
|Summary||0003933: SAML authentication does not work with XHR requests|
|Description||This is a follow-up to 0003884. I wasn't able to reopen it or comment on it.|
A solution would be to use HTTP-Artifact, which uses a side channel between IdP and SP to transfer to Assertion.
I modified my SAML IdP to support HTTP-Artifact binding, which shouldn't need a POST from the browser. But as it turns out, Artifact Binding itself isn't implemented - see:
But it is listed in the generated Metadata, see:
So probably to resolve this issue, an implementation of HTTP-Artifact binding would be needed.
|Tags||No tags attached.|
Another solution would be maintaining a (local) session after verification of the assertion that is longer valid than the Assertion itself.
In the Shibboleth SP for example, you can set the duration until the session times out (I think default is 60 minutes, I've set it to 1440min). With inactivity, it times out faster (that should work oob in SOGo, too).
The validation of the eventually timed out assertion can be left up to the application. Both crudesaml and my pam-script-saml have a grace parameter which could be set to the session duration.
I've tried setting the Assertions validity duration to 8 hours (and checked it afterwards in the Assertion XML), but the session was gone after 5 mins again.
I found out why the session times out so fast:
The Assertion is saved in SOGoCache, and when validating the session on a request, the assertion is loaded from SOGoCache. However, with the default configuration the CacheInterval is set to 300 secs, so after 5 mins the Assertion is gone.
Is there any possibility to make at least a workaround by saving to a less volatile storage or to increase the lifetime of only the assertions?
And for the case when the assertion is gone after a given time, how can the bad XHR requests be handled? How is this done with "normal" authentication?
I guess the proper solution would be:
1- increase the cache saving time for SAML2 by introducing a new parameter - like SOGoSAML2AssertionTimeout
2- add support for HTTP Artifact Binding
Right now, when a XHR call is made to SOGo and the session is expired, SOGo returns HTML content and the XHR code detects that, and redirects the user to the login page.
thanks for assessing that. At least point 1 would be very nice!
Right now, when the IdP is returning HTML content (after the redirection from the SOGo SP part to the IdP), nothing happens in my installation (see request order in 3884).
We are affected by this as well. Logging into SOGo/dovecot using SAML works nicely, it's just that after five minutes we are redirected to the IdP again. (guessing because the assetion is gone)
It would be very nice if HTTP Artifact Binding could be implemented.
|Yes we plan on implementing that. We need to setup our SAML environment to add support for it.|
Coming back to your comment:
"Right now, when a XHR call is made to SOGo and the session is expired, SOGo returns HTML content and the XHR code detects that, and redirects the user to the login page."
|@ckreutzer how about when you do the same test with SOGo v2?|
|Try tomorrow's nightly build.|
I'll try it in the evening (UTC+0200) and report back.
Regarding comment 11240: Haven't seen any notification for that one. I currently have no v2 test system running, but I'll try to manage that. I probably can't install them on the same machine using the repository?
I tried it running the latest nightly (188.8.131.5270302-1).
I let SOGoCacheInterval time out and choose another Mail in the INBOX.
/SOGo/so/<user>/Mail/0/folderINBOX/<ID>/view is called, response is 302 Redirect to the IdP.
This is the trace for the Initiator of the "view" request in the Chrome Dev Tools... doesn't tell me much, but maybe it gives you the ability to track down how it is handled:
(anonymous) @ angular.js:12433
p @ angular.js:12178
(anonymous) @ angular.js:11930
(anonymous) @ angular.js:16689
$eval @ angular.js:18017
$digest @ angular.js:17827
$apply @ angular.js:18125
(anonymous) @ angular.js:26813
dg @ angular.js:3617
d @ angular.js:3605
|Try again with the latest nightly build.|
edited on: 2017-03-05 07:01
I tried it again today with the latest nightly (184.108.40.20670305-1).
In my case, it's still not working. However I think I know what the problem is. heupink was so kind to give me a test user on his system to follow the requests.
His IdP, Keycloak, returns a HTTP 401 when it isn't able to authorize via Kerberos. Then your error handler jumps in, loads the recover page in the iFrame, which is redirected, the session is refreshed and all is working again.
However in my case, when the redirect from the SOGo XHR request is happening, my IdP (SimpleSAMLphp) is returning a HTTP 200 since it directly reauthorized using the cookies. Probably your error handler then doesn't kicks in, as the request was successful (however not your expected response was returned).
The AuthInterceptor (UI/WebServerResources/js/Common/Common.app.js#L240) also doesn't seem to handle that:
1) L245/6: You're checking against the response content, however my HTML header looks a bit different (example below). Especially my response has no closing ">" after the "html" (no HTML5).
2) Is there a reason not to check the _reponse_ headers for the returned Content-Type?
Of course the iFrame solution is more beautiful than the reload by AuthInterceptor, but I could arrange with that, too :)
Another option would be to apply the same logic in the AuthInterceptor as in the ErrorInterceptor.
Example of my IdPs response:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="http://www.w3.org/1999/xhtml" [^] xml:lang="en" lang="en">
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<form method="post" action="https://example.com/SOGo/saml2-signon-post"> [^]
<!-- Need to add this element and call click method, because calling submit()
on the form causes failed submission if the form has another element with name or id of submit.
See: https://developer.mozilla.org/en/DOM/form.submit#Specification [^] -->
<input type="submit" style="display:none;" />
<input type="hidden" name="SAMLResponse" value="[... Gibberish ...]" />
<button type="submit" class="btn">Submit</button>
HTTP/1.1 200 OK
Content-type: text/html; charset=UTF-8
Date: Sun, 05 Mar 2017 11:43:06 GMT
Thanks again for giving it a try!
|Just wanted to mention that in my keycloak config, kerberos authentication is switched OFF. So as it is now (and as you tested it) my keycloak is not supposed to attempt kerberos. (just thought I'd mention it)|
Lowering to minor.
@ckreutzer - can you provide a test account for me and ssh access to a test server? I would like to see it in action.
That's possible, but the IdP still tries it :)
See the following header:
HTTP/1.1 401 Unauthorized
Date: Tue, 07 Mar 2017 19:54:29 GMT
Cache-Control: no-store, must-revalidate, max-age=0
Keep-Alive: timeout=5, max=100
And the Status 401 is why the ErrorInterceptor is catching that response (Status is not 200 OK) ;)
I've managed to setup a test server where I can give you SSH access to. Would you please contact me via mail sending me a public key to setup for logging in? In response I'll send you the URL and credentials for the test server.
However, I'm 90% sure I've figured the problem out above.
|Contact me by email, my address is all around the planet.|
edited on: 2017-06-10 14:35
Can I ask what the status of this bug is? Is this supposed to be fixed/implemented/finished/closed?
Reason I'm asking is, that in my testing, as soon as I switch from ldap to saml2 auth, I start seeing many errors like:
GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
switching back to ldap gets rid of those. (trying with 3.2.9 currently)
IIRC, it worked for you.
SOGo nor SOPE does not use at all glib - so I don't know where/how that error comes from.
These are coming from liblasso. Sadly, there is no real alternative to it...
I've been looking for some time for a C/C++ SAML library to replace the PHP in pam_script_saml, but liblasso doesn't allow you to extract the assertion, IIRC. And all builds I patched (like the AUF guys https://wiki.auf.org/wikiteki/Projet/SOGo/TestsSAML [^]) and built myself gave these errors, too.
|ah ok, thanks for explaining, ckruetzer!|
|2016-12-08 14:50||ckreutzer||New Issue|
|2016-12-12 03:15||ckreutzer||Note Added: 0010986|
|2016-12-13 07:28||ckreutzer||Note Added: 0010991|
|2016-12-28 14:48||ludovic||Note Added: 0011120|
|2017-01-02 03:58||ckreutzer||Note Added: 0011160|
|2017-01-23 04:58||heupink||Note Added: 0011236|
|2017-01-23 11:37||ludovic||Note Added: 0011237|
|2017-01-23 14:12||heupink||Note Added: 0011238|
|2017-01-24 12:48||ckreutzer||Note Added: 0011239|
|2017-01-24 12:51||ludovic||Note Added: 0011240|
|2017-03-01 11:24||ludovic||Note Added: 0011399|
|2017-03-02 01:27||ckreutzer||Note Added: 0011405|
|2017-03-02 14:36||ckreutzer||Note Added: 0011407|
|2017-03-03 09:17||ludovic||Note Added: 0011417|
|2017-03-05 06:59||ckreutzer||Note Added: 0011431|
|2017-03-05 07:01||ckreutzer||Note Edited: 0011431||View Revisions|
|2017-03-06 04:53||heupink||Note Added: 0011432|
|2017-03-06 11:24||ludovic||Severity||major => minor|
|2017-03-06 11:24||ludovic||Note Added: 0011442|
|2017-03-07 15:00||ckreutzer||Note Added: 0011454|
|2017-03-07 15:04||ludovic||Note Added: 0011455|
|2017-06-10 14:11||heupink||Note Added: 0011915|
|2017-06-10 14:35||heupink||Note Edited: 0011915||View Revisions|
|2017-06-16 11:37||ludovic||Note Added: 0011968|
|2017-06-16 11:45||ckreutzer||Note Added: 0011971|
|2017-06-16 16:10||heupink||Note Added: 0011979|
|Copyright © 2000 - 2017 MantisBT Team|