Shibboleth Developers

[Andrew Petro <>]

Chad,

Yes, I do think a Java SP would be used, and I predict that I personally 
would be able to use it on (Unicon) consulting projects, and I predict 
that more generally Unicon would be able to use it on projects.

I also think it would have a lot of potential for enabling better 
support for Shibbolization in Java web applications.  uPortal makes some 
effort to ship with "Shibboleth support" today in that it supports 
relying on container-asserted REMOTE_USER, supports reading attributes 
from headers, etc.  So the upshot is that one can, and people have, 
configured these lovely application features along with the Shibboleth 
SP to achieve Shibbolization of uPortal.

A Java SP would help uPortal to go further, to e.g. ship a quickstart 
with a working example of using Shibboleth *without requiring Apache*.  
To emulate what is currently done with uPortal shipping a quickstart 
including CAS and working configuration to delegate authentication to 
CAS, that is, do this same thing with Shibboleth, shipping an example 
IdP and the Java SP configured to allow login to uPortal via that 
example IdP.

While I respect the considerations that make a Java SP a questionable 
idea, I think it's also a practical idea, one that would help with 
momentum of adoption and with ease of providing compelling out of the 
box examples and Shibboleth integration features.

Andrew



On 08/25/2010 11:11 AM, Chad La Joie wrote:
> You just can't keep a questionable idea down.  ;)
>
> The Shibboleth Core team has been discussing internally and on the dev 
> phone calls whether we should delay IdP v3 work in favor of a Java SP.
>
> I produced the following page that currently summarizes our discussions:
> https://spaces.internet2.edu/display/SHIB2/JavaSPRoadmap
>
> The first part of the page tries to describe the the current Java 
> application authentication landscape and the second part shows our 
> current thoughts on what a Shibboleth Java SP might be.
>
> What we are most interested in hearing, at this point, is:
>  - is there still a reasonable demand for a Java SP (i.e. would you 
> actually use it)
>  - is the rather vague functional description going in the right 
> direction
>
> Please note, a Java SP will NOT alleviate the work of externalizing 
> authentication and attribute acquisition.  If you are not willing to 
> take on that work for the web applications you have in mind please do 
> not respond that you'd use the Java SP.