Authentication in WP7 client with REST Services–Part I

In the last drop, we included a sample that demonstrates how to secure a REST web service with ACS, and a client calling that service running in a different security realm:

In this case, ACS is the bridge between the WS-Trust/SAML world (Litware in the diagram) and the REST/SWT side (Adatum’s a-Order app)

This is just a technical variation of the original sample we had in the book, that was purely based on SOAP web services (WS-Trust/SAML only):

 

But we have another example in preparation which is a Windows Phone 7 Client. Interacting with REST based APIs is pretty popular with mobile devices. In fact is what we decided to use when building the sample for our Windows Phone 7 Developer Guide.

There’s no WIF for the phone yet, so implementing this in the WP7 takes a little bit of extra work. And, as usual, there’re many ways to solve it.

The “semi-active” way:

This is a very popular approach. In fact, it’s the way you’re likely to see this done with the phone in many samples. It essentially involves using an embedded browser (browser = IE) and delegate to it all token negotiation until it gets the token you want. This negotiation is nothing else than the classic “passive” token negotiation, based on HTTP redirects that we have discussed ad infinitum, ad nauseam.

The trick is in the “until you get the token you want” . Because the browser is embedded in the host application (a Silverlight app in the phone), you can handle and react to all kind of events raised by it. A particular useful event to handle is Navigating. This signals that the browser is trying to initiate an HTTP request to a server. We know that the last interaction in the token negotiation (passive) is actually posting the token back the the relying party.  That’s the token we want!

 

So if we have a way of identifying the last POST attempt by the browser, then we have the token we need. There are many ways of doing this, but most look like this:

In this case we are using the “ReplyTo” address, that has been configured in ACS with a specific value “break_here” and then extract the token with the browser control SaveToString method. The Regex functions you see there, simply extract the token from the entire web page.

Once you’ve got the token, then you use it in the web service call and voila!

With this approach your phone code is completely agnostic of how you actually get the final token. This works with any identity provider, and any protocol supported by the browser.

Here’re some screenshots of our sample:

The first one is the home screen (SL). The second one shows the embedded browser with a login screen (adjusted for the size of the phone screen) and the last one the result of calling the service.

JavaScript in the browser control in the phone has to be explicitly enabled:

If you don’t do this, the automatic redirections will not happen and you will see this:

You will have to click on the (small) button for the process to continue. This is exactly the same behavior that happens with a browser on a desktop (only that in most cases scripting is enabled).

In next post I’ll go into more detail of the other option: the “active” client. By the way, this sample will be posted to our CodePlex site soon.

Comments

• Anonymous
  March 24, 2011
  Eugenio I believe there's a somewhat similar sample in acs.codeplex.com doing the same thing. I've been hacking it for my own WCF REST service, but not quite finished. Looking forward to that source code.

• Anonymous
  March 24, 2011
  That is correct Chris. There's one difference though: they add a new method to the service to return the SWT. We intercept the last redirect and get the SWT from the browser. This means one less roundtrip. But you are right, the principles are exactly the same.