-
Notifications
You must be signed in to change notification settings - Fork 699
Description
Is your feature request related to a problem? Please describe.
Yes.
In short:
SwitchWAYF discovery service trigger issues with this namespace added in SimpleSAMLPhP metadatas as of version 2.4.x:
xmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
<md:Extensions> <idpdisc:DiscoveryResponse xmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://..../simplesaml/module.php/saml/sp/discoResponse/<aut-source-sp>" index="0"/> </md:Extensions>
Details:
The new branch 2.4 of SSP introduced a mandatory endpoint for DiscoveryResponse, this EVEN if the discoURL config in authsources point to an external discovery service.
At Belnet (Belgian NREN), we are making use of SimpleSAMLPhP as SP for some of our services, like FileSender.
Our authsources.php config is set to redirect to an external Discovery Service which is built with the SwitchWAYF:
'discoURL' =>
The discovery service (based on SwitchWAYF) is then providing a list of IdP's members in the Belnet's R&E federation.
We publish our SP (Filesender) metadatas in the Belnet's R&E federation global metadata file using the Metadata SAML URL provided on SP admin module.
The version of SwitchWAYF that we use is incompatible with the sections in the SP metadata of the namespace related to idp-discovery-protocol introduced since version 2.4 .
Describe the solution you'd like
Obtain the construction of the SP metadata without including the namespace related to idp-discovery-protocol
Here are two approaches:
- Disable DiscoveryResponse when using an external discovery service (i.e. when discoURL is configured in authsources.php)
(referred as Method A hereunder)
OR - Disable DiscoveryResponse explicitly through metadata option
(referred as Method B hereunder)
Describe alternatives you've considered
I tested both approaches (method A & method B) with a test instance of our FileSender service, running version 2.4.2 of SimpleSAMLPhP
This was done by modifying the SP metadata construction so that it no longer included any references of the namespace idp-discovery-protocol.
To achieve this, I successfully tested both methods by modifying the file modules/saml/src/Auth/Source/SP.php
- Method A: Disable DiscoveryResponse when using an external discovery service (i.e. when discoURL is configured in authsources.php)
/**
* Retrieve the metadata array of this SP, as a remote IdP would see it.
*
* @return array The metadata array for its use by a remote IdP.
*/
public function getHostedMetadata(): array
{
$entityid = $this->getEntityId();
$metadata = [
'entityid' => $entityid,
'metadata-set' => 'saml20-sp-remote',
'SingleLogoutService' => $this->getSLOEndpoints(),
'AssertionConsumerService' => $this->getACSEndpoints(),
];
// METHOD A: Disable DiscoveryResponse when using an external discovery service
// (i.e. when discoURL is configured in authsources.php)
if (empty($this->metadata->getOptionalString('discoURL', null))) {
$metadata['DiscoveryResponse'] = $this->getDiscoveryResponseEndpoints();
}
...
- Method B: Allow the choice of whether to use the DiscoveryResponse extension. Requires a parameter in authsources.php.
'disable.DiscoveryResponse' => true,
/**
* Retrieve the metadata array of this SP, as a remote IdP would see it.
*
* @return array The metadata array for its use by a remote IdP.
*/
public function getHostedMetadata(): array
{
$entityid = $this->getEntityId();
$metadata = [
'entityid' => $entityid,
'metadata-set' => 'saml20-sp-remote',
'SingleLogoutService' => $this->getSLOEndpoints(),
'AssertionConsumerService' => $this->getACSEndpoints(),
];
// METHOD B: Disable DiscoveryResponse explicitly through a config parameter in authsources.php
if (!($this->metadata->getOptionalBoolean('disable.DiscoveryResponse', false))) {
$metadata['DiscoveryResponse'] = $this->getDiscoveryResponseEndpoints();
}
...
Here is an example of metadata obtained by applying method B.:
Additional context
I have not yet tested with one of the latest versions of SwitchWAYF, but it seems to me that the solution could be either:
-
not overloading the SP metadata with this namespace if an external Discovery Service is used by specifying its URL in authsources.php with “discoURL” => “<url_of_the_remote_DS>/”, (=Method A)
-
allowing sysadmins to enable or disable ‘support for IDP Discovery protocol’ with a configuration parameter (=Method B)
Here is the error we get with SSP >2.4.0 and SwitchWAYF, without the code modification suggested above, after authentication by our IdPs:
Conclusion
Do you agree with any of the suggestions above?
I'll leave it up to you to decide which of my suggestions is the best solution.