This topic does not indicate a commitment to provide a Java implementation of the SP software. It only represents current thinking on the topic.
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.
However, in some cases such a deployment environment is not ideal. For such instances it would be nice to have a Java-native implementation of the SP. Such an implementation might integrate with an application via:
There are existing open source Java-based SAML SP implementations, however they are either poorly supported or are rather limited in what they support. These include:
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.
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 a library that was higher level than OpenSAML. Currently the idea would be to have two coarse grained components:
In both services 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 not widely used and its inclusion would either end up adding a whole lot of complexity or prohibit clustering.
Such an SP library we believe would go 80-90% of the way to a usable SP. 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 work necessary to go from the SP library to an SP implementation 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 probably also be what a significant portion of Java web apps would want today anyways.
Such a Servlet/Filter based SP would create HTTP sessions (expiration would still be managed by the container), make attributes available via the Session, and optionally HttpServletRequest, attributes. Discovery would be done using the new SP-local discovery service. Session initiation would be implemented in the Servlet.