Decoded message was not a SAML 1.x Response

[Cantor, Scott]

On 4/25/12 2:47 PM, "Sara Hopkins" <sara.hopkins at ed.ac.uk> wrote:
>
>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.

Yes, I would assume that's the problem.

>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

Possibly. The bug, I think, was that specifying an index doesn't drive any
logic related to which protocol gets used. If you pass acsIndex to it, it
only uses the index inside the various handlers once it's decided to try
to use a protocol. And before the bug fix, it would just pass the index
blindly at that point, and if the protocols don't match, it failed at the
end, which was the worst time to fail.

But you have no control over which protocol is used other than metadata
and the order of the chain of handlers. If SAML2 is first and the IdP
supports SAML2, you get an error if the index was a SAML 1 endpoint. If
you want to use SAML 1 only, you have to take out the SAML2 initiator.

>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.

Going that far back, I believe acsByIndex either defaulted to true or was
in the config by default or both. That turned out to cause a ton of
problems and I made the one change I've made in the history of this
release branch that actually changed a default, and switched the default
to false. (As well as taking it out of the config going forward.)

>Anyway, I have already recommended that Hanan stops using acsIndex, and
>promised to do some testing to help her find a better solution.

Not using acsIndex is by far the best choice, as is, obviously, upgrading
the SP.

If this isn't running an old release, then I don't understand how it's
happening if the metadata matches. On a 2.4 SP, you could use the indexes,
and if the ACS selected was of the wrong protocol, it would back off to
selecting a default ACS for that protocol. In other words, it tries to do
what you tell it, but if that fails, it trys to get the request issued
with something that will work based on what it knows. Minimizing failure,
but not necessarily getting it to use the binding intended.

-- Scott