I’m going to start this blog post with a “user story” – the sort of thing that we use to shape systems design. \u00a0Then I’ll talk about one aspect of the design that this user story gave rise to, and the resulting fun with hacking on Shibboleth and cross site scripting. But first the user story:<\/p>\n
User story<\/strong><\/p>\n We have computer labs on campus, some of which are public (any members of the institution can use them) and some of which are “private” – only available for staff and students in certain groups (departments or modules for example). The campus is large, with long walks between buildings so students (and to some extent staff) would like to know which labs have machines that are available for them to drop in and use. \u00a0To complicate matters some labs are also bookable for classes, during which time no machines are available for drop in use.<\/em><\/p>\n The University is also very keen on using single sign on technologies to minimise the number of times that our users are prompted for their username and password. \u00a0We use Shibboleth<\/a> and simpleSAMLphp<\/a> to provide this on campus, and where possible new services should make use of this technology and avoid popping up unnecessary log in dialogues.<\/em><\/p>\n In this case we would like to provide a view of machine availability in the public labs for people that have not authenticated, and a tailored view for people that have got an existing Shibboleth session running. \u00a0We also need to make this available in a dynamic HTML page using RESTful<\/a> APIs because some departments may wish to take the data and mash it up into their own displays and reporting systems.<\/em><\/p>\n Shibboleth and APIs<\/strong><\/p>\n OK, so that’s our user story – the reason why we’re going to need to write some code. Most of the API details aren’t important here – they just talk to back end databases that are populated regularly with details of labs, machine availability and bookings. The APIs then format the data into some nice JSON<\/a> output that the Javascript on the client can turn into pretty HTML.<\/p>\n However we need to tailor the output for the user if they have already authenticated and have active Shibboleth sessions running so that we can show them specific information about the private labs they have access to. \u00a0To do this from client side Javascript is we need to know what username (if any) a Shibboleth session is associated with, so that we can then provide a list of the labs that this person has access to using other API calls.<\/p>\n The obvious first approach was to write a simple CGI API script on a web server that has Apache and mod_shib<\/a> installed. \u00a0The CGI script would be called from the client side Javascript and would get the user’s eppn<\/em> or cn<\/em> details. These come from the environment variables that mod_shib provides. The CGI script would return them in a JSON structure for the client side code to then use. \u00a0The resulting script is quite simple:<\/p>\n The first problem with this is that we also need to support people who aren’t logged in. This appeared to mean that we couldn’t use the common Apache mod_shib config that we use with our other server side Shibbolized CGI script:<\/p>\n Not to worry though: reading the Shibboleth documentation there is an option for “passive” or “lazy” authentication. This means that if a Shibboleth session is active, mod_shib makes use of it to fill in the environment variables with user details as before and approves running the CGI script. Otherwise it just passes authentication back to Apache which can then run the CGI script without the additional Shibboleth variables in the environment. All we need to do is remove the “require valid-user<\/tt>” and change the 1 to a 0 for the requireSession<\/tt> setting. Sounds just what we want, right?<\/p>\n Wrong. What passive Shibboleth authentication lacks is the ability to check with the IdP if there is an existing Shibboleth session known to the web browser that wasn’t made to our web server. Effectively it allows “guest” access to the CGI script, with the option of going through an manual IdP login process if the user wishes to for that one site. Not that it really matters, as it soon became apparent that there were other issues with doing Shibbolized API calls from Javascript.<\/p>\n XMLHttpRequest and CORS<\/strong><\/p>\n OK, so passive authentication in Shibboleth isn’t going to help much here. Lets step back a moment, and put the normal, non-passive mod_shib configuration shown above back in place. If the user has a valid Shibboleth session running, this should give us their user details, otherwise they’ll get an HTML page from the IdP asking them to log in.<\/p>\n However, we want to use this CGI script as an API from Javascript, so we’re going to be calling it using the XMLHttpRequest<\/a><\/tt> object’s methods. Maybe we could make the call and then see what the returned document is? If its JSON with cn<\/em> or eppn<\/em> details we know the user is logged in via Shibboleth. If its an HTML page of some sort, its probably a login or error page from the IdP intended to be displayed to the user, so we know they aren’t logged in.<\/p>\n Now, when we call the API CGI script from XMLHttpRequest<\/tt> we’re actually going to end up with a set of HTTP 302 redirects<\/a> from the API’s server to the IdP server and possibly back again. Effectively one call to a Shibbolized resource may end up as multiple HTTP transactions. This is where Shibboleth stops playing nicely because of cross domain security in Javascript<\/a> in web browsers:<\/p>\n W3C have been working on\u00a0Cross-Origin Resource Sharing (CORS)<\/a> technologies. \u00a0These can help with some of these issues. For example web servers can issues a\u00a0Access-Control-Allow-Origin HTTP Header<\/a> which says which allows suitably equipped modern browsers to over come the Origin checking. \u00a0However these are limited: your server can only have one\u00a0Access-Control-Allow-Origin header value, otherwise browser Javascript interpreters will throw an error. \u00a0You can specify “*” for the\u00a0Access-Control-Allow-Origin header value which gives a wild card match against any Origin, but we found that if you do that browsers then disallow the passing of credentials (including cookies).<\/p>\n So, calling a Shibbolized API from XMLHttpRequest<\/tt> looks like a non-starter. Every time a hand seems to reach out to help us, another hand comes along and slaps us down. \u00a0We need to be sneakier and… well, cruftier.<\/p>\n Evil iframe Hacking<\/strong><\/p>\n Let me just say up front: iframes<\/a> are ugly, are a hack and I’d rather not use them.<\/p>\n However they do offer us the sneaky solution to this problem in that they don’t appear to have some of the restrictions that the XMLHttpRequest<\/tt> calls do. \u00a0Specifically they appear to set cookies for a remote web server based on ones know to the browser and also honour cookie setting during HTTP 302 redirects.<\/p>\n What we can do is create a hidden iframe dynamically using client side Javascript, set an onLoad()<\/tt> handler function up and then point the iframe at our Shibboleth protected API CGI script. It will then do the 302 redirection chain to the IdP and possibly back to the API script and the iframe contents will end up as either a bit of JSON, or the HTML for the login error page from the IdP. In other words unlike XMLHttpRequest<\/tt>, the iframe behaves much more like the web browser session the user experiences.<\/p>\n Our onLoad()<\/tt> handler function can then use this to determine if the user is logged in to Shibboleth or not. There is one more “gotcha” though, and again its related to cross site scripting protection in browsers. If we get a resource in an iframe that comes from the same server as the page that the Javascript was included in, we can peer into the contents of that iframe using Javascript object calls. However if the iframe is filled from another server, our Javascript in the client can’t fiddle with its contents. There’s a good reason for this: you don’t want naughty people including your banking site inside an iframe and then extracting out your account details as you’re using it. This also applies if we request a resource from our server in the iframe but due to HTTP 302 redirects the final document comes from a different server (as will happen if a user who is not logged in gets sent to\u00a0our IdP).<\/p>\n Luckily, in our case we’ve got one hack left up our sleeve. If we try to access the iframe contents that have come from the IdP (which isn’t the server we put in the src<\/em> attribute to the iframe), Javascript in the browser throws an error. However we can use the try-catch error handling mechanism to grab this error. As it only happens when we’ve got a document that hasn’t come from our CGI API script (assuming our CGI API is hosted on the same server as the HTML and Javascript came from), then we know that at that point the user isn’t logged in with a Shibboleth session. We don’t need to see the IdP’s document – the fact that we can’t see it tells us what we need to know.<\/p>\n And we’re there! We can finally have client side Javascript that can deduce whether or not the user’s browser has had any Shibboleth session with our IdP open and if so can find out what the cn<\/em> or eppn<\/em> for the user is. Just for completeness, here’s a test HTML document with embedded Javascript to show that this works – you’ll need to serve it from the same web server as the Perl API CGI script above and modify the iframe.src accordingly.<\/p>\n I’m going to start this blog post with a “user story” – the sort of thing that we use to shape systems design. \u00a0Then I’ll talk about one aspect of the design that this user story gave rise to, and … Continue reading #!\/usr\/bin\/perl
\nuse strict;
\nuse JSON;
\nprint \"Content-type: application\/json\\r\\n\\r\\n\";
\nmy $output = {};
\nforeach my $env_var ('cn', 'eppn') {
\n if($ENV{$env_var}) {
\n $output->{$env_var} = $ENV{$env_var};
\n }
\n}
\nmy $json = new JSON;
\nprint $json->pretty->encode($output);
\n<\/code><\/p>\n<Location \/cgi-bin\/somewhere\/whoami>
\n AuthType shibboleth
\n ShibRequestSetting requireSession 1
\n require valid-user
\n<Location>
\n<\/code><\/p>\n\n
\n<html>
\n <head>
\n <title>Javascript playpen<\/title>
\n <\/head>
\n <body>
\n <button type=\"button\" onclick=\"checkIdp()\">Test against IdP<\/button>
\n <p id=\"response\"><\/p>
\n <script>
\nfunction IsJsonString(str) {
\n try {
\n JSON.parse(str);
\n } catch (e) {
\n return false;
\n }
\n return true;
\n}
\nfunction checkIdp() {
\n document.getElementById(\"response\").innerHTML = '';
\n var iframe = document.getElementById(\"iframe\");
\n if(!iframe) {
\n iframe = document.createElement('iframe');
\n iframe.id = \"iframe\";
\n }
\n iframe.innerHTML = '';
\n iframe.onload = function() {
\n var iframe = document.getElementById(\"iframe\");
\n try {
\n var text = iframe.contentDocument.body.innerText ;
\n } catch (e) {
\n document.getElementById(\"response\").innerHTML = 'Not logged in';
\n return;
\n }
\n if(IsJsonString(iframe.contentDocument.body.innerText)) {
\n var res = JSON.parse(iframe.contentDocument.body.innerText);
\n document.getElementById(\"response\").innerHTML = 'Logged in as ' + res.cn;
\n } else {
\n document.getElementById(\"response\").innerHTML = 'Not logged in';
\n }
\n };
\n iframe.hidden = true;
\n iframe.src = \"https:\/\/www.example.org\/cgi-bin\/ssocheck\/whoami\";
\n document.body.appendChild(iframe);
\n iframe.src = iframe.src;
\n}
\n <\/script>
\n <\/body>
\n<\/html>
\n<\/code><\/p>\n","protected":false},"excerpt":{"rendered":"