Unable to decode incoming request

[Christopher Bongaarts]

This looks suspiciously similar to a case we ran into yesterday; from 
what I gather, whatever SP software the vendor is using consumes SAML 
metadata, but blindly grabs the first SSO endpoint it sees instead of 
the one it plans to use (SAML2 HTTP-Redirect).

On 7/16/2019 10:45 AM, Peter Schober wrote:
> * Ryan Suarez <ryan.suarez at sheridancollege.ca> [2019-07-16 17:33]:
>> POST https://my.idp.ca/idp/profile/Shibboleth/SSO
> That's your endpoint for proprietary "Shibboleth" protocol requests
> under SAML1.
>
>> <saml2p:AuthnRequest
>> Destination="https://my.idp.ca/idp/profile/Shibboleth/SSO"
>> ForceAuthn="false" ID="LI_qd47rn684941iui6hebvqmdqc4"
>> IsPassive="false" IssueInstant="2019-07-16T15:18:29.733Z"
>> ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
>> Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" >
>> <saml2:Issuer
>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://some.sp.com/someEndPoint/ABEAAAAAAAAirCEAAAAAAuNRbAHzAzyYcMFFTC97fZ9C4TfaBxvDtg</saml2:Issuer>
>> <saml2p:NameIDPolicy AllowCreate="true" /> </saml2p:AuthnRequest>
> But the authentication request is using the SAML 2.0 protocol.
> I.e., the SP is configured with the wrong endpoint for your IDP.
>
> -peter

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%