Adding additional AssertionConsumerServices to the metadata

[Thomas Zangerl]

Hi simplesamlphp developers,

 

a use case we have stumbled upon during the last two weeks was that we would need to add additional AssertionConsumerService endpoints to the metadata of a simplesaml ServiceProvider. So, actually the reversion of the use case detailed in [1]. That is, because we make the same simplesamlphp entity accessible from different vhosts, leading to different AssertionConsumerServices.

 

Until now we just let simplesamlphp autogenerate the ACS endpoints, which resulted in metadata with different ACS endpoints but the same entityID on different vhosts. Compare [2] and [3], they have the same entityID in their metadata but different ACS endpoints, due to the way in which simplesamlphp generates the metadata.

 

This causes trouble for some federations and their metadata management procedures. What we'd like to have instead is one authorative metadata that can be imported, with the additional ACSes and SLOServices from the additional service vhosts added.

 

This is why I made a tentative patch (see attachment) that parses additional ACSes from the SP section of authsources.php.

 

I tried to stick to the format conventions introduced in format 3 of the simplesamlphp metadata [4]. Additional ACSes are configured by adding an array like the following to the SP section of authsources.php

 

'acs' => array(
                       array('Location' => 'https://sp-mirror1.example.com/acs',
                              'Binding'  => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST'),
                       array('Location' => ...,
                              'Binding' => ...)),

This adds the two ACS entries both to the XML metadata as well as the simplesamlphp metadata generated in metadata.php.

If the acs configuration entry is empty ('acs' => array()), then, for the simplesaml metadata, configuration format 1 (according to [4]) will be used, otherwise configuration format 3.

 

Now my question is: Is this patch something that could go into simplesamlphp?* Or do you see a better way of solving the problem?

 

Thanks,

/Thomas

 

* In this case I will create a similar patch for having multiple SingleLogoutService endpoints.

 

[1] http://groups.google.com/group/simplesamlphp/browse_thread/thread/42f37ec7335038dd/720a79f3146f678a

[2] https://tcs-escience.sunet.se/simplesamlphp/module.php/saml/sp/metadata.php/default-sp?output=xhtml

[3] https://tcs-escience-portal.terena.org/simplesamlphp/module.php/saml/sp/metadata.php/default-sp?output=xhtml

[4] http://simplesamlphp.org/docs/1.6/simplesamlphp-metadata-endpoints

freenetMail - Der zuverlässige E-Mail-Dienst von freenet.de
Jetzt kostenlose E-Mail-Adresse mit 1 GB Speicher und Profi-Spamschutz sichern!
Sofort anmelden!

[Olav Morken]

On Fri, Aug 06, 2010 at 19:34:15 +0200, Thomas Zangerl wrote:
> Hi simplesamlphp developers,
>  
> a use case we have stumbled upon during the last two weeks was that we would need to add additional AssertionConsumerService endpoints to the metadata of a simplesaml ServiceProvider. So, actually the reversion of the use case detailed in [1]. That is, because we make the same simplesamlphp entity accessible from different vhosts, leading to different AssertionConsumerServices.
>  
> Until now we just let simplesamlphp autogenerate the ACS endpoints, which resulted in metadata with different ACS endpoints but the same entityID on different vhosts. Compare [2] and [3], they have the same entityID in their metadata but different ACS endpoints, due to the way in which simplesamlphp generates the metadata.
>  
> This causes trouble for some federations and their metadata management procedures. What we'd like to have instead is one authorative metadata that can be imported, with the additional ACSes and SLOServices from the additional service vhosts added.
>  
> This is why I made a tentative patch (see attachment) that parses additional ACSes from the SP section of authsources.php.
>  
> I tried to stick to the format conventions introduced in format 3 of the simplesamlphp metadata [4]. Additional ACSes are configured by adding an array like the following to the SP section of authsources.php
>  
> 'acs' => array(
>                        array('Location' => 'https://sp-mirror1.example.com/acs',
>                               'Binding'  => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST'),
>                        array('Location' => ...,
>                               'Binding' => ...)),
> This adds the two ACS entries both to the XML metadata as well as the simplesamlphp metadata generated in metadata.php.
> If the acs configuration entry is empty ('acs' => array()), then, for the simplesaml metadata, configuration format 1 (according to [4]) will be used, otherwise configuration format 3.
>  
> Now my question is: Is this patch something that could go into simplesamlphp?* Or do you see a better way of solving the problem?

No, I don't think this is something that we want to officially support
in simpleSAMLphp. The reason for this is that this is not the way that
the SAML 2 standard is supposed to be used, and you cannot reliably
integrate it with logout (at least not with the current logout
implementation).

An IdP will only send logout requests to one of the
SingleLogoutService endpoints of an SP. Also, if an SP sends a logout
request to the IdP, the IdP will not know which logout endpoint it
should send the response to.

If the virtualhosts are on a common domain, you may be able to make
this work by tweaking the cookie settings, so that all the virtualhosts
share a single simpleSAMLphp session. Otherwise, I would suggest that
you look at creating multiple SPs (with multiple entityIDs).

Regards,
Olav Morken
UNINETT / Feide

[Thomas Zangerl]

Olav,

thanks for your fast response!

>
> No, I don't think this is something that we want to officially support
> in simpleSAMLphp. The reason for this is that this is not the way that
> the SAML 2 standard is supposed to be used,

Can you maybe explain why? I see the argument with the
SingleLogoutService
(though this could still be solved by matching the domain names and
picking the
right one in ssp), but according to the SAML2 documents I have read it
should
be legal to specify multiple endpoints. The SAML2-metadata [1]
specification makes
no stipulations about the domains of the ACS endpoints.

Thanks,
Thomas

[1] http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

[Olav Morken]

On Mon, Aug 09, 2010 at 01:54:09 -0700, Thomas Zangerl wrote:
> Olav,
>
> thanks for your fast response!
>
> >
> > No, I don't think this is something that we want to officially support
> > in simpleSAMLphp. The reason for this is that this is not the way that
> > the SAML 2 standard is supposed to be used,
>
> Can you maybe explain why? I see the argument with the
> SingleLogoutService
> (though this could still be solved by matching the domain names and
> picking the
> right one in ssp), but according to the SAML2 documents I have read it
> should
> be legal to specify multiple endpoints. The SAML2-metadata [1]
> specification makes
> no stipulations about the domains of the ACS endpoints.

I'm sorry, I should have been clearer. I was thinking of this patch in
combination with the possible future patch for SingleLogoutService that
you hinted on in your original mail.

The SAML 2 standard assumes that a single SAML 2 "entity" has a common
state, and that it doesn't matter where logout requests are sent. This
also applies to other protocols, such as the NameID management protocol.

It is possible create an SP that shares a state between multiple
hosts, and such an SP could easily support the behaviour you wish, but
I don't think it is appropriate for SSP.