Shibboleth Developers

["Howard Gilbert" <>]

In the C++ SP, the POST can go to a URL of the form "https://server:port/Shibboleth.sso/extra" while in the Java SP it must go to "https://server:port/context/Shibboleth.sso/extra".

 

The problem here is a structural difference between the implementation of Filters in ISAPI and Apache compared to the Java Servlet Standard. The ISAPI and Apache mod world install filters on the entire server. ISAPI, for example, configures a module over the entire site (hostname+port-number) and maps it based on file extension. Thus *.sso is mapped to the shibboleth DLL today just as *.shire was mapped previously. The application (virtual directory) doesn't matter in this case.

 

However, the Java Servlet API maps filters to specific contexts (application directories) on the server. The Java SP has been written so that if the SP is configured in the /shibboleth-sp context and the secured data is in /secure, then the Authentication Consumer handlerURL can be either. If the POST goes to /shibboleth-sp/Shibboleth.sso then the SP handles it directly, while if the POST goes to /secure/Shibboleth.sso then the data is digested and is forwarded to the SP classes for processing. What cannot happen is it it cannot go to /Shibboleth.sso, a URL in the ROOT of the server. In the ISAPI Apache world there was no need for a specific context to be mentioned, so it was common for the handlerURL to reference the dummy Shibboleth.sso and before it Shibboleth.shire in the "root" directory of the server, but that was sloppy syntax and now it comes back to pose a problem.

 

While I believe that the syntax of the configuration file should be roughly the same in all implementations, I do not think that this extends to the contents of XML attributes whose type is designated to be URIs. There will be differences in URI format based on local conventions and server choices.

 

---

The snippet cited below is a part of a broader issue where pieces of the Java SP's configuration differ from the naming and structure of the C++ SP; in this particular example, default metadata will differ. I've also run into a handful of places where the main configuration is different through trying to use configuration files for one in the other.

 

How hard do we want to try to unify the configuration further? Is it a stated goal to be able to interchange the Java and C++ SP with no change to metadata or major configuration differences in sp.xml/shibboleth.xml, with the web server specific stuff mostly contained in server.xml/web.xml/httpd.conf?

 

I only ask because based on my tinkering so far it seems like it might be possible, so this might be a silly question. If not, I might try to restructure the documentation because I'd assumed once a certain point were reached everything further would be done in a similar fashion.

 

On Oct 20, 2005, at 1:10, Howard Gilbert wrote:

Well, the problem here is that there is no context. There should be a

/shibboleth-sp between the 8443 and the Shibboleth.sso. Probably left it out

of the handlerURL.