Decoded message was not a SAML 1.x Response
Sara Hopkins
sara.hopkins at ed.ac.uk
Wed Apr 25 19:47:17 BST 2012
Hi Scott,
I've been trying to help Hanan with this problem. My understanding from
looking at her logs is that the SP sends a SAML2 request to the IdP,
even though the SAML1 AssertionConsumerService URL has been specified by
means of acsIndex. The IdP then sends back a SAML2 response to the SAML1
AssertionConsumerService URL specified. There isn't an error message in
the log extract that Hanan has included, but I have seen the "Decoded
message was not a SAML 1.x Response" error in her logs in association
with some IdPs.
What I don't understand is how to make the initial request from the SP
be SAML1. I would have thought it should be SAML1, because the SAML1 ACS
URL has been specified. I have wondered if this bug might be involved:
https://bugs.internet2.edu/jira/browse/SSPCPP-227
The SP is an old version so it may be affected by the bug, and equally
acsByIndex may be switched on, but I'm not sure how that works I'm afraid.
Anyway, I have already recommended that Hanan stops using acsIndex, and
promised to do some testing to help her find a better solution.
The SP metadata is correct, and the indices in the metadata match up
with the ones in the config.
Cheers,
Sara
On 24/04/2012 03:42, Cantor, Scott wrote:
> On 4/23/12 10:34 PM, "Hanan Teleb"<hanan.ebraheem at gmail.com> wrote:
>>
>> the SAML version used for that request is SAML1 as I have
>> AssertionConsumerServiceIndex="3" for SAML1 while
>> AssertionConsumerServiceIndex="1" for SAML 2. does the binding protocol
>> in the response should
>> match AssertionConsumerServiceIndex in the AuthnRequest. for this case
>> SAML:2.0:protocol in the response should be SAML:1.0:protocol b/c
>> AssertionConsumerServiceIndex=3 in the request?
>
> Your problem could be that the indexes in your metadata do not match the
> ones the SP is internally using in the configuration. This is not rare,
> and is why we don't use indexes in requests to IdPs. That isn't how it
> works by default. acsByIndex is now off by default, and you would have to
> add that option to flip it from passing the ACS URL in the AuthnRequest by
> index instead of just by full URL.
>
> However, I will say again that your log does not show an error. It's
> showing a 2.0 request and a 2.0 response, and that doesn't show any
> problem that would lead to that error message. If the IdP did send a 2.0
> response to the SP's 1.1 endpoint, that would cause that error.
>
> But it seems likely that your metadata is wrong, and that's the root
> problem, along with setting this option to pass the ACS by index.
>
> If for some reason the IdP requires that, then you would need to get the
> metadata indexes to match the ones the SP knows about internally. That's
> not easy to do, particularly with 2.4+ SPs. But the log will show what
> index it's passing in the AuthnRequest. That has to match the metadata the
> IdP is using as being the index of a SAML 2.0 POST endpoint.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>
--
Sara Hopkins
Support Team
UK Access Management Federation for Education and Research
web: http://www.ukfederation.org.uk/
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
More information about the users
mailing list