Internal SP Using HTTP-Redirect instead of HTTP-POST

Brent Putman putmanb at
Thu May 23 18:59:01 EDT 2019

On 5/23/19 6:37 PM, Garmer, Jack - garmercj wrote:
> We’re attempting to authenticate against our development idp
> environment, In the shibd.log on the SP
> side, we’re seeing this:
> 2019-05-23 18:26:38 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [2]
> [default]: marshalled message:
> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> AssertionConsumerServiceURL=""
> Destination=
> ID="_1648fa9b7458e5bb02050562e7902c54"
> IssueInstant="2019-05-23T22:26:38Z"
> ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
> Version="2.0"><saml:Issuer
> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"></saml:Issuer><samlp:NameIDPolicy
> AllowCreate="1"/></samlp:AuthnRequest>

Read on, but look closely at the AssertionConsumerServiceURL value...

> On the idp side, we see this:
> DEBUG Endpoint Resolver
> org.opensaml.saml.common.binding.impl.DefaultEndpointResolver: Neither
> candidate endpoint location
> '' nor response
> location 'null' matched
> ''

You have mismatch in the URLs there. 
https://*it-itsmapi*   !=

Note presence of "it-" in the former vs absence in the latter.  That's
your problem.

The other stuff about Redirect vs POST is a misunderstanding.  The SP is
sending the AuthnRequest to the IdP via Redirect and that's fine.  And
generally preferred.  The Shib SP will prefer sending the request over
Redirect unless you specifically configure otherwise, or the IdP
indicates in its SingleSignOnService metadata that it doesn't support
Redirect (which would generally be highly unusual).

> It appears the SP is sending requests to HTTP-Redirect on our idp and
> I can’t figure out why. The metadata on both instruct HTTP-POST as the
> primary protocol:
> SP:
>                 <md:AssertionConsumerService
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
> Location=""
> index="0" isdefault="true"/>

That's indicating where and how the SP wants the **response** sent
(which has nothing to do with where and how the IdP wants the request
sent).  It's the mismatch between this and what's in the AuthnRequest
AssertionConsumerServiceURL that is causing the mismatch here in the
endpoint evaluation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list