Alternative Webservers and

[Cantor, Scott]

The generic answer is that the SP supports this today using FastCGI, and
additional work to support more proprietary server APIs is something
that's possible given time and/or additional resources.

Coding a full SP in every other language? No, that's not really viable.
Today's Ruby and Python will be two other languages tomorrow. Short
attention spans led people to them, and it will lead the same people away.

An additional project has been discussed to expose a distributed API for
processing SAML via either the SP (shibd) or via a Java version of the
same concept.

>I'd hesitate to dismiss other languages servers as a toy, though clearly
>Python and Ruby being interpreted makes them slower.

I think Peter was calling the web servers toys, not the languages. And I
happen to agree. The documentation for those servers alone is laughably
bad in most cases.

>So following in the Java SP discussion vein, I guess I'm asking if the
>library model is the future?

Not mine.

>  While it has been discussed before, technology is a moving target.  Is
>targeting plugins for Web Servers the best strategy?

I stand behind it fully. If you want to use APIs and never have a hope of
changing or altering your infrastructure, you can do so, but I think it's
a very, very bad model. Especially for most campuses. Enterprises with
lots of control and budget can rewrite apps to change things out, but my
experience is campuses don't.

If you want me to articulate the essential principle underlying the
Shibboleth SP, it's not SAML, it's "don't use APIs if at all possible". So
that probably answers your question? I would deploy a hundred Apaches
before I'd code to an API.

>  The Devs/Members on the Shibboleth project are two things, developers
>of specific software, leaders on the vanguard of SAML and federated
>authentication.  How can library based projects tap into the vision
>without requiring leaders to give up the specific practice (which
>directly informs the vision)?

If I'm pressed on it, the answer would probably be to leverage a remote
API (SAML as a service). You're still stuck with lock-in, but at least in
theory the remote API could be abstract enough to be protocol neutral (as
in fact shibd's own internal API is).

As always, I'm open to approach by developers that want to work on
specific problems.

-- Scott