metadata EntityDescriptor ID changed after upgrade from 1.18 to 2.1.0

[Maarten Scholl]

Hello,

We just migrated our SP to a new server and also ugraded from 1.18.x to 2.1.0.

We see the metadata has changed. The signing is enabled for the specific idp in the authsources. 

Metadata looks exactly the same, except for:

< <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://xxxx/xxx/module.php/saml/sp/metadata.php/default-sp" ID="_9670782ba1d591f5371d2d35e1efeed97cf9d95018ed8fa70fb0c9a706e19bc1"><ds:Signature>
---
> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://xxxx/xxx/module.php/saml/sp/metadata.php/default-sp" ID="_7f52f67030b1a6e76ada43df6a85f1254efe06937120d6bd6c26aa42b9eba50d"><ds:Signature>

and offcourse by that also the ds:Reference URI later. 
Is there a possibility to keep those the same as before the upgrade? Because i think this will impact the IDP (they would need to update our metadata?)

Kind regards,

Maarten

[Peter Brand]

Maarten Scholl <maa...@jamd.eu> [2023-11-16 13:15 CET]:

> Is there a possibility to keep those the same as before the upgrade?
> Because i think this will impact the IDP (they would need to update our
> metadata?)

This shouldn't affect anything.

-peter

[Maarten Scholl]

Hi Peter,

ok thanks for the quick response. Then i have to look further for the 
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] Backtrace:
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 2 /var/simplesamlphp-2.1.0/src/SimpleSAML/Error/ExceptionHandler.php:32 (SimpleSAML\Error\ExceptionHandler::customExceptionHandler)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 1 /var/simplesamlphp-2.1.0/vendor/symfony/error-handler/ErrorHandler.php:541 (Symfony\Component\ErrorHandler\ErrorHandler::handleException)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 0 [builtin] (N/A)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] Caused by: Exception: Empty SOAP response, check peer certificate.
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] Backtrace:
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 7 /var/simplesamlphp-2.1.0/vendor/simplesamlphp/saml2/src/SAML2/SOAPClient.php:147 (SAML2\SOAPClient::send)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 6 /var/simplesamlphp-2.1.0/vendor/simplesamlphp/saml2/src/SAML2/HTTPArtifact.php:152 (SAML2\HTTPArtifact::receive)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 5 /var/simplesamlphp-2.1.0/modules/saml/src/Controller/ServiceProvider.php:203 (SimpleSAML\Module\saml\Controller\ServiceProvider::assertionConsumerService)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 4 /var/simplesamlphp-2.1.0/vendor/symfony/http-kernel/HttpKernel.php:163 (Symfony\Component\HttpKernel\HttpKernel::handleRaw)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 3 /var/simplesamlphp-2.1.0/vendor/symfony/http-kernel/HttpKernel.php:75 (Symfony\Component\HttpKernel\HttpKernel::handle)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 2 /var/simplesamlphp-2.1.0/vendor/symfony/http-kernel/Kernel.php:202 (Symfony\Component\HttpKernel\Kernel::handle)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 1 /var/simplesamlphp-2.1.0/src/SimpleSAML/Module.php:234 (SimpleSAML\Module::process)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 0 /var/simplesamlphp-2.1.0/public/module.php:17 (N/A)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] Error report with id 43c3ae5b generated.

that happens after authenticating at the IdP.

Any idea perhaps?

Kind regards,

Maarten

Op donderdag 16 november 2023 om 13:26:16 UTC+1 schreef Peter Brand:

[Maarten Scholl]

i already see that if i put in vendor/simplesamlphp/saml2/src/SAML2/SOAPClient.php
 // create ssl context
            $ctxOpts['ssl']['verify_peer'] = true;
            $ctxOpts['ssl']['verify_depth'] = 1;
            $ctxOpts['ssl']['cafile'] = $peerCertFile;

to 

 // create ssl context
            $ctxOpts['ssl']['verify_peer'] = false;
            $ctxOpts['ssl']['verify_depth'] = 1;
            $ctxOpts['ssl']['cafile'] = $peerCertFile;

it works.. trying to add now the idp cert/chain to the trusted ca of the OS.

Kind regards,

Maarten

Op do 16 nov 2023 om 13:42 schreef Maarten Scholl <maa...@jamd.eu>:

--
This is a mailing list for users of SimpleSAMLphp, not a support service. If you are willing to buy commercial support, please take a look here:
 
https://simplesamlphp.org/support
 
Before sending your question, make sure it is related to SimpleSAMLphp, and not your web server's configuration or any other third-party software. This mailing list cannot help with software that uses SimpleSAMLphp, only regarding SimpleSAMLphp itself.
 
Make sure to read the documentation:
 
https://simplesamlphp.org/docs/stable/
 
If you have an issue with SimpleSAMLphp that you cannot resolve and reading the documentation doesn't help, you are more than welcome to ask here for help. Subscribe to the list and send an email with your question. However, you will be expected to comply with some minimum, common sense standards in your questions. Please read this carefully:
 
http://catb.org/~esr/faqs/smart-questions.html
---
You received this message because you are subscribed to a topic in the Google Groups "SimpleSAMLphp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/simplesamlphp/Lms0i1E-7Rw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to simplesamlph...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/simplesamlphp/9df2a006-7824-4605-a367-8ef4737b896fn%40googlegroups.com.

[Peter Brand]

Maarten Scholl <maa...@jamd.eu> [2023-11-16 13:42 CET]:

> ok thanks for the quick response. Then i have to look further for the
> %b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5]
> SimpleSAML\Error\Error: UNHANDLEDEXCEPTION

Well, you could have lead with that. ;)

> Caused by: Exception: Empty SOAP response, check peer certificate.

> Backtrace:

> 7 /var/simplesamlphp-2.1.0/vendor/simplesamlphp/saml2/src/SAML2/SOAPClient.php:147 (SAML2\SOAPClient::send)

> 6 /var/simplesamlphp-2.1.0/vendor/simplesamlphp/saml2/src/SAML2/HTTPArtifact.php:152 (SAML2\HTTPArtifact::receive)

> 5 /var/simplesamlphp-2.1.0/modules/saml/src/Controller/ServiceProvider.php:203 (SimpleSAML\Module\saml\Controller\ServiceProvider::assertionConsumerService)

> 4 /var/simplesamlphp-2.1.0/vendor/symfony/http-kernel/HttpKernel.php:163 (Symfony\Component\HttpKernel\HttpKernel::handleRaw)

> 3 /var/simplesamlphp-2.1.0/vendor/symfony/http-kernel/HttpKernel.php:75 (Symfony\Component\HttpKernel\HttpKernel::handle)

> 2 /var/simplesamlphp-2.1.0/vendor/symfony/http-kernel/Kernel.php:202 (Symfony\Component\HttpKernel\Kernel::handle)

> 1 /var/simplesamlphp-2.1.0/src/SimpleSAML/Module.php:234 (SimpleSAML\Module::process)

> 0 /var/simplesamlphp-2.1.0/public/module.php:17 (N/A)

Is the use of Artifacts on purpose (and why would you do that)?
I know of no reason to use Artifacts today[1].

[1] The only one I remember that may have been useful in the past was
that it's the only SAML Protocol Binding for Responses that doesn't
involve an HTTP POST to the SP and therefore wouldn't cause errors in
the web browser when the SP was running in plain HTTP. Quite obscure
use case and everything should be using TLS today anyway.

> it works.. trying to add now the idp cert/chain to the trusted ca of the OS.

The code as shippped should work, no hacks required.
Also the IDP cert should not be part of the OS-provided trust store,
it should come from SAML Metadata describing that IDP.

Was this all working before and the update from 1.18 to 2.1.0 broke it?

It may well be that Artifact support wasn't tested all that much, it's
virtually unused today AFAIU and was hardly used before.

-peter

[Maarten Scholl]

Hi Peter,

Yes, it for DigiD -> https://www.logius.nl/domeinen/toegang/digid/documentatie/koppelvlakspecificatie-digid-saml-authenticatie

it states (in dutch):

Gebruikte profiles van SAML

Een SAML profile is een specifieke set regels die gebruikt wordt voor een bepaalde use case. DigiD gebruikt twee profiles van de SAML-standaard, te weten:

• Webbrowser SSO profile, met een HTTP Redirect of HTTP Post binding voor het front channel verkeer, en een HTTP Artifact binding voor het back channel verkeer. (Het front channel is de communicatie tussen de dienstaanbieder en DigiD via de browser van de eindgebruiker. Het back channel is de directe communicatie tussen de dienstaanbieder en DigiD).
• Single Logout profile, issued by Session Participant to Identity Provider. Een gedetailleerde uitleg van dit profiel is te vinden in de SAML profiles zoals genoemd onder hoofdstuk Gerelateerde pagina's.

Gebruikte bindings

De DigiD SAML-implementatie maakt gebruik van de volgende bindings:

• SP Initiated: HTTP Redirect binding (Location HTTP header contains SAMLRequest AuthnRequest).
• SP Initiated: HTTP Post binding (HTML form contains SAMLRequest AuthnRequest).
• SP Initiated: HTTP Artifact binding (SOAP Artifact Resolve & Artifact Response) t.b.v. het back channel verkeer (de directe communicatie tussen de dienstaanbieder en DigiD).

Let op: Uit veiligheidsoverwegingen ondersteunt DigiD geen authenticatie Response over een POST binding. Gebruik altijd de HTTP-Artifact binding.

and yes it is still working on 1.18.x as we speak.

Kind regards,
Maarten

Op donderdag 16 november 2023 om 15:03:14 UTC+1 schreef Peter Brand:

[Maarten Scholl]

Hi All,

Well. adding certs to the trusted certs of the OS doesn't help. 
The only thing that works is changing the verify peer to false. But that is indeed not wat we should want.

Any other suggestions to try?

Kind regards,

Maarten

Op donderdag 16 november 2023 om 15:29:22 UTC+1 schreef Maarten Scholl:

[Peter Brand]

Maarten Scholl <maa...@jamd.eu> [2023-11-17 13:13 CET]:

> Any other suggestions to try?

The trust anchor for SAML deployments is SAML Metadata (or rather
SSP's internal PHP representation thereof), not the OS's trust store.
So make sure the metadata for the IDP is complete and correct and the
metadata about your SP you gave to the IDP is complete and correct.

But if you say that this all worked fine with SSP < v2 (i.e., the only
change is the software version) I guess the simple answer is to file a
bug about it stating that upgrading to v2 broke this functionality.
It's not as there were any good reasons to use Artifacts so
essentially noone does. (Of course government types need to do things
differently "because security".)

-peter

[Tim van Dijen]

Hi Peter,

I must disagree with you here, Peter.

Taking away the possibility of leaking sensitive data through a MitM/MitB-attack is a valid reason to perform back-channel token-exchange.

- Tim

Op vrijdag 17 november 2023 om 14:11:00 UTC+1 schreef Peter Brand: