PopulateBindingAndEndpointContexts: Unable to resolve outbound message endpoint

[Tom Zeller]

> On Mar 4, 2016, at 3:52 PM, King, David <dsmk at bu.edu> wrote:
> 
> Hi everyone,
>  
> One my SPs has a problem with our soon to be released V3.2.1 IdP but works fine with the old V2.3.3 IdP.  The V3.2.1 IdP process log contains the following when it fails:
>  
> 2016-03-04 21:28:04,329 - DEBUG [org.opensaml.saml.common.binding.impl.DefaultEndpointResolver:126] - Endpoint Resolver org.opensaml.saml.common.binding.impl.DefaultEndpointResolver: Neither candidate endpoint location 'https://trusted.bu.edu/controls/login/AssertionConsumerService.aspx?sid=1759' nor response location 'null' matched 'https://trusted.bu.edu/controls/login/AssertionConsumerService.aspx?sid=1759&gid=1'
> 2016-03-04 21:28:04,329 - DEBUG [org.opensaml.saml.common.binding.AbstractEndpointResolver:130] - Endpoint Resolver org.opensaml.saml.common.binding.impl.DefaultEndpointResolver: No candidate endpoints met criteria
> 2016-03-04 21:28:04,329 - WARN [net.shibboleth.idp.saml.profile.impl.PopulateBindingAndEndpointContexts:404] - Profile Action PopulateBindingAndEndpointContexts: Unable to resolve outbound message endpoint
> 2016-03-04 21:28:04,333 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred while processing the request: EndpointResolutionFailed
> 2016-03-04 21:28:04,333 - DEBUG [org.opensaml.saml.common.profile.logic.DefaultLocalErrorPredicate:154] - No SAMLBindingContext or binding URI available, error must be handled locally
>  
> The SP is located in the InCommon metadata feed (entityId: https://bostonu.imodules.com/sp).  Based on the error above it appears to be a simple SP misconfiguration issue. However, our old V2.3.3 IdP works just fine with this SP.  I double-checked with SAML Tracer that both requests had the same AssertionConsumerService:
>  
> AssertionConsumerServiceURL="https://trusted.bu.edu/controls/login/AssertionConsumerService.aspx?sid=1759&gid=1"
>  
> So my questions are:
>  
> 1)      Is V3.2.1 more strict about this AssertionConsumerService than 2.3.x?  Is the ‘&gid=1’ suffix what is actually causing this problem?

I don’t know about V2, I’d have to look, but in V3 the strings must be equal, so yes to the latter.

> 2)      If so, is there a way to make it less strict so we can accept this inconsistency for this SP until we work it out with them? 

I guess a custom endpoint resolver could be plugged in (probably a bad idea), but perhaps a metadata filter to add the ‘&gid=1’ would work ?