PopulateBindingAndEndpointContexts: Unable to resolve outbound message endpoint

[King, David]

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?



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?



3)      Am I correct that the parameter skipEndpointValidationWhenSigned  would not help in this situation?  I do see a message that "protocol message signature succeeded" earlier in the request.

Thanks in advance for the help,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160304/e6653914/attachment.html>