Java Service Provider

Current Landscape

Currently, individuals wishing to SAML-enable a Java web application with Shibboleth software must front-end their Servlet container with a supported web server (IIS, Apache, Netscape/iPlanet/Sun) and use the C++ SP implementation. In many cases this is fine because deployers often deploy their container behind such a web server for other reasons.

In some cases, for one reason or another, such a deployment environment is not ideal. Instead it would be nice to have a Java-native implementation of the SP. Such an implementation might integrate with an application via:

• Servlet/Filter - The Servlet 2.x APIs, which includes Filters, are literally the standard for Java web applications. Therefore, this presents a reliable model for dealing with the HTTP request/responses, locating configuration data, and storing attribute data.

• Java Authentication Service Provider Interface for Containers (JASPI) - The JASPI standard has been around since 2007 but only recently has begun to be adopted by most containers (see next item for why). This standardizes things like Tomcat's security realms.

• Servlet 3.0 - The latest version of the Servlet standard, finalized in December of 2009, now includes API calls to initiate and check the state of authentication. The general idea seems to be that invoking such APIs will trigger a JASPI module.

• Spring Security - Spring has become a defacto standard in Java applications. Spring Security offers a model for integrating various authentication mechanisms in to an application. It has a nascent SAML SP but it's pretty immature and is Spring security specific. Additionally it can be cumbersome to integrate Spring Security with applications because of various assumptions made by the framework.

• Container/Application Integrated Mechanisms - Most containers provide some sort of implementation-specific mechanism for integrating new authentication mechanisms. Many of these have baked in assumptions about the general flow of an authentication interaction, mostly based of the idea of username/password. Applications-integrated mechanisms are rarely pluggable and where they are often make similar assumptions as the container developers did.

There are existing open source Java-based SAML SP implementations, however they are either no longer supported or are rather limited in what they support. These include:

• OpenSSO from Sun Microsystems
• a toolkit from the Danish Government, based on OpenSAML, which implements a java SP as a filter
• Enterprise Sign On Engine (ESOE)

In addition, with commercial applications, there is a question about whether deployers will be willing to integrate a Java SP given that doing so would most likely void their support contracts.

Shibboleth Java SP

So, given the discussion above, what might a Shibboleth Java SP look like? The following rough architecture tries to strike a balance between deployment complexity and feature set.

It seems clear that picking a single integration option as the one true option is probably not a good decision. So, instead we would probably try to create something that was higher level than the OpenSAML. Currently the idea would be to have two gross components:

• Authentication Service - this would be responsible for determining if a request needed to be authenticated (similar to the C++ SP's request map functionality), creating the authentication request and processing the response.

• Attribute Server - this would be responsible for taking a SAML assertion, possibly querying the IdP, and spitting out attributes. This would be similar to the C++ SP's attribute resolver, extractor, and filter services.

In both the security policies currently performed by the IdP and SP would be included (i.e. SAML condition validation, signature checking, etc.). In terms of protocols we'd implement the Shib and SAML 2 SSO and SAML 1 and 2 Attribute query profiles. We'd leave out artifact resolution because it seems like it's just not used that often and would either end up adding a whole lot of complexity or prohibit clustering.

Such a library we believe would go 80-90% of the way. It would not address discovery and session initiation because those end up being very tightly coupled to the underlying technology (e.g. the way you'd return a discovery response to a Servlet/Filter setup is quite different than returning it to a Spring Security setup).

To both demonstrate the final steps necessary in an SP implementation and to cover what we feel is probably the most case right now, we would also produce an SP implementation that targeted the Servlet 2.x standard (JASPI and Servlet 3 just aren't widely enough available currently). This would create HTTP sessions (expiration would still be managed by the container), make attributes available via the session, and optionally request, attributes. Discovery would be done using the new SP-local discovery service. Session initiation would be implemented in the authentication Servlet.