Shibboleth Developers

["Scott Cantor" <>]

> 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. 

Yep. My point is it can be done and has been and (I think I said this a
while back) if there's an API behind which you supply the answer to the RM,
you could stub out an implementation that did in fact not do this
dynamically, but determined it statically based on web.xml or what have you.
Then we *could* implement a RequestMap-based implementation of that API if
we chose to do so later because it was useful to have.

> 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.

Yes, the other point being that I don't like anything that exposes an API to
applications. This is what causes lock-in when in fact I ought to be able to
yank out Shib and plug in CAS (allowing for the fact that I'd lose
attributes) with no changes. But I won't stand in anybody's way if they have
an API they want to support. I just think having a strictly portable,
Shib-agnostic, URL-based way of triggering behavior from within applications
is also important.

> [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.

Ok, I guess I knew that.

Regarding TARGET, my point is that you cannot assume that the flow is
SP->IdP. The IdP can simply push you an assertion with an arbitrary TARGET
value, usually meant as a URL. The spec leaves this open. In practice in
1.3, what I do is look for values I recognize (default or cookie) and
failing that I just assume it's a URL to redirect to afterward.

So if you hook TARGET for your own purposes, it can't be the only mechanism
by which you accomplish that purpose. Showing up at an ACS URL has to be
self-descriptive as to where to go afterward.

-- Scott