Shibboleth Developers

["Scott Cantor" <>]

I'd be lying if I claimed to understand most of that, and since I designed
the original examplar, I doubt anybody else could understand it either.

But I see some problems...

> elements to do the RequestMap are available. However, while 
> "virtual host" and port are major structural design feature 
> of other Web Server configurations, Tomcat has a few 
> configuration elements for them but largely ignores them and 
> does no URL mapping based on them.

If this is true, Tomcat is broken, or I don't understand something. Vhosting
is a critical thing and is the only way to isolate applications on a single
web server from the client's point of view. It has to be fully supported. It
also has to be supported because of load balancing. People need to be able
to tell Tomcat to pretend it lives on http/portX even if the client sees
https/portY. This has been well covered on the list. And I do know Tomcat
supports that in the http connector, although I think there are bugs, as
there are with Apache.

So maybe I'm just not understanding what you mean by "URL mapping".

> The examples of multiple-applicationId configurations seemed 
> to suggest alternate Attributes for different levels of 
> access. However, two Application elements each with their own 
> Metadata are also (and maybe more likely to be) used in 
> multiple-Federation scenarios.

I see this as very unlikely, especially with 1.3+. There's no reason to use
multiple applications to expose a single service to multiple IdPs, no matter
what the federation arrangement is.

The purpose is what it originally was, to assign various configuration
options, including session lifetimes, error handling, etc. on a per-request
basis by bucketing requests into logical applications. Mostly this is useful
when vhosting multiple services, and I don't think it's a huge problem if
the Java SP only supported dividing up content on a per-web context,
per-vhost basis, though I don't see why that restriction is necessary.
 
> Meanwhile, a Servlet Filter has its own configuration and 
> init-param values from the web.xml file in the application. 

This has serious pluses and minuses, but given that the applications are
already non-portable and only work in a Java container, it's probably got
less minuses than what I was facing in Apache.

> If you insist on the RequestMap algorithm, then it can draw 
> very fine distinctions based on things that Java (or at least 
> Tomcat) regards as irrelevant. In particular, when Tomcat 
> runs on a machine with more than one hostname, and exposed 
> more than one port, it will always route requests to a 
> subsequent path string to the same filter.

If so, somebody screwed up designing Java filters, that's crazy if the
intent is that filters could be multiply configured. Vhosting seems like the
number one reason you'd do it. To me that argues for using the RequestMap as
an option to completely replace what the container is doing to configure
requests.

> This means that a 
> Filter can get a sequence of requests, even from the same 
> browser for the same resource, that the RequestMap algorithm 
> maps to different ApplicationIds.

That's what multi-vhosting the same resources does, though. It's the whole
point. Not that this is the common case, by any means, but it certainly
happens.

> If we decide that this is a 
> desirable feature, then it can be supported, but it will 
> require multiple cookies, Sessions, and Attributes. This is a 
> small amount of work, but it complicates the API a lot.

It didn't complicate mine, except by forcing things to be qualified by
applicationId across the remoted boundary. My filter maps requests to
applicationId and everything else operates with respect to that, so that the
URL becomes irrelevant after it's been mapped.

> used to build the Session. I can't take a chance that the 
> Filter is configured for one ApplicationId and the RequestMap 
> algorithm selects another based on TARGET. So when the Filter 
> redirects the initial request off to the WAYF, if the 
> applicationId has been configured in the Filter init-param, 
> then it has to be part of the Redirect URL. I can embed it in 
> the TARGET by mutual agreement between the SP and the Filter 
> API that TARGET isn't always a URL. At this point the 
> RequestMap in the SPConfig ceases to be meaningful to the 
> Java SP because it is never used (well, neither is the ISAPI 
> element, or a few other things).

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.

But I don't understand the problem. Today, you can have the case where a
request could come in mapped to one applicationId while the TARGET ends up
being for another, but that's a misconfiguration, and I don't think I can
really prevent that, though I could probably detect it more effectively than
now.

-- Scott