I wanted to offer my take on important changes I perceive at Microsoft.

Pastel Became Passe

Microsoft is evolving to stay relevant within a technological oligarchy ruled alongside Google, Apple, Amazon, Facebook. Like the movie, Miami Vice, whose protagonists Sonny and Tubbs were transformed as gritty, cerebral and laconic -- in stark contrast to their original, television counterparts -- Microsoft realized that Yesterday's Microsoft would not survive Today. Beyond survival, in order to thrive the company must transform.

And indeed Bob, Clippy, Rover and the faceless, androgenous, interspecific progenitor that spawned them were euthanized; collateral damage of self-reinvention. Here's a highlight of other changes at Microsoft that separately may go unnoticed but together redefine the company's direction moving forward:

The Tree Isn't Far from the Apple

Microsoft finally beat Apple at design (once) and is refocusing efforts to improve user experience -- comparatively its most-glaring software deficiency. Is Microsoft also stumbling along the way? Undoubtedly -- while also improving.

Ammunition and Now Guns

With the acquisition of Nokia's devices and service division and release of the Surface family of consumer hardware products Microsoft is suddenly also a devices company. While still lagging behind the likes of Samsung and Sony, it is playing ball on the same field as the big leaguers.

Sharing is Caring

Microsoft has embraced open source software development as a value. More on this and why it maters later.

Their Foot In More Doors

Microsoft is invading living rooms -- Xbox continues to position the company within the increasingly unsettled consumer entertainment market prior to the (inevitable) collapse of cable TV. The acquisition of Yammer affords Microsoft social networking capabilities within B2B which it already dominates; heretofore a space that LinkedIn has championed uncontested.

E Pluribus Unum

Even Microsoft products and brands, a perpetually disparate spaghetti, are transcending into integrated service offerings (Office, Visual Studio are now available on the Cloud -- XBox on Azure, common UX between Windows phone and Windows etc) that play nicely with eachother. Additionally, at long last the branding of these product offerings is consistent!

"Steve? Steve Who?"

Microsoft hired a new CEO - only the third in its history. Gone is the bombastic, odd Steve Ballmer; in his place a pragmatic, 'more efficiently designed' engineer Satya Nadella.

In Summary the transformative reinvention of Microsoft, a company long considered awkward and uncool, is occuring:

There's Just One More Thing...

Is this perspective into the transformation of Microsoft profound? No. However, I believe the changes the company is making are deserving of notice. This capable, overlooked Microsoft might just be the Coloumbo that solves the mystery of how to succeed across a myriad of competitive landscapes where others have not; the Cladius that ascends to power, the Steve Urkel who hits a game winner.

My next post will center upon developing enterprise software on Microsoft's tech stack from the context of these evolving paradigms.

This is the first in a series of posts focusing on two .Net development technologies: Azure Active Directory (AAD) and NancyFx (aka Nancy). Nancy has emerged as a scalable web-development framework affording what it labels the "Super Duper Happy Path" (SDHP) for simplistic creation of web applications. AAD is a Azure/cloud-hosted directory service supplying authentication as a service (SaaS). We are securing a Nancy web application with AAD; the code presented in this series is available here.

• In Part I: Azure Active Directory Configuration we configure a new AAD tenant for our use
• In Part II: AAD From a Nancy Web Application we take the first steps to integrate a Nancy web application with AAD
• In Part III: Nancy Statless Authentication With AAD we implement Nancy's stateless authentication to leverage AAD

Part I: Azure Active Directory Configuration

This post covers the setup and configuration of a new Azure Active Directory account and tenant to support our use within a new web application.

Authenticating Users

Verifying that a person who wants access to secured resources should be allowed access typically necessitates substantial development effort to support; within the context of a web application:

1. First we would create a UI view to support accepting a user id and password.
2. Next we might create a database repository holding all authorized user names and passwords against which to verify those credentials.
3. Finally our application requires logic to determine whether or not this particular user has required authorization and handle each case accordingly.

...or instead we can offload this work to AAD -- a cloud-hosted directory service which can manage such burdens as a proxy on behalf of our application. Think of AAD as the security officer blocking access to a Customs checkpoint within the international arrival section of an airport. Without valid proof of your identification (passport) as well as authorization to enter the country (ie citizenship, travel visa etc) you will not be permitted entry. In similiar manner AAD can restrict access to our application.

As an added incentive this service is practically free (seriously!).

Configuring an Azure Active Directory Account and Tenant

(Before continuing be sure you have an active Windows Azure account)

In order for AAD to handle authentication for our application we need to create an AAD tenant within which applications and authorized users that access them are configured. An AAD tenant can be conceptualized as an ecosystem containing users and applications that interact. Users within the tenant have access to applications within that tenant; furthermore such applications may be configured to allow interactions between eachother as trusted clients.

An important concept to understand is that in order for a user or application to interact with components of the tenant ecosystem it must first exist within it. Another useful way to conceptualize a tenant as a domain - in fact an AAD tenant is often reffered to as an (Active Directory) domain.

Create a new Active Directory Account & Tenant

1. Login to the Windows Azure Management portal.
2. Navigate to the "Active Directory" section using the navigation bar.
3. Create a new Active Directory account and tenant using the ADD icon.

4. Within the "Add directory" dialog populate the following:

   • DIRECTORY = Create new directory
   • NAME = MyOrganization
   • DOMAIN NAME = [SOMEAVAILABLENAME].onmicrosoft.com
   • COUNTRY OR REGION = [YOUR COUNTRY]

   NOTE: AS OF THIS WRITING ACTIVE DIRECTORY ACCOUNTS & TENANTS CANNOT BE DELETED OR RENAMED AFTER CREATION. WHILE THIS IS PLANNED TO CHANGE, IN THE MEANTIME PICK "SOMEAVAILABLENAME" THAT WON'T BOTHER YOUR OCD TOO MUCH.

What do did was create an Active Directory Account (named NAME) containing a tenant (DOMAIN NAME). An AAD Account can house multiple tenants:

Add a User to Your AAD Tenant

One of the benefits of AAD is that it can be synced with an on-premises Active Directory to leverage existing user information. In this tutorial though we will manually create a user within our tenant to use throughout the rest of this blog series.

1. Within the "Active Directory" section of the Windows Azure Management portal select the AAD Tenant we created above.
2. Navigate to the "USERS" tab and click the ADD USER icon.
3. At the "Tell us about this user" prompt populate the following:
   
   • TYPE OF USER = New user in your organization
   • USER NAME = Test@YOURTENANTNAME.onmicrosoft.com
   • At the "user profile" prompt dialog populate the following:
   • FIRST NAME = Testy
   • LAST NAME = Testo
   • DISPLAY NAME = Lord Testington
   • ROLE = Global Administrator
4. At the "ADD USER Get temporary password" prompt click the create button.
5. Select the newly-created user and overwrite the temporary password with a strong password that is easily rememberable.

Add an Application to Your AAD Tenant

After creating a user within our tenant we also need to configure information about the application we want AAD to provide user authentication for. Here's how:

1. Within the "Active Directory" section of the Windows Azure Management portal select the AAD Tenant we created above.
2. Navigate to the "APPLICATIONS" tab and click the "ADD" icon.
3. Click "Add an application my organization is developing".
4. Enter NAME=WebApp and select "WEB APPLICATION AND/OR WEB API" before clicking the ->
5. At the "ADD APPLICATION App properties" dialog populate the following:
   
   • APP URL = http://localhost:1234 [the url of your Nancy Web App]
   • APP ID URI = https://YOURTENANTNAME.onmicrosoft.com/WebApp
6. At the "ADD APPLICATION Directory access" dialog populate the following:
   
   • SINGLE SIGN-ON
7. After creation navigate to "CONFIGURE" and modify the Reply URL of the application to be http://localhost:1234/Authenticated this is the url that will be called after a user has been authenticated by AAD. Click the SAVE icon to persist changes.
8. At the very bottom of the application's configuration you’ll see a list of the Web APIs provisioned within the same tenant. If you have none, this would be a good opportunity to create one for testing purposes. You can do that by repeating the steps in this block while altering steps 4 & 5 to reference instead "WebAppResource". After creation, specify WebAppResource is a WEB API ACCESSED BY THIS APPLICATION from the WebApp configuration page. Click the SAVE icon to persist changes.
9. There's one more piece of information we need to configure for use in part II; we will generate a shared key that our application will use to prove to AAD that it is trusted (by us). You can generate this key within the WebApp tenant configuration inside the "keys" section:

One...

Three...

After generation copy and paste the key to a temporary notepad++ document because upon renavigation it will be hidden (but you can generate a new one):

Now you should have two applications configured within your tenant like so:

Conclusion

This post covered the necessary configurations for Azure Active Directory to support authentication on behalf of a web application (that we have yet to create). In the next post, part II, we will create a simplistic NancyFx web application and use AAD to authorize users.

This is the second in a series of posts focusing on two .Net development technologies: Azure Active Directory (AAD) and NancyFx (aka Nancy). Nancy has emerged as a scalable web-development framework affording what it labels the "Super Duper Happy Path" (SDHP) for simplistic creation of web applications and APIs; AAD is a Azure/cloud-hosted directory service affording native client and web client application authentication as a service (SaaS). We are securing a Nancy web application with AAD; the code presented in this series is available here.

• In Part I: Azure Active Directory Configuration we configure a new AAD tenant for our use

Part II: AAD From a Nancy Web Application

This post covers the creation of a new Nancy web application that will leverage the AAD configurations we created in part I to authorize users to access secured resources.

Make a Nancy Web Application

1. Within Visual Studio create a Console Application named "WebApp".
2. Install the Nancy.Hosting.Self nuget package.

3. Add a reference to Nancy.Hosting.Self and within Program.Main add the following:

   using (var host = new NancyHost(new Uri("http://localhost:1234")))
   {
      host.Start();
      Console.ReadLine();
   }
   

4. Add a new class named SampleModule.cs to handle an HTTP request to the default route:

   public class SampleModule : Nancy.NancyModule
   {
      public SampleModule()
      {
         Get["/"] = _ => "Hello World!";
      }
   }   
   

   This class inherits NancyModule -- the mechanism by which Nancy handles HTTP verbs to different places. Our project now looks like this within Visual Studio:

F5 to launch the console application and navigate to http://localhost:1234/ to see Nancy say "Hello World!"

Integrating AAD into our Nancy Web Application

Now that we have AAD configured and a functional web application it's time to integrate them.

Create a new class within WebApp.csproj named AADHelper containing the following boiler plate code that will be used to leverage AAD from within our web application:

public static class AADHelper
{
  public static string GetAuthorizationURL()
  {
    string authorizationUrl = string.Format("https://login.windows.net/{0}/"+
    "oauth2/authorize?api-version=1.0&response_type=code&client_id={1}&"+
    "resource={2}&redirect_uri={3}",
    AAD.TENANT_ID,
    AAD.CLIENT_ID,
    AAD.APP_ID_URI,
    AAD.REPLY_URL);
    return authorizationUrl;
  }          
  public struct AAD
  {
    public static readonly string TENANT_ID  
    = "????????-????-????-????-????????????"
    public static readonly string CLIENT_ID  
    = "???????????????????????????????";
    public static readonly string APP_ID_URI 
    = "https://?????.onmicrosoft.com/WebAppResource";
    public static readonly string REPLY_URL  
    =  "http://localhost:1234/Authenticated";
    public static readonly string CLIENT_KEY 
    = "???????????????????????????????";
  }        
}

Before proceeding populate the variables within the "AAD" struct to match those of your own AAD configuration. Here's where to locate them:

• TENANT ID - an Azure Active Directory "tenant" (aka Domain) which is identified by us as a key (which can be found via) :
  • Azure Management Portal ->
    • Active Directory ->
      • Applications ->
        • View Endpoints (at the bottom, center of the screen) the TENANT_ID appears sandwiched within the various end point urls as a guid-like key
• CLIENT ID - this is the Client ID for the WebApp (we configured within AAD in Part I).
• APP ID URI - this is the APP ID URI for WebAppResource (we configured within AAD in Part I).
• REPLY URL - this is the Reply URL for the WebApp
• CLIENT KEY - This is the 'secret' configured within AAD to associate the calling code with the configured application. We configured this in part I within the "keys" section of our WebApp application.

Create a Secure Nancy Module

A good first step in securing access to our web application is to block unknown parties from accessing private information. Let's do this within WebApp.csproj by creating a new NancyModule with some simple security logic to accomplish this. Create a new class named SecureModule.cs :

    using Nancy;
    using Nancy.Responses;
    using System;

    public class SecureModule : NancyModule
    {
        Before += ctx =>
        {
            return ctx.CurrentUser == null ||
                   String.IsNullOrWhiteSpace(ctx.CurrentUser.UserName)
                ? new RedirectResponse("/login")
                // else allow request to continue unabated
                : null;
        };

        public SecureModule()
        {
            Get["/Private"] = _ =>
            {
                return "Secret stuff!";
            };
        }
    } 

We created a new HTTP route, "/Private" that will execute when a user navigates to http://localhost:1234/Private -- but notice the code block beforehand starting with Before +=. This code is invoked before each HTTP request within this NancyModule (only) reaches its destination. It redirects requests from unidentified users to a "/login" route. Only if the initiating request is associated with a valid user it is allowed to continue to its destination.

We haven't yet coded support for a /Login route that unauthenticated users are redirected to; let's do so now because this is where the rubber hits the road between our Nancy Web Application and AAD.

Invoke AAD Login Screen From our Web App

Now our application supports redirecting an unidentified client to /login. Let's take it a step further and utilize AAD to present a login dialog to authenticate users against those AAD configurations we previously defined.

Add a new HTTP route within the SampleModule.cs file we created within WebApp.cs (below Get["/"] ... "Hello World!";):

    Get["/login"] = _ =>
    {
      return new Nancy.Responses.
      RedirectResponse(AADHelper.GetAuthorizationURL());
    };

Now when a user is redirected to this /login route the web browser will redirect a client to be authorized by the AAD tenant we point it to. F5 the application and navigate to http://localhost:1234/login to see what happens. If everything is configured correctly you will be prompted with a web dialog page asking you to sign in.

There are a couple of things to notice about this web dialog.

1. The address for this page is served from login.microsoftonline.com ; this isn't anything from within our WebApp or Nancy - this page is served as a callback by AAD to our browser redirection within /login.
2. Multiple account credentials are visible. My hotmail address is there in addition to a user I have for an AAD tenant. If I login with either of these credentials I will not be provided authorization to the WebApp. This is because these two accounts/users do not exist within our WebApp tenant on AAD. They are outside of our application's ecosystem.

Try to sign in using various usernames and passwords; you will notice that AAD prohibits you from proceeding further until you enter a valid login for a user and password authorized for the WebApp (that we configured within our tenant in part I). Only after logging in with "Test@YOURTENANTNAME.onmicrosoft.com" and the associated password will you be allowed to continue (be sure to logout of any other associated microsoft accounts that might be cached within your browser).

This is great! AAD is basically playing the part of a guard dog on our behalf. It stonewalls any attempt to access our web application until a user proves he should be permitted access by providing valid user credentials associated with the applicable AAD tenant's configuration.

After providing correct credentials for the user we previously configured, you will be redirected to the following screen:

What looks like an error actually isn't - this is success! It means that AAD effectively authenticated a user and redirected him to the REPLY_URL configured for our WebApp (see part I); unfortunately we haven't configured a route within our SecureModule.cs that matches "/Authenticated" -- ergo Nancy's cute 404 monster cartoon. Take a look at something else -- AAD sent us an authorization "code" as a query parameter as well.

Things are starting to get fun here - what is this mysterious code? What will we do with it? What part does Nancy play?

Conclusion

In this post we created a NancyFx web application, referenced AAD tenant configuration we initialized in part I and leveraged AAD to authorize clients. What comes next is to more fully integrate security behavior between Nancy and AAD. We do that next in part III.

This is the third in a series of posts focusing on two .Net development technologies: Azure Active Directory (AAD) and NancyFx (aka Nancy). Nancy has emerged as a scalable web-development framework affording what it labels the "Super Duper Happy Path" (SDHP) for simplistic creation of web applications. AAD is a Azure/cloud-hosted directory service supplying authentication as a service (SaaS). We are securing a Nancy web application with AAD; the code presented in this series is available here.

• In Part I: Azure Active Directory Configuration we configure a new AAD tenant for our use
• In Part II: AAD From a Nancy Web Application we took the first steps to integrate a Nancy web application with AAD

Part III: Integrating Nancy Stateless Authentication with AAD

This post covers further integration of the AAD configurations we created in part I with the Nancy web applciation we created and part II . We will be leveraging Nancy's support for stateless authentication to secure our web application's content. This affords a simplistic, low-overhead implementation to allow only trusted users access.

Handling AAD's Returned Authorization code

We ended part II with AAD invoking a callback to the configured RETURN_URL "/Authenticated" along with a query parameter representing an authorization code. Let's add functionality to the WebApp.csproj to use this authortization code to retrieve the identity of a user invoking our application.

Handling AAD's RETURN_URL Callback

In order to catch the callback redirection from AAD to "/Authenticated" create a new route within WebApp.csproj's SecureModule.cs:

        Get["/Authenticated"] = _ =>
        {
            return "Hello " + Context.CurrentUser.UserName + "!";
        };

If you F5'd the application you will enter into a redirect loop and never reach the inside of the "/Authenticated" route -- do you know why?

Remember the other code at the top of our SecureModule() :

        Before += ctx =>
        {
            return ctx.CurrentUser == null ||
                   String.IsNullOrWhiteSpace(ctx.CurrentUser.UserName)
                ? new RedirectResponse("/login")
                // else allow request to continue unabated
                : null;
        };

Even though AAD is dialing back to our /Authenticated route with an authorization means that the current user was identified by AAD as being authorized for access - Nancy still hasn't associated the incoming request (from AAD) with an authorized user. Because of this AAD's callback (and authorization code) will be rebuffed and redirected back to the /login route. How ironic!

In order to fix this unexpected behavior we will call in some backup in the form of a Nuget package.

Integrating Nancy's Stateless Authentication

We will use Nancy's stateless authentication to consume the authorization code returned by AAD to determine a user's identity. Once Nancy knows an incoming request is associated with a real user (or not) application security logic is breezy; however there's a little more work involved to before we get there.

1. Add the "Nancy.Authentication.Stateless" Nuget package to WebApp.csproj. This package adds support for authenticating a request eachtime it is handled by Nancy without the overhead of database or session persistance.
2. Create a new class within WebApp.csproj called Bootstrapper.cs containing the following:

I apologize for the image in place of code - ghost blogging hates my code formatting -- but there is a link to all the source code at the end

The function of this code is to override Nancy's default behavior in order to inject stateless authentication into every request that the application handles. The RequestStartup method is invoked prior to every request that Nancy handles.

The interesting part comes here:

var authorizationCode = (string)nancyContext.Request.Query.code;
return AADHelper.GetAuthenticatedUserIDentity(authorizationCode);

We are grasping the authentication code (remember -- that AAD returned to us) and using it to retrieve a user identity from AAD. Unfortunately the magic method we call here to do that doesn't yet exist. Let's write it.

Retrieving Identity from AAD

I already let the cat out of the bag - that mysterious authentication code that AAD sent us back in part II provides the ability to retrieve a user's identification. That's its secret. Mystery solved. Let's use the token (and AAD) to do just that.

1. Add the Nuget package Microsoft.IdentityModel.Clients.ActiveDirectory to WebApp.csproj. This is the Active Directory Authentication Library (ADAL) -- the .Net library for consuming AAD's SaaS offerings. You can conceptualize ADAL as a telephone for requesting AAD information from within a consuming application.
   
   • You might say "wait a second we already used AAD to show our user a login screen without ADAL!" Well we sort of did; if you look back to part II what we actually did was hack an oauth2 URI containing our AAD tenant.
2. Open the AADHelper.cs class and add a using reference to Microsoft.IdentityModel.Clients.ActiveDirectory.
3. Add a new method at the bottom of the class:
   

Before proceeding let's resolve the missing reference to this method's UserIdentity dependency. Add a new class to WebApp.csproj named UserIdentity.cs:

using Nancy.Security;
using System.Collections.Generic;
using Microsoft.IdentityModel.Clients.ActiveDirectory;

namespace WebApp
{
    public class UserIdentity : IUserIdentity
    {
        public UserIdentity(UserInfo userInfo)
        {
            UserName = userInfo.UserId;
        }

        public string UserName { get; set; }
        public IEnumerable<string> Claims { get; set; }
    }
}

This class is just an adapter which converts ADAL's UserInfo object into an implementation of IUserIdentity -- an interface which Nancy works off of for authentication.

Now we're all hooked up to retrieve a user's identity from AAD using the authorization token provided by AAD and then integrate it into Nancy's stateless authentication. Let's watch it in action.

Let it Rip

• Within the WebApp.csproj add a Visual Studio breakpoint to the following line of Bootstrapper.cs:
• F5 the application and navigate to http://localhost:1234/Private. Your previous login credentials should be cached within your browser (if not login with the test user we configured back in part I). You will hit the above breakpoint after AAD has authorized you and passed back an authorization code thusly:

• F11 to step into the GetAuthenticatedUserIDentity method:

  
  As you continue to the end of the method you'll see that we have UserInfo returned from AAD. We convert this into a UserIdentity object (ala our adapter) and return it from the method.

• Press Shift+F11 to return to Bootstrapper.cs

  
  From the context of Nancy's stateless authentication we are consuming the returned UserIdentity and associating it with the current HTTP request (remember we are in the RequestStartup method that is invoked prior to each handled request).

• Press F10 to continue along the request's path through Nancy. Since the destination is /Authenticated (the RETURN URL configured within AAD back in part I) - the request will next be handled within SecureModule.cs.

Remember the Before += ctx => code that is invoked within SecureModule before a request is handled in order to redirect unauthenticated requests (see part II)?

This time around Nancy has a user associated with the incoming request. This is the user we configured within our AAD Tenant back in part1.

Because Nancy has an authenticated user associated with the request it continues unabated through Before += ctx => and on to its destination (as we configured within AAD as the RETURN URL back in part I).

• The request ends up here:

And outputs the user's name to the browser window:

Congratulations you've just setup a Nancy web application with stateless authentication to leverage Azure Active Directory's authentication service!

Extra Credit

Handling Errors From AAD

Add the following code to the top of SecureModule's Before += ctx => to handle errors returned from ADAL's AcquireTokenByAuthorizationCode method to aid debugging:

            if (ctx.Request.Query.error.HasValue)
            {
                string errorDesc = 
                    string.Format("{0}\n\n{1}\n\n{2}",
                    ctx.Request.Query.error,
                    ctx.Request.Query.error_description);

                Context.Response            = Response.AsText(errorDesc);
                Context.Response.StatusCode = HttpStatusCode.Forbidden;
                return Context.Response;
            }                

Conclusion

In this post we integrated the work from part I and part II to support stateless authentication within Nancy using AAD and Microsoft's ADAL library. You can obtain the source code we created in this series from this git repo. Where possible obfuscated complexity (and confusion) that being said there is a lot going on; hoprfully this series of posts will give you a good introductory context to dive deeper and learn more about authorization, authentication, AAD and NancyFx.