Tom,<div>Do you control all the domains in question? If so, the scope of your concern is probably greatly reduced.</div><div><br></div><div>Here's a pretty good stackoverflow primer on the subject:</div><div><a href="http://stackoverflow.com/questions/613962/is-jsonp-safe-to-use">http://stackoverflow.com/questions/613962/is-jsonp-safe-to-use</a></div>
<div><br></div><div>Mike</div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Mon, Oct 24, 2011 at 8:34 AM, Lukas Hämmerle <span dir="ltr"><<a href="mailto:lukas.haemmerle@switch.ch">lukas.haemmerle@switch.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Allow me to add some points to this subject as we are one of those<br>
federations that use remote Javascripts for Discovery.<br>
<br>
Very simply put these are the gains of using JSONP/remote Javascript<br>
loading:<br>
- Ability to load data from remote sites.<br>
- Ability to load Javascript code from remote sites. This code can be<br>
generated dynamically and updated automatically be the maintainer.<br>
- Very convenient and easy to integrate a feature into many sites<br>
<br>
And the risks:<br>
- Including script tags from remote sites allows the remote sites to<br>
inject any content into a website.<br>
- Dependence on remote site's availability and security in general<br>
- If used by many sites, many sites will be affected immediately<br>
by problems (Single Point of Failure)<br>
<br>
Loading executable code from Remote sites is always a risk. The question<br>
is if one can handle them and if the risks are acceptable taking into<br>
account the benefits. There are millions of web pages for whom the risks<br>
*are* acceptable. Just think of Google Ad Sense and similar services.<br>
They wouldn't work without loading remote Javascripts. On the other<br>
hand, Google certainly will make sure that their scripts are well<br>
protected because this is business critical for them.<br>
<br>
The same is true for all web sites that use hosted versions of JQuery,<br>
YUI and other Javascript frameworks. Their administrators apparently<br>
think that the gains outweigh the risks (or they are just not aware of<br>
the risks or too lazy to download a local copy).<br>
<br>
In SWITCHaai we have been offering to our Service Providers a feature<br>
called Embedded WAYF since more than two years. It allows to embed the<br>
central wayf into any web page. In order to make this work, an<br>
executable javascript is loaded from our central WAYF.<br>
<br>
For the operators of an AAI service the Embedded WAYF is very valuable<br>
because the integration is very easy, they always have an up-to-date<br>
list of IdPs and they can customize their instance of the WAYF. The<br>
improved usability from having a WAYF integrated into a web page is also<br>
very much appreciated by all parties.<br>
<br>
Today about half of all observed login requests (total 1.5 millions) on<br>
our central WAYF are handled by the Embedded WAYF.<br>
<br>
In order to protect the Embedded WAYF, our central wayf service is<br>
provided by multiple instances in different geographical areas. Using<br>
anycast, several monitoring applications and an intrusion detection<br>
system that informs us about file manipulations, we try to ensure that<br>
the service is sufficiently protected.<br>
<br>
However, in the more than two years that we operated the Embedded WAYF<br>
we also have learned a few times about the things that can go wrong.<br>
So far all issues directly affecting the Embedded WAYF were related to<br>
configuration errors and bugs. Both of which affect any kind of<br>
software. The difference is that such issues become effective<br>
immediately on all sites that use the Embedded WAYF.<br>
<br>
The good thing though is that not only negative effects become effective<br>
immediately but also fixes for such issues. No need to make another<br>
release and redeploy of the software to fix the problem.<br>
<br>
So far the most serious WAYF incident in six years of production<br>
operation of SWITCHaai happened just a few weeks ago. But it had nothing<br>
to do with the remotely loaded javascript but with the architecture of<br>
our infrastructure.<br>
<br>
A DOS attack stopped hundreds of users from accessing their AAI services<br>
during some minutes because the WAYF was not or only very slowly responding.<br>
<br>
Although this incident had not directly to do with the Embedded WAYF, it<br>
demonstrated that a central service like our WAYF can be a risk to the<br>
infrastructure. The same would be true for a central federated error<br>
handling solution. On the other hand, error handling is probably not<br>
that critical given that the user already experienced another error that<br>
led him to the error handling page :-)<br>
<br>
Although we will continue to use the Embedded WAYF (and remotely loaded<br>
javascripts), we know that with the advent of Shibboleth 2.4 new<br>
approaches to solve the Discovery issue became available. Therefore, we<br>
are having a closer look at the Shibboleth Embedded Discovery Service<br>
because it gets rid of the above-mentioned risks (at the cost of some<br>
other drawbacks).<br>
<br>
Cheers<br>
Lukas<br>
<font color="#888888"><br>
--<br>
SWITCH<br>
Serving Swiss Universities<br>
--------------------------<br>
Lukas Hämmerle, Software Engineer, Net Services<br>
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland<br>
phone <a href="tel:%2B41%2044%20268%2015%2064" value="+41442681564">+41 44 268 15 64</a>, fax <a href="tel:%2B41%2044%20268%2015%2068" value="+41442681568">+41 44 268 15 68</a><br>
<a href="mailto:lukas.haemmerle@switch.ch">lukas.haemmerle@switch.ch</a>, <a href="http://www.switch.ch" target="_blank">http://www.switch.ch</a><br>
</font><div><div></div><div class="h5">--<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"><div><br></div>-- <br>Michael J. McDermott<br>Lead Developer, Identity and Access Management<br>Brown University<br><br><br>
</div>