BaseSAMLMessageDecoder.checkEndpointURI

[Zmuda, Matthew R]

Thanks for the response.
The Authentication Request is sent to use at one URI that is intercepted and changed for load balancing.

For example say AuthNRequest comes in at

https://my.domain.com//profile/SecureProtocol2/Redirect/SSO<https://my.domain.com/profile/SecureProtocol2/Redirect/SSO>

I want to route this request to
https://my.domain.test1.com//profile/SAML2/Redirect/SSO
or
https://my.domain.test2.com//profile/SAML2/Redirect/SSO

So at the time this check is executed it throws exception since the Destination URL does not match current URL.
________________________________
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Brent Putman
Sent: Thursday, March 01, 2012 1:06 PM
To: users at shibboleth.net
Subject: Re: BaseSAMLMessageDecoder.checkEndpointURI



On 2/29/12 2:10 PM, Cantor, Scott wrote:

Is there an out-of-box way to configure multiple URI's as acceptable by this

method?



If that's the method that checks the Destination attribute of a message, there isn't even a specification-appropriate way, it's a required check.


Yes, that is correct.

To the OP: I'm not sure what you even mean by multiple URI's here.  This check compares the one sent in the Destination of the protocol message with the actual endpoint on which the message was received.  There can't really be multiple values of either of those.

Perhaps you can explain more of the problem that you are trying to solve.  The usual problem is that the message receipt endpoint is not calculated correctly, when things like reverse proxy from Apache via AJP are used.  In the decoder this URI is calculated simply as the value of:  HttpServletRequest# getRequestURL().  So that has to be right.  For Tomcat I believe that they have some attributes you can set on the AJP connector to determine this.  For the general case, I think you can also solve via a servlet Filter that introduces a wrapped HttpServletRequest and overrides the value.

If the problem is the message Destination value, that's likely just a mismatch between your metadata and the IdP deployment, so that the location to which the SP is choosing to send the request is simply not the right one.

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. If received in error, please go to www.td.com/legal for instructions.
AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. Si reçu par erreur, prière d'aller au www.td.com/francais/avis_juridique pour des instructions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120301/bfd95139/attachment.html