Mobile Enterprise Application. Step 2: Authentication

This is a second post in the series. Previous post:
 - Step 1: General Architecture

Authentication - as in supplying proper user credentials - is an essential part of any enterprise application. Consumer apps and games usually allow unauthenticated users to execute them, but enterprise systems have higher security requirements. So, your login page is likely to be set in WMAppManifest.xml as default task:

    <Tasks>
      <DefaultTask Name ="_default"
            NavigationPage="/Views/LoginPage.xaml"/>

    <Tasks>

It's not difficult to put together a simple page with two text boxes and a button, then make a web service call to verify user credentials and return an object containing user context. However, there are a couple of things to consider.

Push Notifications Opt-In
Push Notification Service (PNS) is a powerful tool that allows your server application to initiate communication with the client even while the client isn't running. There is no equivalent functionality on the desktop or in web applications; it is one of the unique features of the mobile client. I'm sure any enterprise system could use PNS, and in my next post I will show how to implement it. Normally, you would register a user for push notifications as soon as he or she authenticates. However, according to Windows Phone 7 Application Certification Requirements, the application must ask the user for explicit permission to receive a toast notification. Once the opt-in is obtained from the user, it can be saved in isolated storage settings. Below is a code snippet that checks settings and redirects user accordingly:

   NavigationService.Navigate(
      IsolatedStorageSettings.ApplicationSettings.Contains(Constants.Settings.CanUsePNS)
         ? new Uri(Constants.Urls.LandingPage, UriKind.Relative)

: new Uri(Constants.Urls.PNSOptInPage, UriKind.Relative));


Session Management
Authentication usually implies a time-limited user session. Unlike ASP.NET, which is a server-side platform, Silverlight doesn't provide session management features out of the box. My recommended approach for mobile application is to implement a dual session management mechanism along these lines:

1. Client ask user for a preferred session duration (not to exceed a predefined system limit) before login
2. Client successfully authenticates, and server returns a unique session token (a GUID, for instance)
3. Client keeps session state in the isolated storage
4. Every time the application is activated, it checks if session length has exceeded timeout
5. Every time the client makes a webservice call, it includes the session token as a parameter. Server uses it to validate the session and optionally create an audit trail of user activity.

Restoring Session State On Activation

When application is running, session state is stored in a public static property of the App class (App.xaml.cs), for example:

   public static UserLogin CurrentUser { get; set; }

However, the value goes away when application becomes inactive (again, this is unique behavior of mobile clients) and we need to restore it as part of reactivation:

   1:  private void Application_Activated(object sender, ActivatedEventArgs e)

   2:  {

   3:      if (AppController.CurrentUser == null)

   4:      {

   5:          using (var store = IsolatedStorageFile.GetUserStoreForApplication())

   6:          {

   7:              if (store.FileExists(Constants.Files.UserLogin))

   8:              {

   9:                  using (var file = new IsolatedStorageFileStream(Constants.Files.UserLogin, FileMode.Open, store))

  10:                  {

  11:                      var serializer = new DataContractSerializer(typeof(UserLogin));

  12:                      AppController.CurrentUser = (UserLogin)serializer.ReadObject(file);

  13:                  }

  14:              }

  15:          }

  16:      }

  17:  }

(to be continued)