Shibboleth Developers

["Howard Gilbert" <>]

[maybe a quick poll in today's call]

I spent last week reorganizing the Filter to SP API to make it more efficient and suitable for a Remote or WS version. I wanted to get a final version of the Filter/RM API set before the Beta. Everything went fine until I ran up against an architecture problem that has been pending for a while. After beating my head against it for a while, I decided I should put it up for general discussion.

There is a basic difference between the Java Servlet Filter and the C++ filters applied to other Web Servers (mod_shib, ISAPI, NSAPI, etc.). A Servlet filter is configured for one application context and operates local to that context. The C++ filters are configured globally to the server (which is useful because one of their common functions is to route incoming requests by rewriting the URL). The Servlet Filter also has complete control over the HttpServletRequest block that the application sees, and can also put attribute information in the ServletSession block. These structures do not occur in the C++ environment which has to work through simulated Headers.

The C++ figures are configured by the RequestMap structure in the SPConfig. Given a particular virtual hostname, port, and directory/subdirectory in a URL, the RequestMap indicates if the resource is protected and selects an Application to provide parameters for the Session management.

The API was designed around the same RequestMap algorithm, but the code had not been seriously tested on any multiple <Application> situations. I suppose it is possible to simply test this code and fix bugs, but this would put some stress on the differences in the architectures. The hostname and port number are available through the Request, so all the 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.

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. Admittedly there is a low likelihood that in normal use any one person from the same Browser would try to access the same resource through two different Federations, but if it is a configuration option it will certainly be tested by someone and therefore I have to build it into the design and unit test it to work.

Meanwhile, a Servlet Filter has its own configuration and init-param values from the web.xml file in the application. The C++ code has no such configuration. So a Filter driven entirely by RequestMap tries to duplicate an algorithm based on configuration options from the wrong Web Servers, and ignores the configuration options provided by the native Java environment.

An alternate approach would be to take the final result of the RequestMap (mostly the ApplicationId), and configure it directly to the Servlet Filter.

<init-param>
    <param-name>applicationId</param-name>
    <param-value>nondefault</param-value>
</init-param>

Obviously if no such value was specified, the Filter would connect to the <Applications> element also known as "default".

This ultimately boils down to two possibilities. In one, the Filter takes the request URL, feeds it to the SPConfig and asks for the parameters associated with the Application that the URL maps to. In the other case, it simply provides its own configured applicationId and gets those parameters.

The choice may be influenced by the bad consequences of each decision.

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

The alternative is to configure the Filter with an ApplicationId, and then if you insist that you want different Sessions for different URL formats (say one Application for HTTP request and a different one for SSL requests, or one hostname mapped to one Federation and another to a different Federation) then you have two filters. Each Filter then manages one Session for one Application (though they still many need different Cookie names and HttpSession parameter names). The problem with this second approach occurs when the AssertionConsumerURL (formerly known as shireURL) points to a URL in the SP context. When it arrives at the SP, there is no obvious applicationId, so the current logic runs the TARGET URL through the RequestMap logic to select the ApplicationId 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).

Of course, the mapping function hasn't entirely disappeared if more than one Filter supports more than one Application in the same context. However, then it becomes either a Filter-Mapping (I wish it were so simple) or init-params in the context in some syntax convenient to Java.

Now in the past, when faced with a choice like this, I have tended to code both alternatives. This is actually a lot easier to code than it would be to document to users. So if this raises any serious dispute, my threat to everyone is that I will code it to work both ways and then let Nat's head explode. However, my sense in dealing with previous versions of this issue is that there are no strong constituencies and we can all probably agree among ourselves to do it one way, until we hear from some user who has a convincing need to do it the other way (although from what I know of our users they either just want "default" or else they will have some third or fourth way to address this question).