How does AssertionConsumerServiceURL in the SAMLRequest get constructed?

256 views
Skip to first unread message

o haya

unread,
Nov 30, 2020, 9:09:45 AM11/30/20
to simple...@googlegroups.com
Hi,

I am new here and just started working with SimpleSamlPhp.

We are using SimpleSamlPHP to construct and send requests to our IdP.  We are using Oracle OAM as IdP.

However, in our IdP logs, we are seeing an error:

"The AssertionConsumerServiceURL found in the authentication request message cannot be validated.
oracle.security.fed.event.EventException: The AssertionConsumerServiceURL found in the AuthnRequest message could not be validated: either the message has to be signed, or the URL needs to be one of the AssertionConsumerService Location defined in the metadata"

In the SimpleSamlPHP logs, we can see the request, but we are not able to figure out how that AccessConsumerServiceURL that is in the request is being constructed by SimpleSamlPHP:

- It is not the value of the AssertionConsumerService parameter in the authsources.php file
- It is not the value of the Location parameter in the saml20-idp-remote.php file

The best we can tell, SimpleSamlPHP must be somehow constructing that AssertionConsumerServiceURL value in the SAMLRequest from pieces of information, but can someone explain exactly how it does that?

Thanks,
Jim

Peter Schober

unread,
Nov 30, 2020, 9:29:24 AM11/30/20
to simple...@googlegroups.com
* o haya <ohay...@gmail.com> [2020-11-30 15:09]:
> The best we can tell, SimpleSamlPHP must be somehow constructing
> that AssertionConsumerServiceURL value in the SAMLRequest from
> pieces of information, but can someone explain exactly how it does
> that?

While people here may be able to explain how the implementation works
that may not be the best way forward.

> However, in our IdP logs, we are seeing an error:
>
> "The AssertionConsumerServiceURL found in the authentication request
> message cannot be validated.
> oracle.security.fed.event.EventException: The AssertionConsumerServiceURL
> found in the AuthnRequest message could not be validated: either the
> message has to be signed, or the URL needs to be one of the
> AssertionConsumerService Location defined in the metadata"

As an error cause "either the message has to be signed" is weird since
the IDP would have to know with certainty whether (a) itself imposes
such a requirement on the SP or (b) the SP claims it signs its
authentication requests via SAML 2.0 Metadata.
FWIW, unless you're doing something fancy in the authn request such as
setting forcedAuthn you shouldn't sign them and consequently the SP's
metadata shouldn't claim that those will be signed.

And whether the ACS URL from the authn request matches the SP's
metadata (or not) should be clear to IDP, too. And you can easily
determine that yourself: Just look at the SAML authn request in
transit using the SAMLtracer browser extension. Look at the ACS URL
the SP requested that the assertion should be returned to by the IDP.

Then look at the SAML 2.0 Metadata for the SP you gave to the IDP (or
the SP's ACS URL you provisioned into the IDP manually) and see
whether the ACS URL matches.

> The best we can tell, SimpleSamlPHP must be somehow constructing
> that AssertionConsumerServiceURL value in the SAMLRequest from
> pieces of information, but can someone explain exactly how it does
> that?

Look at the beginning of your config/config.php (base url).
Also check your SimpleSAMLphp admin UI, e.g. the tab about metadata.

-peter

o haya

unread,
Nov 30, 2020, 10:43:15 AM11/30/20
to SimpleSAMLphp
Hi Peter,

I think I was able to get past that problem.  The problem was that in the Oracle OAM logs, it was showing the URL coming in (in the request) with an IP address in it, rather than a hostname.  I couldn't see where we had specified an IP address, so I was "guessing" that SimpleSAMLPhp was somehow "constructing" that URL.

As it turns out, it looks like it SimpleSamlPHP was getting the IP from the URL that we were using to access the SimpleSamlPHP web app!!!!  I changed to using the hostname in the URL and then the IP address was gone from the ACS URL (and I was able to get past the URL mismatch)!!!

Now I am on the problem and will post a new message about that.

Thanks,
Jim

o haya

unread,
Nov 30, 2020, 10:46:27 AM11/30/20
to simple...@googlegroups.com
I messed up the last line.  Instead of:

" Now I am on the problem and will post a new message about that."

I meant to say:

"Now, I am on TO the NEXT problem, and will post a new message about that."


--
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/G8CS0Jwq2Ig/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/6e01734c-be7b-4319-b580-8ddcdbbd0044n%40googlegroups.com.

Peter Schober

unread,
Nov 30, 2020, 11:15:43 AM11/30/20
to SimpleSAMLphp
* o haya <ohay...@gmail.com> [2020-11-30 16:43]:
> As it turns out, it looks like it SimpleSamlPHP was getting the IP
> from the URL that we were using to access the SimpleSamlPHP web app!

For SAML SPs I strongly recommend to canonicalize any and all URLs
leading to the application in the webserver, e.g. HTTP vs HTTPS,
"www.example.org" vs. "example.org", etc.pp., that also helps avoid
other problems down the road.

And (as I said before) by setting the base url parameter in your config.

And (as I often say on this list) by setting the entity's own entityID
value to a static string of your choice. Otherwise SSP will likewise
dynamically generate what it thinks its own name is.
(Besides the auto-generated entityID values being incredibly long, e.g.:
111 https://stonybrookuniversity.co1.qualtrics.com/WRSAML/simplesaml/www/module.php/saml/sp/metadata.php/default-sp
108 https://saml.hrperformancesolutions.net/simplesaml/module.php/saml/sp/metadata.php/The-Ohio-State-University
106 https://edugain-demo-sp.moonshot.utr.surfcloud.nl/simplesamlphp/module.php/saml/sp/metadata.php/default-sp
and so on.)

-peter
Reply all
Reply to author
Forward
0 new messages