Logout issue with multiple SPs (Google and our own Intranet Portal) and Single IdP

[amu...@rsu18.org]

We are trying to setup single sign on for our intranet portal and G Suite using LDAP (AD) for authentication. As far as I can tell, everything is working except the logout process. When signing out of Google, we are getting the following error using URL https://<IdP Domain>/simplesaml/saml2/idp/SingleLogoutService.php. I'm not sure if this is relevant but I am sharing the same simpleSAMLphp library files with our internal SP (portal) and IdP but they are on different vhosts.

You accessed the SingleLogoutService interface, but did not provide a SAML LogoutRequest or LogoutResponse. Please note that this endpoint is not intended to be accessed directly.

DEBUG INFO:

SimpleSAML_Error_Error: SLOSERVICEPARAMS

Backtrace:
0 www/saml2/idp/SingleLogoutService.php:30 (N/A)
Caused by: Exception: Unable to find the current binding.
Backtrace:
2 vendor/simplesamlphp/saml2/src/SAML2/Binding.php:99 (SAML2\Binding::getCurrentBinding)
1 modules/saml/lib/IdP/SAML2.php:539 (sspmod_saml_IdP_SAML2::receiveLogoutMessage)
0 www/saml2/idp/SingleLogoutService.php:23 (N/A)

If i use this, it only signs out of Google and nothing else but then signing out of our Portal throws an error because it tries to sign out all SPs.

https://<IdP Domain>/simplesaml/module.php/saml/sp/metadata.php/google

 

[Peter Schober]

* amurray via SimpleSAMLphp <simple...@googlegroups.com> [2018-04-13 15:09]:

> We are trying to setup single sign on for our intranet portal and G Suite
> using LDAP (AD) for authentication. As far as I can tell, everything is
> working except the logout process.

AFAIK Google does not suppot SAML SLO.
Do they? (Not something this forum is authoritative for.)

> You accessed the SingleLogoutService interface, but did not provide
> a SAML LogoutRequest or LogoutResponse. Please note that this
> endpoint is not intended to be accessed directly.

What exactly is unclear about this? If you want to use SLO, like SSO,
you'll have to send a SAML protocol message. Simply accessing the URL
where SAML protocol messages should be sent for logout purposes does
not make them proper SAML requests.

> If i use this, it only signs out of Google and nothing else but then
> signing out of our Portal throws an error because it tries to sign out all
> SPs.
>
> https://<IdP Domain>/simplesaml/module.php/saml/sp/metadata.php/google

What makes you think a URL like this will cause logout anywhere?
(It does not, not even at Google. Google logs you out locally -- which
of course is completely meanigless with SSO -- before it sends
you there. So you could just as well provide https://duckduckgo.com/
as that URL. That will not log you our any less than the URL above.

Now if SSP supports IDP-initiated SLO that is a URL you could redirect
to from Google's not-SAML logout redirect.

Or you could simply accept that logging out from web applications is
not what you'd possibly expect -- esp it's not the reverse of SSO.
Unless you know that it always works for all services (which you
can't, in distributed computing) you'll have to have a plan B. And if
you have a plan B why bother with plan A?

More seriously, though, logging out of web applications is also not
sufficient as the computer will have lots of other data (and possibly
other open sessions) on it that need protection. So lock the device
instead, which also takes care of active web sessions as a side-effect.

-peter

[Jaime Perez Crespo]

Hi,

On 13 Apr 2018, at 15:09 PM, amurray via SimpleSAMLphp <simple...@googlegroups.com> wrote:
> We are trying to setup single sign on for our intranet portal and G Suite using LDAP (AD) for authentication. As far as I can tell, everything is working except the logout process. When signing out of Google, we are getting the following error using URL https://<IdP Domain>/simplesaml/saml2/idp/SingleLogoutService.php. I'm not sure if this is relevant but I am sharing the same simpleSAMLphp library files with our internal SP (portal) and IdP but they are on different vhosts.
>
> You accessed the SingleLogoutService interface, but did not provide a SAML LogoutRequest or LogoutResponse. Please note that this endpoint is not intended to be accessed directly.

Google does not support SLO, as far as I recall. Therefore, if you configure your SLOEndpoint as the logout URL in Google, they won’t send a SAML logout request there, and then you’ll get this error back.

You may want to configure "/simplesaml/logout.php” instead.

—
Jaime Pérez
Uninett / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Adam Murray]

I have found differing opinions about Google's support for SLO. I'm just not sure why the specific Google setup documentation says to put that URL in if it seemingly does not work. I do not have <md:SingleSignOnService> anywhere in my metadata XML either.

You will find in the metadata the XML tag <md:SingleSignOnService> which contains the right URL to input in the field, it will look something like this:

https://dev2.andreas.feide.no/simplesaml/saml2/idp/SSOService.php

You must also configure the IdP initiated Single LogOut endpoint of your server. You will find this in your metadata XML in the tag <md:SingleLogoutService>. It will look something like:

http://dev2.andreas.feide.no/simplesaml/saml2/idp/SingleLogoutService.php

[Peter Schober]

* 'Adam Murray' via SimpleSAMLphp <simple...@googlegroups.com> [2018-04-13 17:01]:

> I have found differing opinions about Google's support for SLO.

Then this is the last place to come looking for an authoriative
statement. As the vendor.

> I'm just not sure why the specific Google setup documentation says
> to put that URL in if it seemingly does not work.

So they can make it your problem while appearing to "support logout".

-peter

[James Harris]

On Friday, April 13, 2018 at 12:21:51 PM UTC-4, Peter Schober wrote:

* 'Adam Murray' via SimpleSAMLphp <simple...@googlegroups.com> [2018-04-13 17:01]:
> I have found differing opinions about Google's support for SLO.

Then this is the last place to come looking for an authoriative
statement. As the vendor.

I also recommend asking Google. They have a site to ask for feature requests https://www.cloudconnectcommunity.com/ and might build it one day.

> I'm just not sure why the specific Google setup documentation says
> to put that URL in if it seemingly does not work.

So they can make it your problem while appearing to "support logout".

I pondering a SSP module that would provide a URL for Google's logout. Something gsuite/logout.php?entityid=google.com would remove the google.com association. So the user sees a successful log out if they click logout from Gmail. But do see an error with IDP initiated/other SP initiated logout. Not like SAML SLO. But at least gives the user a chance of correctly logging out.

-James

[Peter Schober]

* James Harris <har...@adelphi.edu> [2018-04-30 22:25]:

> I pondering a SSP module that would provide a URL for Google's logout.

Jaime already provided the URL you could configure in your tenant settings:

* Jaime Perez Crespo <jaime...@uninett.no> [2018-04-13 15:39]:

> You may want to configure "/simplesaml/logout.php” instead.

As to your suggestion:

> Something gsuite/logout.php?entityid=google.com would remove the google.com
> association. So the user sees a successful log out if they click logout
> from Gmail. But do see an error with IDP initiated/other SP initiated
> logout. Not like SAML SLO. But at least gives the user a chance of
> correctly logging out.

No idea what that should do but at worst it's creating a false sense
of security.
*Instead* people should lock/logout from the device itself, which will
also protect their chat messages, private photos, email account, as
well as all other data at the device.

Why would you want to hand over your computer, with you being logged
in, to an untrusted person? That doesn't make any sense, even without
bringing SAML or SSO into the picture.

* If that's a PC lab of some kind have people log off from the
workstation instead (and make them responsible for any damage that
occurs from leaving an authenticated session on the PC behind for
others to misuse.)

* If it's a public kiosk of yours (1) I'd question whether you should
be offering any SSO-enabled services there at all, and (2) you have
options to make "logout" simple and secure by configuring the browser
to that closing the browser removes all session cookies (or better
yet: any local state, all cookies, HTML5 local storage, etc.).
Also add a big, friendly "END SESSION" button on the screen and make
people responsible to walking away without ending their session.
Sensitive services should probably use forced (re-)authentication with
their SAML authentication requests. The IDP might be configured to
disable SSO for the IP ranges (or user agent strings) for managed
kiosks or other "public" PCs. etc.pp.

* I'm not aware of many sensible use cases that require sharing a
device with someone else but in those cases it's trivial to start a
"private" browser window (or another browser implementation
altogether) before giving it to the other person, so that the browsers
don't share any state.

None of this has to do with Google, but all of those avoids "the
logout problem" in the general case, IMO.

-peter

[James Harris]

On Thursday, May 3, 2018 at 9:09:26 AM UTC-4, Peter Schober wrote:

* James Harris <har...@adelphi.edu> [2018-04-30 22:25]:
> I pondering a SSP module that would provide a URL for Google's logout.

Jaime already provided the URL you could configure in your tenant settings:

* Jaime Perez Crespo <jaime...@uninett.no> [2018-04-13 15:39]:
> You may want to configure "/simplesaml/logout.php” instead.

Thanks, that's a good choice. I didn't read the whole thread, especially the first messages. Just saw a thread about logout and Google and got excited.

As to your suggestion:

> Something gsuite/logout.php?entityid=google.com would remove the google.com
> association. So the user sees a successful log out if they click logout
> from Gmail. But do see an error with IDP initiated/other SP initiated
> logout. Not like SAML SLO. But at least gives the user a chance of
> correctly logging out.

No idea what that should do but at worst it's creating a false sense
of security.

It handles a user clicking Gmail's Sign Out as if Google sent a SAML Logout Request. I read through what Logout Request does, and afaict, boils down to:

$idp->terminateAssociation("saml:google.com");

$idp->doLogoutRedirect("/simplesaml/logout.php");

If the user logs out via Google (or never SSOed to Google), SSP won't show warnings about failed SLO for Google. 

*Instead* people should lock/logout from the device itself, which will
also protect their chat messages, private photos, email account, as
well as all other data at the device.

 

Why would you want to hand over your computer, with you being logged
in, to an untrusted person? That doesn't make any sense, even without
bringing SAML or SSO into the picture.

* If that's a PC lab of some kind have people log off from the
workstation instead (and make them responsible for any damage that
occurs from leaving an authenticated session on the PC behind for
others to misuse.)

* If it's a public kiosk of yours (1) I'd question whether you should
be offering any SSO-enabled services there at all, and (2) you have
options to make "logout" simple and secure by configuring the browser
to that closing the browser removes all session cookies (or better
yet: any local state, all cookies, HTML5 local storage, etc.).

Since where talking about google, all cookies.

 

Also add a big, friendly "END SESSION" button on the screen and make
people responsible to walking away without ending their session.
Sensitive services should probably use forced (re-)authentication with
their SAML authentication requests. The IDP might be configured to
disable SSO for the IP ranges (or user agent strings) for managed
kiosks or other "public" PCs. etc.pp.

* I'm not aware of many sensible use cases that require sharing a
device with someone else but in those cases it's trivial to start a
"private" browser window (or another browser implementation
altogether) before giving it to the other person, so that the browsers
don't share any state.

None of this has to do with Google, but all of those avoids "the
logout problem" in the general case, IMO.

Thanks for writing this. It was informative and I agree all of that must be done.

But the logs show many users click logout. They also wander off-campus and borrow a friend's device and do insecure stuff like that. And then read the logout text "You have been logged out." (I wanted to change it to "for secure logout, submerge this device in salt water while powered on". But legal didn't like that.) I figure this was a small improvement.

-James