Tag Archives: AJAX

Making Ajax play with Passive ADFS 2.1 (and 2.0) – Reactive Authentication

The first post, described the issue of using ADFS and Ajax to create SSO between a WebApp and a WebAPI. This solution looks at the changing the WebAPI to return 401 if the request is not authorized and then using an iFrame to authenticate the user for subsequent calls.

The last solution, pre-authorized on the first AJAX call per page load, which adds some overhead. This was because JSONP has no means of returning status codes (this is not entirely true, you can return a 200 and then have the real response inside a payload, but that is beyond this article). This solution makes use of normal AJAX calls and 401 responses to perform authorization only when it is required.

Caveats

  • This uses normal AJAX calls, so it requires CORS to be enabled on the WebAPI server for cross-domain requests. (See this guide)
  • IE8 & 9 do not support the passing of cookies with cross domain requests and therefore this method will not work as described. However, it should be possible to pass the token in the body of the AJAX request (use POST and HTTPS to maintain security) and write a customized AuthenticationModule to read the token and provide it to the WSFederatedAuthenticationModule. (This is outside the scope of this solution however)

Solution

By default, the WSFederationAuthenticationModule redirects the user to ADFS if the user is not currently authenticated (there is no valid session cookie). This can be changed with the following code

FederatedAuthentication.WSFederationAuthenticationModule.AuthorizationFailed += (sender, e) =>
{
    if (Context.Request.RequestContext.HttpContext.Request.IsAjaxRequest())
    {
        e.RedirectToIdentityProvider = false;
    }
};

By adding this code to ApplicationStart, or a HttpModule, we can make the WebAPI return a HttpStatus of 401 every time authentication is required (during an AJAX request). We then handle this response in our javascript.

The following Gist shows some javascript that handles the 401 response and then uses the idea of authenticating in a iFrame from the last solution, before retrying the AJAX call. The second attempt should now have the needed session cookies to authorize and succeed.

[gist https://gist.github.com/thejuan/4e535a0c468fa47fd9cc]
Advertisements
Tagged , , ,

Making Ajax play with Passive ADFS 2.1 (and 2.0) – JSONP & Pre-Authentication

The first post, described the issue of using ADFS and Ajax to create SSO between a WebApp and a WebAPI.
This solution looks at using JSONP and pre-authentication to achieve SSO between sites on different domains.

Solution Overview

We add a html page (or handler) to the WebAPI solution.
Whenever we make a call to the WebAPI we first load the html page in an iFrame, this iFrame call handles all the ADFS redirects and sets the session cookies for the WebAPI.
These session cookies are then sent (automatically) with the next JSONP call to the server.

Caveats

  • Like all the solutions, this expects that the user has authenticated with ADFS via the WebAPP. When the iFrame hits the WebAPI pre-auth html page and the request gets redirected to ADFS if the user already has a session (that is compatible with the WebAPI relying party) a token will be issued without further authentication.
Tagged , , , ,

Making Ajax play with Passive ADFS 2.1 (and 2.0) – The Problem

The Problem

ADFS is Microsoft’s Federated Identity Service, but if you are reading this you probably know that.
You may also know that the way it does passive authentication doesn’t work well with Ajax calls.

Below is a fiddle that shows the steps involved in authenticating a request for an ASPX page (that page belongs to the awesome Communica) protected by ADFS. This process happens the first time a request is made to an application, after that the authentication information is stored in a cookie (by default named FedAuth if you are using WIF)

Image

Request 37 responds with Http Status code 200 (ok); the response is a payload of secret information that is submitted to the return url (your application) via javascript that submits the returned form (circled above).

This is fine when we are in a browser as the browser runs the javascript happily and submits the form. Everything is dandy. Unfortunately in an Ajax world the first Http Status of 200 is presumed to be the response and the call is never completed as intended.

This is only a problem if your application is entirely an API. If it is a mixed API/Web Application your user will be authenticated when they load the application. Any subsquent call by your application to API endpoints will already have a session and will not perform the ritual outlined above.

However, if like me, you have a 100% API based application and you are attempting to enable SSO with other applications, then there is some work to be done.

In the next posts I’ll look at 3 possible solutions:

Tagged , , , ,

UpdatePanel and Rendered (Inline) Javascript

It seems that the UpdatePanel essentially replaces the InnerHTML of  a DIV with the delta returned from the server. If you try this yourself you will notice that any javascript elements in the html are not fired.

All javascript registered on the server-side (if you are using .NET) with the ScriptManager is put into a separate section of the returned delta. The atlas runtime obviously then loads these scripts into the document manually.

What if the returned HTML has Javascript tags already rendered in it? Nothing. 😦
Such was our predicament and we had no control over the HTML that would be returned to the UpdatePanel (ReportViewer Control). Could we manually load the javascript ourselves when the UpdatePanel returns the payload? As it turns, we could.

You can create script elements on the fly and they get evaluated as you do. Atlas has the ScriptLoader object that will do it for you if your JavaScript is an external reference. Tweaking this idea we got a solution that found all the new Script elements and added them to the document.

The code is below; the scriptLoader was taken from this post.
The main thing to know is that a script element has a text property that can be modified.
The atlas scriptloader sets the src property whilst the innerHTML and innerText properties are readonly.

Continue reading

Tagged , , ,