Alternative Webservers and

[McDermott, Michael]

Scott,
Thanks again for the thoughtful response.  Sorry that this was not the best
forum, but grateful for your time.
Mike


On Thu, Jan 5, 2012 at 11:14 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
>
> --
> 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/20120106/78741715/attachment.html