Alternative Webservers and

[Cantor, Scott]

On 1/5/12 9:27 PM, "McDermott, Michael" <michael_mcdermott at brown.edu>
wrote:
>
>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.

One answer is, work to make it no more diverse than it has to be. If you
(meaning deployer) value what Apache gives you (which includes the modules
it supports) then you factor that into your choices.

I think the underlying problem in play is partly that it takes more than a
simple understanding of federation to know why the implementations
available natively aren't sufficient for many purposes. I think there are
two ways to maybe attack that:

- expose them as insecure (many of them will be, subject to wrapping
attacks or worse)
- document where they fall short in something closer to plain language

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

Yes. So far I've dealt with a couple and proven both of them to be
insecure and broken (see above). That helped make my argument in at least
those cases. It's becoming a bit of a hobby.

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

You don't have to build apps in C or Java to use Apache (or IIS) though.

In terms of the question, no, the dev list is not really the best place to
attack the generic problem of dealing with non-Shibboleth implementations,
or making them better. There just isn't a lot we can do about that.

I will say that, contrary to the opinions of some, I don't believe OAuth
is going to fix this. You're going to see many more implementations of it
in those languages, yes. And probably in Shibboleth eventually. But true
to form, our implementation of it will be designed to scale, and be
flexible, and include a trust management component, and metadata, and all
that. And those one-offs in Ruby won't. And we'll have the same problems
we have now.

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

I don't like these languages, but that's really entirely beside the point,
I'm not calling them slow or anything else. What I am saying is that none
of them require using boutique web servers. That's a separate decision.
And there are plenty of hosting providers that don't limit your choices.
That's also a choice.

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

Yes, it might. But I run into people all the time that will refuse to run
anything needing native code (or even Java) if they have an otherwise pure
Ruby (or whatever) solution. They expect it to be self-contained in Ruby
gems or whatever. Maybe I'm just looking for reasons not to do it, but we
have to be convinced that the work is worth it.

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

Which is why I don't think there's much we can do. Anything I built would
not be deployable that way. So I have to hope that pysaml2 works and
improves. At least in that case, I think it will. If you tell Roland
what's needed, I think he'll do it.

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

I guess a partial answer is, you'd have to convince the people who pay me
to pay me to write text, not code. I can write. I don't love it, but I can
do it well. But it takes just as much time as coding does, and I can't
really do both.

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

I think you're stuck with the problem that it will never just be a gem,
but that's fine with me. There's an item on the roadmap for that specific
idea, has been for a while.

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

I do too, but I also think they come and go, while Apache stays around.

But I don't think anybody is proposing that it's viable to code to those
servers. Those languages have frameworks you have to plug into, not via
web servers.

-- Scott