Shibboleth Developers

["Howard Gilbert" <>]

Let me try this from a different point of view. There are two ways in which
a Resource Manager (and here I want to include user written RMs) can request
a Session based on a particular ApplicationId.

The RequestMap approach operates on factors that are entirely outside the
Web Applications scope of concern: hostname, port, context name, etc. This
is particularly attractive for general purpose RMs that can be configured to
operate over a wide range of applications written to a public API (like
Filters). The problem, however, is that if a single RM can have multiple
Sessions based on different mappings, then the Filter has to continue to
scan and map every request even after a Session has been established on the
chance that a subsequent URL will map to a second applicationId. 

Alternately, we can imagine that a RM would want to choose an ApplicationId
and therefore some Session parameters based on logic that is local to the
application itself. For the sake of the argument, assume that it presents
some pages and asks the user some questions before redirecting the user to
the WAYF. In this design the Configured Application looks good, but it can
be simulated by a Configured Formal Target for the return where the Target
is mapped by a RequestMap table to the desired ApplicationId. Same result
just a more convoluted process.

[When I talked about Vhosts, I was talking about routing the request to a
different application based on hostname and port, as can be done with IIS.
If Tomcat is on a machine named "x" and "y" and has ports "a" and "b" then
//x:a/foo, //x:b/foo, //y:a/foo, and //y:b/foo all go to the same webapp in
Tomcat. In IIS (Sever)every hostname-port combination can be a different
site with a different set of applications and a different meaning for
"/foo". In Tomcat the filter can query the URL and hostname header to see
how it was accessed and make decisions based on them, but it will be basing
those decisions on factors the server did not consider when routing the
request to a particular WAR.]

> I know this won't work. When you get a push, TARGET is probably a URL, or
> perhaps some agreed upon value, but you certainly can't depend on it for
> internal processing in the SP.

I can if the Filter asked the SP to generate the TARGET prior to redirecting
the original request back to the WAYF. I already had most of this worked out
in the current code. The idea is that the RM has decided to request a
Session and has made some parameter decisions such as applicationId. So it
calls the SP (by what passes for the RPC interface) with the data the SP
will need to correctly process the Assertion when it arrives, including a
URL to get back to the RM. The SP sends back a randomly generated one-time
use TARGET-string that identifies the pending session to the SP. The RM
makes this the TARGET value. If the guy never actually logs on, the
incomplete session times out. However, if an Assertion arrives, the TARGET
string is used to find the incomplete Session, the Assertion is added
completing it, a real SessionId is generated as before, and the SP Redirects
the Browser back to the RM using the saved URL.