Using artifact binding with simplesamlphp SP and IdP

[mark chater]

Dear all,

I am trying to get artifact resolution working between an SP and IDP both using simplesamlphp 2.3.5.  The SP and IDP are able to correctly complete single sign on using HTTP_REDIRECT.  For information, though I don't think it's relevant, the IDP is using memcached as its store, the SP sql. Excerpts from the various configuration files are given at the end. This question is unfortunately quite long as I have attempted to include everything relevant.

Firstly (and not the main issue) I cannot get the metadata on the IDP through the Federation page when logged in to the simplesaml admin page, nor from the metadata URL.  Configuration.php function getDefaultBinding throws a "Missing default binding for ArtifactResolutionService" in saml20-idp-hosted exception.  I added

    case 'saml20-idp-hosted:ArtifactResolutionService':
        return BINDING_SOAP;

to the switch in function getDefaultBinding which least allowed metadata the SP needs to be generated.  Changing the binding it returns does not affect the following problem.

There is a post on google groups about the metadata generation problem here https://groups.google.com/g/simplesamlphp/c/7FGqWUsnp2I but it concludes with an "everything works fine" once they got the artifact resolution endpoint from the idp. In my case it doesn't.

So, with the metadata exchanged, when I attempt to initiate a signon at the SP, either from my test page that calls requireAuth or when logged in to the simplesaml admin interface on the SP and using its Test page, I get an exception that it "Could not find a supported SingleSignOnService endpoint." from Configuration.php (SimpleSAML\Configuration::getDefaultEndpoint) on the SP. The IDP is never reached.

This seems to be because the SP authsources.php contains (per the documentation page "Using HTTP-Artifact from a SimpleSAMLphp SP") the following line

'ProtocolBinding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact',

for this SP configuration, but saml20-idp-remote.php on the SP has

    'SingleSignOnService' => [
        [
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
            'Location' => 'https://artifiacttest.idplocal.example/saml20idp/module.php/saml/idp/singleSignOnService',
        ],
    ],


for the artifact test idp.  This comes from the metadata published by the idp, where 'saml20.sendartifact' => true is configured in the relevant section of the saml20-idp-hosted file.  All this is per the documentation on configuring artifact on simplesamlphp running as SP or IDP as appropriate.

Digging into it a bit more, it looks like getDefaultEndpoint in Configuration.php can't find an endpoint based on the following input

 $endpoints is an array containing:

 [Binding] => urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect          
 [Location] => https://artifiacttest.idplocal.example/saml20idp/module.php/saml/idp/singleSignOnService

 $bindings is an array containing:
 [0] => urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact


As an aside, if I change the binding in (SP) saml20-idp-remote.php from HTTP-Redirect to HTTP-Artifact then the exception is not generated and a request is sent to module.php/saml/idp/singleSignOnService at the idp, passing a SAMLart variable, rather than the expected SAMLRequest variable. This is also wrong as the IdP (as far as I can tell) then thinks it is an SP receiving an artifact and tries to find the required remote IDP to call its artifact resolution service, which it clearly can't.

I am now stuck and would be grateful if anyone can offer any insight.


Here are excepts from the relevant configuration files

On the SP authsources.php contains
$config['artifacttest'] = [
    'saml:SP',
    'entityID' => 'https://artifacttest.splocal.example',
    'idp' => 'artifacttestIdp',
    'ProtocolBinding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact',
];

On the SP saml20-idp-remote.php contains (these are copied and pasted from the idp admin interface)

$metadata['artifiacttestIdp'] = [
    'metadata-set' => 'saml20-idp-hosted',
    'entityid' => 'artifiacttest',
    'SingleSignOnService' => [
        [
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
            'Location' => 'https://artifiacttest.idplocal.example/saml20idp/module.php/saml/idp/singleSignOnService',
        ],
    ],
    'SingleLogoutService' => [
        [
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
            'Location' => 'https://artifiacttest.idplocal.example/saml20idp/module.php/saml/idp/singleLogout',
        ],
    ],
    'NameIDFormat' => [
        'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
    ],
    'ArtifactResolutionService' => [
        [
            'index' => 0,
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:SOAP',
            'Location' => 'https://idplocal.example/saml20idp/module.php/saml/idp/artifactResolutionService',
        ],
    ],
    'contacts' => [
        [
            'emailAddress' => 'sup...@example.com',
            'givenName' => 'Administrator',
            'contactType' => 'technical',
        ],
    ],
    'certData' => 'snipped',
];

On the IDP saml20-idp-hosted.php contains

$metadata['artifacttestIdp'] = [
    'host' => 'artifiacttest.idplocal.example',

    'privatekey' => 'artifiacttest.idplocal.example.key',
    'certificate' => 'artifiacttest.idplocal.example.pem',

    'auth' => 'example-userpass',
    'saml20.sendartifact' => true,

];

On the IDP saml20-sp-remote.php (copied and pasted from the SP admin interface)

$metadata['https://artifacttest.splocal.example'] = [
    'SingleLogoutService' => [
        [
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
            'Location' => 'https://splocal.example/saml20sp/module.php/saml/sp/saml2-logout.php/artifacttest',
        ],
    ],
    'AssertionConsumerService' => [
        [
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
            'Location' => 'https://splocal.example/saml20sp/module.php/saml/sp/saml2-acs.php/artifacttest',
            'index' => 0,
        ],
        [
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact',
            'Location' => 'https://splocal.example/saml20sp/module.php/saml/sp/saml2-acs.php/artifacttest',
            'index' => 1,
        ],
    ],
    'certData' => 'snipped',
];

Regards,

Mark

[monk...@gmail.com]

Hi,

  I am still getting up to speed on the Artifact binding and code using it. Some of this message may be quite strange as it is just exploratory configuration to see how things change.

  I have been looking at setting up an sspsmall instance using Artifact for testing. This gives me an SP and IdP on a local machine both using the same SimpleSAMLphp version.

  I can get beyond the initial issue of not finding a binding by adding an HTTP-Artifact using the same single sign on Location. This gives a saml20-idp-remote.php as follows:

    'SingleSignOnService' => [
        [
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',

            'Location' => 'https://localhost/sspsmall/module.php/saml/idp/singleSignOnService',

        ],
        [
            'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact',

            'Location' => 'https://localhost/sspsmall/module.php/saml/idp/singleSignOnService',
        ],
    ],

With that in place trying to login using the admin/test interface I see a GET request to the IdP

GET https://localhost/sspsmall/module.php/saml/idp/singleSignOnService?SAMLart=AAQ...admin%2Ftest%2Fdefault-sp

I see in the logs here the following message:
No metadata found for remote provider with SHA1 ID: '...'

Perhaps this is because the IdP does not know where to send the ArtifactResolve message because I only have a partial configuration.

My next step will be trying to tell the IdP about the remote provider so it can try to talk to the SP and see what
message it then intends to send off.

I will be AFK for a few days due to matters beyond my control but will return to investigating this. 

I will also look for an exact SAML Trace of a working login to try to make a configuration that can match that flow.

I am using a mix of SAML Tracer, the specs (saml-bindings-2.0-os.pdf), and digging into the code and trying out some configurations to see what happens at the moment.

[Peter Schober]

mark chater <markr...@gmail.com> [2025-02-28 18:24 CET]:

> I am trying to get artifact resolution working between an SP and IDP
> both using simplesamlphp

Why are you trying to do that? Given the state of support for
Artifacts in SAML implementations I cannot imagine this being used for
any real deployments/integrations?

Esp. if you control both the IDP and the SP and both are SimpleSAMLphp
why would you want to use use Artifacts between them when much
simpler, easier to debug and more widely supported bindings are
available?

-peter

[Tim van Dijen]

Because it is a valid mitigation against MitB-attacks..

Op donderdag 6 maart 2025 om 10:34:10 UTC+1 schreef Peter Schober:

[Peter Schober]

Tim van Dijen <tvd...@gmail.com> [2025-03-06 11:04 CET]:

> Because it is a valid mitigation against MitB-attacks..

When all data is end-to-end encrypted and signed how does MitB matter
(assuming WebSSO using HTT-POST)? I.e., what's to gain from unreadable
cipherdata in the browser?
And replacing the data with other data would fail the signature
validation at the SP (since the MitB cannot sign its data with the
impersonated IDP's key) so no way to inject other data either?

More fundamantally, even if SAML 2.0 WebSSO with E2EE was "insecure"
today people wouldn't be moving to SAML 2.0 w/ Artifacts then, they'd
move to OIDC. So I still don't see the point of this excersise, tbh.

That's not to mean people shouldn't make sure what's supposed to work
in SimpleSAMLphp does in fact work and is properly documented.
So don't let the above distract anyone. ;)
-peter

[mark chater]

On Thursday, 6 March 2025 at 08:56:43 UTC monk...@gmail.com wrote:

With that in place trying to login using the admin/test interface I see a GET request to the IdP

GET https://localhost/sspsmall/module.php/saml/idp/singleSignOnService?SAMLart=AAQ...admin%2Ftest%2Fdefault-sp

I see in the logs here the following message:
No metadata found for remote provider with SHA1 ID: '...'

Perhaps this is because the IdP does not know where to send the ArtifactResolve message because I only have a partial configuration.

Thanks for looking at this and it appears you've got to the same place I did before I went on leave last week. My hypothesis is that since the GET request arriving at the IdP contains a SAMLart variable, the receiving IdP thinks it has received an artifact returned from another IdP from a successful authentication, and tries to work out which IdP to call its artifact resolution service. Since this isn't what's happening and the IdP won't have a remote IdP configured, this fails with the no metadata found error that we both have seen.

Normally the SP sends a SAMLRequest variable containing the encoded SAML request initially, and my understanding is that the artifact first comes back to the SP from the IdP once the user is logged on at the IdP.  Since I've not seen a working artifact authentication I can't confirm that from experience though.

Mark

[monk...@gmail.com]

Hi,

  I started narrowing this down. It seems that the following block causes an issue. If you comment this out then the initial request uses a normal redirect to the IdP. That AuthnRequest will have the ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" attribute set (assuming the SP is setup with the right config) and thus trigger artifact binding for the response.

Comment the "elseif ($ar->getProtocolBinding() === Constants::BINDING_HTTP_ARTIFACT)" block.

https://github.com/simplesamlphp/simplesamlphp/blob/1b7a36d9e39eea02a57ab2be71a4cd5d2f1f9eeb/modules/saml/src/Auth/Source/SP.php#L646

This causes the AuthnRequest to be delivered normally but with the artifact attribute. The successful SAML login will see a GET with an art and in the samltracer you don't get to see the response because it is happening in the background between the SP and IdP.

GET https://FQDN/sspsmall/module.php/saml/sp/saml2-acs.php/default-sp?SAMLart=AAQ

[mark chater]

Sorry for the delay in replying, but I've now been able to look at this again and can confirm your suggested change works.  The SP redirects to the IdP which sends back an artifact and the SP then makes a server-side call to the IdP ArtifactResolutionService like it's supposed to.

I had a bit of trouble with peer certificate verification but this [ https://github.com/simplesamlphp/saml2/issues/309 ] on the github put me on the right track and I have everything working like it should in my test environment.

Many thanks for your help.

Mark

--
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/9CSS62Z1tjY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to simplesamlph...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/simplesamlphp/c545b12d-507e-448f-b71b-d3fd9002cb12n%40googlegroups.com.