Alternative Webservers and

[McDermott, Michael]

Scott,
Thanks for the thoughtful response.

On Thu, Jan 5, 2012 at 10:37 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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.
>

I understand that point, and certainly not asking anyone to take this up.
Merely, as you did, think about how to handle a diverse landscape.


> 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.
>

Just like Java and PHP no doubt.  I'm glad that Perl fad is largely over.

But tying into your next point and taking off your developer hat and
putting on your federation hat, PII from your IdP is or will be going to
web applications written in these languages as more and more campus
services are outsourced.  Instructure is a case in point.  They are an up
and coming Learning Management Cloud System that just struck agreements
with Brown, the Utah State System I think, and at least 1 big ten school.
Tomorrow there is a discussion about whehter or not they will be an
acceptable platform for the InCommon Grouper and possibly Shibboleth
training efforts.  They support SAML through a Ruby library.

The good thing about SAML is that you don't know what the downstream SP is
using.  The bad thing about SAML is you don't know what the downstream SP
is using.

So maybe the shib dev list is not a great place for this question, and an
InComon list would be better, but most colleges and universities have cash
constraints and if they outsource or develop smaller applications, they are
not going to turn to Java or C to build web apps unless they are a very
large or rich school.  And while there is a trade off in speed with Python
or Ruby, they are robust OO languages that offer many features absent from
Java and hacked into PHP.  Vendors and small shops are more and more
turning to dynamically typed languages because they minimize development
time, which is the largest expense for most application development.  Many
tmies those applications can be fronted by Apache including Ruby and
Python, but when you don't control the environment, people will find work
arounds.  I'm not trying to convert anyone to using them, but applications
using these languages are entering our federations.



> 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.
>

That might be an avenue worth perusing.


>
> >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.
>

Well, you should always judge a project by its documentation.  They are not
going to match the speed of a Tomcat or an Apache, but I guess do they have
to?  Personally, all the apps I've written in Ruby and peers at Brown have
written in Python have been fronted by Apache and worked fine.  I can
remember lots of problems with Tomcat in the early days and comments that
it is not a serious web server (why wouldn't you just use PERL and CGI
scripts?).


>
> >So following in the Java SP discussion vein, I guess I'm asking if the
> >library model is the future?
>
> Not mine.
>
More than understandable, your expertise would be wasted if anyone tried to
force you in that direction.

>
> >  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.
>
>
I agree that campuses don't and more and more move things out where
possible.  And where they do develop, they are likely to develop in the
mode that requires the least amount of programmers and is easiest to
deploy.  Easiest to deploy may mean Google App engine or Heroku.  If you're
building an app for a small liberal arts college that only needs to serve a
population of less that 5K, how many hits a second might you really be
required to handle?

Its a stretch, but imagine developers getting to a point where the only
thing between them and production deployment to AppEngine is SAML
integration.  Use library or rethink entire deployment strategy?  Now
imagine the developers are not employed by your University, but a "Cloud
Vendor".  They more likely to keep using their platform of choice and use
the Python SAML library than re-architect.


> 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.
>

I guess what I want is a way the folks tackling the SAML SP problem outside
of the Shib SP world who lack the hard won experience of you and the rest
of the Shib development team to be able to tap into your collective wisdom,
because applications built on those libraries are coming to a federation
and/or campus near you.

>  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).
>

If its OK with you, I'd post that to the Ruby Higher Education list.
Perhaps that is something that bears pursuing and someone there is
interested in following up.

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

I'll pass that on as well.

I am personally happy with the Apache answer.  But looking around and to
the future, I believe it more likely that there will be lots of web
development languages and a series of servers.  And given Oracle's long
history of working well with the open source world, I do expect the JVM
environment to long be a wide open field (Stallman's a kook right), but
just imagining I'm wrong, what else is out there?


>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>



-- 
Michael J. McDermott
Lead Developer, Identity and Access Management
Brown University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20120105/99f34ca2/attachment.html