simplesamlphp / simplesamlphp/simplesamlphp
Option to disable DiscoveryResponse (issue with external Discovery Service)
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 1.1k
- Forks
- 704
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 4
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in modules/saml/src/Auth/Source/SP.php and inspect getHostedMetadata(), along with how discoURL and SP metadata options are read from authsources.php. Compare the proposed approaches and verify the generated SP metadata no longer includes the idp-discovery-protocol DiscoveryResponse when the selected configuration disables it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- authentication
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100