Skip to content

Contact Us    Now Hiring

@meritweb on TwitterMerit Solutions on LinkedInMerit Solutions YouTube Video SeriesMerit Solutions on FacebookSubscribe to Merit Matters Blog

   

Windows Azure Access Control Service - Improve User Authentication

Access Control Service is a Windows Azure service that provides an easy way of authenticating users who need to access your web applications and services without having to factor complex authentication logic into your code.

The following features are available in ACS:

  • Integration with Windows Identity Foundation (WIF),
  • Support for popular web identity providers (IPs) including Windows Live ID, Google, Yahoo, and Facebook,
  • Support for Active Directory Federation Services (AD FS) 2.0,
  • An Open Data Protocol (OData)-based management service that provides programmatic access to ACS settings,
  • A Management Portal that allows administrative access to the ACS settings.

Concepts

Windows Azure ACS is built on the principals of claims-based identity - a consistent approach to creating authentication mechanisms for applications running on-premises or in the cloud. Claims-based identity provides a common way for applications and services to acquire the identity information they need about users inside their organization, in other organizations, and on the Internet.

To complete the tasks in this guide, you should understand the following concepts:

Client - In the context of this how-to guide, this is a browser that is attempting to gain access to your web application.

Relying party (RP) application - An RP application is a web site or service that outsources authentication to one external authority. In identity jargon, we say that the RP trusts that authority. This guide explains how to configure your application to trust ACS.

Token - A token is a collection of security data that is usually issued upon successful authentication of a user. It contains a set of claims, attributes of the authenticated user. A claim can represent a user's name, an identifier for a role a user belongs to, a user's age, and so on. A token is usually digitally signed, which means it can always be sourced back to its issuer, and its content cannot be tampered with. A user gains access to a RP application by presenting a valid token issued by an authority that the RP application trusts.

Identity Provider (IP) - An IP is an authority that authenticates user identities and issues security tokens. The actual work of issuing tokens is implemented though a special service called Security Token Service (STS). Typical examples of IPs include Windows Live ID, Facebook, business user repositories (like Active Directory), and so on. When ACS is configured to trust an IP, the system will accept and validate tokens issued by that IP. ACS can trust multiple IPs at once, which means that when your application trusts ACS, you can instantly offer your application to all the authenticated users from all the IPs that ACS trusts on your behalf.

Federation Provider (FP) - IPs have direct knowledge of users, authenticate them using their credentials and issue claims about what they know about them. A Federation Provider (FP) is a different kind of authority: rather than authenticating users directly, it acts as an intermediary and brokers authentication between one RP and one or more IPs. Both IPs and FPs issue security tokens, hence they both use Security Token Services (STS). ACS is one FP.

ACS Rule Engine - The logic used to transform incoming tokens from trusted IPs to tokens meant to be consumed by the RP is codified in form of simple claims transformation rules. ACS features a rule engine that takes care of applying whatever transformation logic you specified for your RP.

Access Control Namespace - A namespace is a top level partition of ACS that you use to organize your settings. A namespace holds a list of IPs you trust, the RP applications you want to serve, the rules that you expect the rule engine to process incoming tokens with, and so on. A namespace exposes various endpoints that will be used by the application and the developer to get ACS to perform its function.  

How does it work?

1. The client (in this case a browser) requests a page from the RP.

2. Since the request is not yet authenticated, the RP redirects the user to the authority that it trusts, which is ACS. The ACS presents the user with the choice of IPs that were specified for this RP. The user selects the appropriate IP.

3. The client browses to the IP's authentication page, and prompts the user to log on.

4. After the client is authenticated (for example, the identity credentials are entered), the IP issues a security token.

5. After issuing a security token, the IP redirects the client to ACS and the client sends the security token issued by the IP to ACS.

6. ACS validates the security token issued by the IP, inputs the identity claims in this token into the ACS rules engine, calculates the output identity claims, and issues a new security token that contains these output claims.

7. ACS redirects the client to the RP. The client sends the new security token issued by ACS to the RP. The RP validates the signature on the security token issued by ACS, validates the claims in this token, and returns the page that was originally requested.

What do you need to get it running?

  • An active Windows Azure account: If you don't have Windows Azure account, you could obtain free trial.


  • Visual Studio 2012: If you want to use latest feature of ACS 2.0 it is recommended using VS2012, but VS2010 could also work with little bit of work.
  • Identity and Access tool: This tool is great add-on for VS2012 which significantly ease connecting ACS with your application.


After few simple steps you should be ready to authenticate users to your application using Windows Azure ACS with identity providers like Microsoft, Google, Facebook etc.

 

Windows 8 development - Process Lifetime Management

If you are a developer, starting to work on a Windows 8 application, one of the really important things to understand is the Process Lifetime Management or PLM. Even if you're not a developer, understanding what really happens when you run a Windows Store application or navigate from it could help you use the app better.

PLM is actually one of the major differences between a Windows 8 application and a desktop application. Unlike traditional Windows applications, which will continue to execute in background, Windows Store apps execute only when they are in the foreground. Windows 8 focuses on the apps in the foreground, keeping them responsive and providing excellent performance by allowing the app to use all of the available device resources. Applications that are snapped are running in foreground, too.

Once a user navigates away from the app, the operating system puts the application in the suspended mode to preserve battery. The application remains in memory but all of its thread are suspended. When the user navigates back to the app, it resumes execution where it stopped and you as a developer can't change this behavior. You don't even have to implement any code to make it happen.

This all seems easy and straightforward, but there is a catch. The operating system cannot guarantee that the application will stay in memory until a user decides to use it again. While the app is suspended, the OS can terminate it to free up additional memory. When an app is terminated, all state that has not been saved is lost. As a developer, you cannot allow for this to happen. Since we are not aware whether the application will be terminated, we must ensure the state is saved when the app is suspended and restore this state in case termination occurs.

But do not despair, Visual Studio 2012 does much of the heavy lifting for you. If your app is not complex, the VS project template takes care of this for you, completely. In the Common folder of your Windows Store app you will find the SuspensionManager.cs. VS added the OnSuspending method and following code to existing OnLaunched method in the App.xaml.cs to save and restore the app’s navigation state if the app was terminated by the operating system after it was suspended.

private async void OnSuspending(object sender, SuspendingEventArgs e)

{

var deferral = e.SuspendingOperation.GetDeferral();
await SuspensionManager.SaveAsync();
deferral.Complete();

}

protected override async void OnLaunched(LaunchActivatedEventArgs args)

{

if (args.PreviousExecutionState == ApplicationExecutionState.Terminated)
{

// Restore the saved session state only when appropriate await SuspensionManager.RestoreAsync();

}

}

In case your application requires anything more sophisticated than this, you will have to implement it yourself, but at least you have a decent starting point. To test how your application behaves when terminated, start the app from Visual Studio and select Suspend and shutdown from the Debug Location toolbar (to activate it, navigate to View > Toolbars > Debug Location).