As I mentioned in my last post, ACS features a number of ways to transition between protocol and token types. One not so widely known transition is between passive sign ins (browser) and active service consumers. Let’s see how this works.

We all know the usual WS-Federation handshake via passive redirect. But ACS also allows driving the sign in process yourself via specially crafted WS-Federation query strings. So you can use the following URL to sign in using LiveID via ACS. ACS will then redirect back to the registered reply URL in your application:

GET /login.srf?
  wa=wsignin1.0&
  wtrealm=https%3a%2f%2faccesscontrol.windows.net%2f&
  wreply=https%3a%2f%2fleastprivilege.accesscontrol.windows.net%3a443%2fv2%2fwsfederation&
  wp=MBI_FED_SSL&
  wctx=pr%3dwsfederation%26rm%3dhttps%253a%252f%252froadie%252facs2rp%252frest%252f

The wsfederation bit in the wctx parameter indicates, that the response to the token request will be transmitted back to the relying party via a POST.

So far so good – but how can an active client receive that token now?

ACS knows an alternative way to send the token request response. Instead of doing the redirect back to the RP, it emits a page that in turn echoes the token response using JavaScript’s window.external.notify. The URL would look like this:

GET /login.srf?
  wa=wsignin1.0&
  wtrealm=https%3a%2f%2faccesscontrol.windows.net%2f&
  wreply=https%3a%2f%2fleastprivilege.accesscontrol.windows.net%3a443%2fv2%2fwsfederation&
  wp=MBI_FED_SSL&
  wctx=pr%3djavascriptnotify%26rm%3dhttps%253a%252f%252froadie%252facs2rp%252frest%252f

ACS would then render a page that contains the following script block:

<script type=”text/javascript”>
    try{
        window.external.Notify(‘token_response’);
    }
    catch(err){
        alert(“Error ACS50021: windows.external.Notify is not registered.”);
    }
</script>

Whereas token_response is a JSON encoded string with the following format:

{
  “appliesTo”:”…”,
  “context”:null,
  “created”:123,
  “expires”:123,
  “securityToken”:”…”,
  “tokenType”:”…”
}

OK – so how does this all come together now?

As an active client (Silverlight, WPF, WP7, WinForms etc). application, you would host a browser control and use the above URL to trigger the right series of redirects. All the browser controls support one way or the other to register a callback whenever the window.external.notify function is called. This way you get the JSON string from ACS back into the hosting application – and voila you have the security token.

When you selected the SWT token format in ACS – you can use that token e.g. for REST services. When you have selected SAML, you can use the token e.g. for SOAP services.

In the next post I will show how to retrieve these URLs from ACS and a practical example using WPF.