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