Scott, <br>Thanks for the thoughtful response.<br><br><div class="gmail_quote">On Thu, Jan 5, 2012 at 10:37 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu">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">The generic answer is that the SP supports this today using FastCGI, and<br>
additional work to support more proprietary server APIs is something<br>
that's possible given time and/or additional resources.<br>
<br>
Coding a full SP in every other language? No, that's not really viable.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Today's Ruby and Python will be two other languages tomorrow. Short<br>
attention spans led people to them, and it will lead the same people away.<br></blockquote><div><br>Just like Java and PHP no doubt. I'm glad that Perl fad is largely over.<br><br>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. <br>
<br>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. <br><br>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.<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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></blockquote><div><br>That might be an avenue worth perusing.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
>I'd hesitate to dismiss other languages servers as a toy, though clearly<br>
>Python and Ruby being interpreted makes them slower.<br>
<br>
</div>I think Peter was calling the web servers toys, not the languages. And I<br>
happen to agree. The documentation for those servers alone is laughably<br>
bad in most cases.<br></blockquote><div><br>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?).<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
>So following in the Java SP discussion vein, I guess I'm asking if the<br>
>library model is the future?<br>
<br>
</div>Not mine.<br></blockquote><div>More than understandable, your expertise would be wasted if anyone tried to force you in that direction. <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> While it has been discussed before, technology is a moving target. Is<br>
>targeting plugins for Web Servers the best strategy?<br>
<br>
</div>I stand behind it fully. If you want to use APIs and never have a hope of<br>
changing or altering your infrastructure, you can do so, but I think it's<br>
a very, very bad model. Especially for most campuses. Enterprises with<br>
lots of control and budget can rewrite apps to change things out, but my<br>
experience is campuses don't.<br>
<br></blockquote><div><br>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? <br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you want me to articulate the essential principle underlying the<br>
Shibboleth SP, it's not SAML, it's "don't use APIs if at all possible". So<br>
that probably answers your question? I would deploy a hundred Apaches<br>
before I'd code to an API.<br></blockquote><div class="im"><br>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.<br>
<br>
> The Devs/Members on the Shibboleth project are two things, developers<br>
>of specific software, leaders on the vanguard of SAML and federated<br>
>authentication. How can library based projects tap into the vision<br>
>without requiring leaders to give up the specific practice (which<br>
>directly informs the vision)?<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If I'm pressed on it, the answer would probably be to leverage a remote<br>
API (SAML as a service). You're still stuck with lock-in, but at least in<br>
theory the remote API could be abstract enough to be protocol neutral (as<br>
in fact shibd's own internal API is).<br></blockquote><div><br>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. <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As always, I'm open to approach by developers that want to work on<br>
specific problems.<br></blockquote><div><br>I'll pass that on as well. <br><br>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?<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net">dev-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Michael J. McDermott<br>Lead Developer, Identity and Access Management<br>Brown University<br><br><br>