AJAX vs JSONP

[Lukas Hämmerle]

Allow me to add some points to this subject as we are one of those
federations that use remote Javascripts for Discovery.

Very simply put these are the gains of using JSONP/remote Javascript
loading:
- Ability to load data from remote sites.
- Ability to load Javascript code from remote sites. This code can be
generated dynamically and updated automatically be the maintainer.
- Very convenient and easy to integrate a feature into many sites

And the risks:
- Including script tags from remote sites allows the remote sites to
inject any content into a website.
- Dependence on remote site's availability and security in general
- If used by many sites, many sites will be affected immediately
  by problems (Single Point of Failure)

Loading executable code from Remote sites is always a risk. The question
is if one can handle them and if the risks are acceptable taking into
account the benefits. There are millions of web pages for whom the risks
*are* acceptable. Just think of Google Ad Sense and similar services.
They wouldn't work without loading remote Javascripts. On the other
hand, Google certainly will make sure that their scripts are well
protected because this is business critical for them.

The same is true for all web sites that use hosted versions of JQuery,
YUI and other Javascript frameworks. Their administrators  apparently
think that the gains outweigh the risks (or they are just not aware of
the risks or too lazy to download a local copy).

In SWITCHaai we have been offering to our Service Providers a feature
called Embedded WAYF since more than two years. It allows to embed the
central wayf into any web page. In order to make this work, an
executable javascript is loaded from our central WAYF.

For the operators of an AAI service the Embedded WAYF is very valuable
because the integration is very easy, they always have an up-to-date
list of IdPs and they can customize their instance of the WAYF. The
improved usability from having a WAYF integrated into a web page is also
very much appreciated by all parties.

Today about half of all observed login requests (total 1.5 millions) on
our central WAYF are handled by the Embedded WAYF.

In order to protect the Embedded WAYF, our central wayf service is
provided by multiple instances in different geographical areas. Using
anycast, several monitoring applications and an intrusion detection
system that informs us about file manipulations, we try to ensure that
the service is sufficiently protected.

However, in the more than two years that we operated the Embedded WAYF
we also have learned a few times about the things that can go wrong.
So far all issues directly affecting the Embedded WAYF were related to
configuration errors and bugs. Both of which affect any kind of
software. The difference is that such issues become effective
immediately on all sites that use the Embedded WAYF.

The good thing though is that not only negative effects become effective
immediately but also fixes for such issues. No need to make another
release and redeploy of the software to fix the problem.

So far the most serious WAYF incident in six years of production
operation of SWITCHaai happened just a few weeks ago. But it had nothing
to do with the remotely loaded javascript but with the architecture of
our infrastructure.

A DOS attack stopped hundreds of users from accessing their AAI services
during some minutes because the WAYF was not or only very slowly responding.

Although this incident had not directly to do with the Embedded WAYF, it
demonstrated that a central service like our WAYF can be a risk to the
infrastructure. The same would be true for a central federated error
handling solution. On the other hand, error handling is probably not
that critical given that the user already experienced another error that
led him to the error handling page :-)

Although we will continue to use the Embedded WAYF (and remotely loaded
javascripts), we know that with the advent of Shibboleth 2.4 new
approaches to solve the Discovery issue became available. Therefore, we
are having a closer look at the Shibboleth Embedded Discovery Service
because it gets rid of the above-mentioned risks (at the cost of some
other drawbacks).

Cheers
Lukas

-- 
SWITCH
Serving Swiss Universities
--------------------------
Lukas Hämmerle, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 64, fax +41 44 268 15 68
lukas.haemmerle at switch.ch, http://www.switch.ch