The Surveys service running in Windows Azure needs to know the identity of the user who is using the mobile client application on the Windows Phone 7 device for two reasons. First, when the mobile client requests a list of surveys, the service determines the contents of the list based on the preferences stored in the user’s profile. Second, when the mobile client submits a set of survey answers, the Surveys service needs to record who submitted the survey in order to be able to calculate any rewards due to the user.
Goals and Requirements
Tailspin wants to externalize as much as possible of the authentication and authorization functionality from the main Surveys application. This will give Tailspin the flexibility to make changes to the way they handle authentication and authorization in the future without affecting the Surveys application itself. For example, Tailspin may want to enable users to identify themselves by using a Windows Live® ID.
It’s also important to ensure that the mechanism the mobile client uses to authenticate is easy to implement on the Windows Phone 7 platform and any other mobile platforms that Tailspin may support in the future.
Overview of the Solution
Figure 1 shows a high-level view of the approach adopted by Tailspin.
The approach that Tailspin adopted assumes that the Windows Phone 7 client application can send credentials to the Surveys web service in an HTTP header. The credentials could be a user name and password or a token. Tailspin could easily change the type of credentials in a future version of the application.
Note: In the sample application, the phone sends a user name and password to demonstrate this approach. The mobile client does not perform any validation on the credentials that the user enters on the AppSettingsView page or encrypt the credentials before it saves them in isolated storage. In a real application, you may decide to enforce a password policy that requires strong passwords and regular password renewals.
In the Surveys web service, the custom authentication and authorization interceptor extracts the header that contains the user’s credentials and identifies an authentication module to perform the authentication. It’s possible that different client platforms use different authentication schemes, so the interceptor must be able to identify from the HTTP headers which type of authentication is being used, and then pass the credentials to the correct custom authentication module.
Note: The sample application uses a mock authentication module that simply checks for one of several hard-coded user names; it does not verify the password. If you use password-based credentials in your application, you should send a hashed version of the password over the network to compare with a hashed version stored in Windows Azure storage in your authentication module.
After the custom authentication module validates the credentials, it uses Windows Identity Foundation (WIF) to construct an IClaims Principal object that contains the user’s identity. In the future, this IClaimsPrincipal object might contain additional claims that the Surveys application could use to perform any authorization that it requires.
The surveys web service includes the IClaimsPrincipal.Claims. Name value when it invokes any methods in the Tailspin Surveys core application. The Tailspin Surveys core application returns data for the user. In the future, the web service could also perform any necessary authorization before it invokes a method in the core application.