Shibboleth Developers

["Jones, Mark B" <>]

Chad,
We would be very interested in a Java SP but I'm not sure if our vision of a 
Java SP matches with what is proposed.  Can you summarize what work would 
have to be done outside the SP?  If I understand what you mean by 
"externalizing authentication" (and I'm not sure I understand) then I don't 
see that a Java implementation would be of any added value.  What are the 
expected advantages of a Java SP over existing implementations?


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Chad La Joie
Sent: Wednesday, August 25, 2010 1:41 PM
To: 

Subject: Re: [Shib-Dev] Return of the Java SP... again

Thanks Andrew,

And just to be clear, I say it's a questionable idea not because I 
necessarily think it's bad (I don't), but because there are still a lot 
of work outside the SP that would have to be done and it's questionable 
to me whether people would do that work.  Some would, the question is 
how many.

On 8/25/10 2:36 PM, Andrew Petro wrote:
> 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.
>>
>
>

-- 
Chad La Joie
http://itumi.biz
trusted identities, delivered