Shibboleth Developers

["Howard Gilbert" <>]

> ONC is also a red herring here, 

It is simply a detail, and maybe I should have left it out rather than
getting things confused. More generally, the current target designs are
"standalone", based only on generic system services (like raw sockets).
There is nothing wrong with this, but it may not be as friendly as we want
to the largest number of potential "customers" we would like to get
involved.

The ISAPI or Apache modules run in the context of Web Servers, but they are
essentially independent C programs that have access only to the HTTP-related
control blocks. They interface to the SHIRE/SHAR using communications
methodologies that are part of the parent OS and not part of the Web Server
environment. However, Web Servers were first and foremost file vending
systems, and the filters run as a front-end to that service. It is notable
that when applications run under these servers, there is no architected rich
authentication interface between the application and the filter.

The alternative models are Application Server systems. They are "container
based" and have larger portable services framework libraries that run under
the operating system. They are J2EE and .NET-ASP.NET.

The key difference to Shibboleth is that they have a place to plug
Shibboleth directly into the framework as an authentication component rather
than as a file-filter frontend. In J2EE there are various pieces, but the
most promising is JSR 196 (http://www.jcp.org/en/jsr/detail?id=196). When it
comes out of committee, it should provide a standard interface through which
Shibboleth can provide identity/roles/attributes to any program, not though
an interface we invented, but a standard we share with others. Similarly,
ASP.NET has a defined programming interface for security providers to add
principal information to their Application Server environment (generally
referred to as Forms-based Authentication). 

> 
> Using .NET isn't going to obviate the need for this except insofar as we
> recognize it's Windows specific anyway and could use something
> proprietary,
> but that would be stupid since what we have works and is done. Maybe we
> would in fact decide we need nothing out of process, but somehow I'm
> betting
> we'll need it even more.

The purpose isn't to redo work unnecessarily. We have a "product". Some
influential parties have now given us an invitation to integrate our product
into their widely used environments. In my mind, the only question is how
much it costs to make the adaptation, and how many
programmers/applications/institutions will start using our methodology if it
is delivered in a package that they find most convenient to use. You say
Windows is proprietary, but we are not trying to sell Shibboleth product to
Microsoft. We are trying to sell it to the "University of Northern South
Dakota at Hoople". In the end, we will be a success if we can point to the
largest possible install base. We can reasonably count on Apache, IIS,
J2EE/Tomcat, and .NET as having very wide distribution in our demographic.
After that, I start to run out of ideas.

For a company there would two questions. Is it too much work to adapt to
...? Is there an alternate platform that would have more institutional buy
in than ...? 

However, for an open source project, there is only one question: Does anyone
want to do ... ?