Scott,<div>Thanks again for the thoughtful response. Sorry that this was not the best forum, but grateful for your time. </div><div>Mike</div><div><br><br><div class="gmail_quote">On Thu, Jan 5, 2012 at 11:14 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/5/12 9:27 PM, "McDermott, Michael" <<a href="mailto:michael_mcdermott@brown.edu" target="_blank">michael_mcdermott@brown.edu</a>><br>
wrote:<br>
<div>><br>
>I understand that point, and certainly not asking anyone to take this up.<br>
> Merely, as you did, think about how to handle a diverse landscape.<br>
<br>
</div>One answer is, work to make it no more diverse than it has to be. If you<br>
(meaning deployer) value what Apache gives you (which includes the modules<br>
it supports) then you factor that into your choices.<br>
<br>
I think the underlying problem in play is partly that it takes more than a<br>
simple understanding of federation to know why the implementations<br>
available natively aren't sufficient for many purposes. I think there are<br>
two ways to maybe attack that:<br>
<br>
- expose them as insecure (many of them will be, subject to wrapping<br>
attacks or worse)<br>
- document where they fall short in something closer to plain language<br>
<div><br>
>But tying into your next point and taking off your developer hat and<br>
>putting on your federation hat, PII from your IdP is or will be going to<br>
>web applications written in these languages as more and more campus<br>
>services are outsourced.<br>
<br>
</div>Yes. So far I've dealt with a couple and proven both of them to be<br>
insecure and broken (see above). That helped make my argument in at least<br>
those cases. It's becoming a bit of a hobby.<br>
<div><br>
>So maybe the shib dev list is not a great place for this question, and an<br>
>InComon list would be better, but most colleges and universities have<br>
>cash constraints and if they outsource or develop smaller applications,<br>
>they are not going to turn to Java or C to build web apps unless they are<br>
>a very large or rich school.<br>
<br>
</div>You don't have to build apps in C or Java to use Apache (or IIS) though.<br>
<br>
In terms of the question, no, the dev list is not really the best place to<br>
attack the generic problem of dealing with non-Shibboleth implementations,<br>
or making them better. There just isn't a lot we can do about that.<br>
<br>
I will say that, contrary to the opinions of some, I don't believe OAuth<br>
is going to fix this. You're going to see many more implementations of it<br>
in those languages, yes. And probably in Shibboleth eventually. But true<br>
to form, our implementation of it will be designed to scale, and be<br>
flexible, and include a trust management component, and metadata, and all<br>
that. And those one-offs in Ruby won't. And we'll have the same problems<br>
we have now.<br>
<div><br>
>And while there is a trade off in speed with Python or Ruby, they are<br>
>robust OO languages that offer many features absent from Java and hacked<br>
>into PHP.<br>
<br>
</div>I don't like these languages, but that's really entirely beside the point,<br>
I'm not calling them slow or anything else. What I am saying is that none<br>
of them require using boutique web servers. That's a separate decision.<br>
And there are plenty of hosting providers that don't limit your choices.<br>
That's also a choice.<br>
<div><br>
>An additional project has been discussed to expose a distributed API for<br>
>processing SAML via either the SP (shibd) or via a Java version of the<br>
>same concept.<br>
><br>
>That might be an avenue worth perusing.<br>
<br>
</div>Yes, it might. But I run into people all the time that will refuse to run<br>
anything needing native code (or even Java) if they have an otherwise pure<br>
Ruby (or whatever) solution. They expect it to be self-contained in Ruby<br>
gems or whatever. Maybe I'm just looking for reasons not to do it, but we<br>
have to be convinced that the work is worth it.<br>
<div><br>
>Its a stretch, but imagine developers getting to a point where the only<br>
>thing between them and production deployment to AppEngine is SAML<br>
>integration. Use library or rethink entire deployment strategy? Now<br>
>imagine the developers are not employed by your University, but a "Cloud<br>
>Vendor". They more likely to keep using their platform of choice and use<br>
>the Python SAML library than re-architect.<br>
<br>
</div>Which is why I don't think there's much we can do. Anything I built would<br>
not be deployable that way. So I have to hope that pysaml2 works and<br>
improves. At least in that case, I think it will. If you tell Roland<br>
what's needed, I think he'll do it.<br>
<div><br>
>I guess what I want is a way the folks tackling the SAML SP problem<br>
>outside of the Shib SP world who lack the hard won experience of you and<br>
>the rest of the Shib development team to be able to tap into your<br>
>collective wisdom, because applications built on those libraries are<br>
>coming to a federation and/or campus near you.<br>
<br>
</div>I guess a partial answer is, you'd have to convince the people who pay me<br>
to pay me to write text, not code. I can write. I don't love it, but I can<br>
do it well. But it takes just as much time as coding does, and I can't<br>
really do both.<br>
<div><br>
>If its OK with you, I'd post that to the Ruby Higher Education list.<br>
>Perhaps that is something that bears pursuing and someone there is<br>
>interested in following up.<br>
<br>
</div>I think you're stuck with the problem that it will never just be a gem,<br>
but that's fine with me. There's an item on the roadmap for that specific<br>
idea, has been for a while.<br>
<div><br>
>I am personally happy with the Apache answer. But looking around and to<br>
>the future, I believe it more likely that there will be lots of web<br>
>development languages and a series of servers.<br>
<br>
</div>I do too, but I also think they come and go, while Apache stays around.<br>
<br>
But I don't think anybody is proposing that it's viable to code to those<br>
servers. Those languages have frameworks you have to plug into, not via<br>
web servers.<br>
<div><div><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank">dev-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Michael J. McDermott<br>Lead Developer, Identity and Access Management<br>Brown University<br><br><br>
</div>