<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
On 2/29/12 2:10 PM, Cantor, Scott wrote:
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383262E2139@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">Is there an out-of-box way to configure multiple URI's as acceptable by this
method?
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
<br>
Yes, that is correct.<br>
<br>
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.<br>
<br>
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:
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<span class="pygments-n">HttpServletRequest#</span>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<span class="pygments-o"></span><span class="pygments-na">getRequestURL</span><span
class="pygments-o">(). 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.<br>
<br>
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.<br>
</span>
</body>
</html>