Access Control Service: Transitioning between Active and Passive Scenarios
- by Your DisplayName here!
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.
