HTTP-POST SingleLogoutService binding for IdP on a bridged SSP (SP/IDP Proxy setup)

[Shweta]

We have the IdP Proxy implementation setup using SSP v1.13.2. 

Most remote SPs that have used it, have used HTTP-Redirect successfully. We have a new SP that does not support Redirett, and requests HTTP-POST for both signon and logout. 

I did add in the SingleSignonService binding to saml20-idp-hosted.php.

        /**

 * Specifiy the bindings to support

 */

'SingleSignOnServiceBinding' => array('urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',

'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'),

For this SP - Tableau, we need to provide a HTTP-POST binding for our IdP. It maybe super trivial, however I can't find info on the logout binding. 

This is from a Shib IdP metadata, something similar for SSP IdP is required. 

<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.test.edu/idp/profile/SAML2/POST/SLO"/>

Referenced this amongst other docs - https://simplesamlphp.org/docs/1.8/simplesamlphp-metadata-endpoints

1. Is it supported for SSP IdP
2. Syntax of how to add it - is it similar to what's there for "SingleSignOnServiceBinding"?

Thanks!

Shweta

[Jaime Perez Crespo]

Hi Shweta,

On 17 May 2017, at 20:43 PM, Shweta <shweta...@gmail.com> wrote:
> We have the IdP Proxy implementation setup using SSP v1.13.2.

Please upgrade it ASAP. 1.13.2 is two and a half years old now. There’s been 15 stable releases (with lots of bugfixes) and 10 security advisories since then. You should always run up-to-date software, specially authentication-related software like this.

> Most remote SPs that have used it, have used HTTP-Redirect successfully. We have a new SP that does not support Redirett, and requests HTTP-POST for both signon and logout.

I’m not sure I understand. HTTP-POST is the default and most used binding to send a SAML response to an SP, while HTTP-Redirect is used by SPs to send requests, and by both SPs and IdPs during logout.

> I did add in the SingleSignonService binding to saml20-idp-hosted.php.

That is your own configuration. You are telling SimpleSAMLphp there how its own metadata should look like, and how should it behave globally. What you want, though, is to configure that remote SP in particular.

> /**
> * Specifiy the bindings to support
> */
> 'SingleSignOnServiceBinding' => array('urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
> 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'),
>
> For this SP - Tableau, we need to provide a HTTP-POST binding for our IdP. It maybe super trivial, however I can't find info on the logout binding.

They should provide you with their SAML metadata. If you parse that metadata with the SimpleSAMLphp metadata parser, the resulting metadata in PHP format should be correct. If that’s not the case (because their metadata is broken or they don’t provide SAML metadata), you can still configure it manually in the corresponding entry in “metadata/saml20-sp-remote.php”.

>
> This is from a Shib IdP metadata, something similar for SSP IdP is required.
> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.test.edu/idp/profile/SAML2/POST/SLO”/>

Use this:

https://simplesamlphp.org/docs/stable/simplesamlphp-metadata-endpoints

> Referenced this amongst other docs - https://simplesamlphp.org/docs/1.8/simplesamlphp-metadata-endpoints

Note that the documentation you are browsing is for an ancient version of SimpleSAMLphp. There’s a big warning about it in the top right of that page. Please use always the documentation corresponding to the version you have installed (and make sure to use the latest stable release).

> • Is it supported for SSP IdP

> • Syntax of how to add it - is it similar to what's there for "SingleSignOnServiceBinding"?
> Thanks!
> Shweta

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

[Shweta]

Jaime,

<Sorry for the empty post earlier,, clicked too soon>

We will schedule to upgrade as soon as we can. Typical steps would be to make a backup of the complete simplesaml directory, then apply and upgrade OR start from a fresh install and apply config/changes ? 

Notable modifications we have:

1. custom module/theme for overriding certain pages like logout -  modules/mymodule/theme/mytheme/default/logout.php
2. Hacky but, in-place code change in this file for overriding UI for discovery service: simplesaml/modules/saml/www/disco.php 
3. Metadata auto refresh
4. Bridged implementation, obviously

If you could recommend the right way to upgrade from 1.13, it would be helpful. 

For the current problem at hand, the remote SP, has the following in their metadata. They seem to want the SSP IDP to have a similar endpoint configured with HTTP-POST binding(?). I guess my confusion arises from not having seen a config file with SLO endpoint with HTTP-POST binding for an SSP IdP. They need to load our IdP metadata on the SP-- obviously and are having issues setting it up with the absence of this binding. 

I've seen it for Shibboleth IdPs metadata.

This is the snippet from the vendor metadata (remote SP) 

 'SingleLogoutService' => 
  array (
    0 => 
    array (
      'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
      'Location' => 'https://remote.sp/wg/saml/SingleLogout/index.html',
    ),
  ),

This is a snippet of IdP's metadata, with only HTTP-Redirect binding for logout. According to my understanding, the remote SP, should be sending the user to this logout url (like other SPs are doing..) and the logout for IDP and SP is handled.  

https://ssp.proxy.idp/simplesaml/www/module.php/core/authenticate.php?as=default-sp&logout

'SingleSignOnService' => 
  array (
    0 => 
    array (
      'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
      'Location' => 'https://ssp.hosted.idp/simplesaml/www/saml2/idp/SSOService.php',
    ),
    1 => 
    array (
      'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
      'Location' => 'https://ssp.hosted.idp/simplesaml/www/saml2/idp/SSOService.php',
    ),
  ),
  'SingleLogoutService' => 
  array (
    0 => 
    array (
      'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
      'Location' => 'https://ssp.hosted.idp/simplesaml/www/saml2/idp/SingleLogoutService.php',
    ),
  ),

Your thoughts?

Let me know if there is any other information I can provide you. and many, many thanks! 

Shweta

[Shweta]

Jaime,

Do you have any suggestions for the email below?

[Jaime Perez Crespo]

Hi Shweta,

On 18 May 2017, at 17:09 PM, Shweta <shweta...@gmail.com> wrote:
> Jaime,
>
> <Sorry for the empty post earlier,, clicked too soon>
>
> We will schedule to upgrade as soon as we can. Typical steps would be to make a backup of the complete simplesaml directory, then apply and upgrade OR start from a fresh install and apply config/changes ?

That’s entirely up to you. Of course, having backups that you can restore if things go wrong is always advisable, but the process you follow is your decision.

> Notable modifications we have:
> • custom module/theme for overriding certain pages like logout - modules/mymodule/theme/mytheme/default/logout.php

If it’s a module, it’s not a problem. Just copy it over or install it again with composer if that’s possible.

> • Hacky but, in-place code change in this file for overriding UI for discovery service: simplesaml/modules/saml/www/disco.php

There shouldn’t be any reason to modify existing code in order to change the user interface. I would advise you to do this properly in your theme and get rid of the code modifications, because this makes it more difficult for you to upgrade. That’s precisely why you shouldn’t modify third-party code yourself.

> • Metadata auto refresh

The cron job should keep working fine, and the target dir where it drops metadata should be independent of SSP’s installation, so no need to worry about this.

> • Bridged implementation, obviously

I don’t know what you mean by this, sorry.

> If you could recommend the right way to upgrade from 1.13, it would be helpful.

1. Create your own themes and extensions into your own modules.
2. Make those modules installable with composer.
3. Move your configuration files and metadata files out of the SimpleSAMLphp installation directory.
4. Update always to the latest stable version as soon as possible, reading the upgrade notes first.

> For the current problem at hand, the remote SP, has the following in their metadata. They seem to want the SSP IDP to have a similar endpoint configured with HTTP-POST binding(?). I guess my confusion arises from not having seen a config file with SLO endpoint with HTTP-POST binding for an SSP IdP. They need to load our IdP metadata on the SP-- obviously and are having issues setting it up with the absence of this binding.
> I've seen it for Shibboleth IdPs metadata.

https://simplesamlphp.org/docs/stable/simplesamlphp-reference-idp-hosted#section_2

“SingleSignOnServiceBinding” and “SingleLogoutServiceBinding"

> This is the snippet from the vendor metadata (remote SP)
> 'SingleLogoutService' =>
> array (
> 0 =>
> array (
> 'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
> 'Location' => '
> https://remote.sp/wg/saml/SingleLogout/index.html
> ',
> ),
> ),

As far as I understand, they need that in your IdP metadata, while this is the SP metadata you have configured in your IdP.

> This is a snippet of IdP's metadata, with only HTTP-Redirect binding for logout. According to my understanding, the remote SP, should be sending the user to this logout url (like other SPs are doing..) and the logout for IDP and SP is handled.
> https://ssp.proxy.idp/simplesaml/www/module.php/core/authenticate.php?as=default-sp&logout

No. If any SP is doing that, they are doing it wrong. Logout messages should always be sent to the SingleLogoutService URL (saml2/idp/SingleLogoutService.php).

> 'SingleSignOnService' =>
> array (
> 0 =>
> array (
> 'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
> 'Location' => '
> https://ssp.hosted.idp/simplesaml/www/saml2/idp/SSOService.php

Note that the “www” shouldn’t be there. The documentation explicitly tells you that you should configure an alias in your web server to point to the “www” directory, in order to avoid the whole SimpleSAMLphp installation directory to be exposed to the internet, including any possible secrets you may have there (like X509 private keys).