Introduction

Dans la première partie de cette série d’article consacrée à l’authentification Windows Azure Active Directory (WAAD) dans les applications d’entreprises, je décrivais les différents scénarios d’utilisation de cette brique proposée par Azure, ainsi que le processus de création d’applications depuis le portail Windows Azure.

Dans cette seconde partie, je vais traiter des applications ASP.NET MVC / Web API, avec deux objectifs principaux :

• La mise en place de SSO au niveau de l’application ASP.NET MVC
• La sécurisation d’une Web API via WAAD

Mise en place du SSO WAAD dans un nouveau projet d’application MVC

Si vous devez démarrer un nouveau projet d’application ASP.NET MVC 5 sous Visual Studio 2013, la mise en place de l’authentification Windows Azure Active Directory est une étape assez triviale, puisque Visual Studio propose désormais une intégration complète de ce scénario, à l’aide d’assistant graphique qui font à peu près tout le travail à notre place Ayant déjà traité ce sujet dans un billet transverse il y a quelques temps, si vous êtes dans ce cas, je vous invite à le consulter ici.

Mise en place du SSO WAAD dans un projet d’application MVC existant

Si vous ne démarrez pas un nouveau projet sous Visual Studio 2013 et que vous n’avez pas la chance de pouvoir utiliser l’assistant de configuration, ce n’est pas bien grave : il est assez simple de configurer une application existante pour travailler avec Azure Active Directory.

La première chose que vous devez faire est de créer une application sur votre tenant WAAD. Cette étape est décrite dans la première partie de cette série d’articles. Ensuite, toute la configuration se fait directement dans le fichier Web.config de l’application (ou presque!).

Pour commencer, vous allez devoir ajouter des références vers System.IdentityModel.dll et System.IdentityModel.Services.dll au projet :

Vous aurez également besoin d’une librairie pour la validation des tokens émits par Azure Active Directory. Celle-ci est disponible sous la forme d’un package NuGet : System.IdentityModel.Tokens.ValidatingIssuerNameRegistery.

Ajoutez les éléments suivants à la section system.web (la créer si elle n’existe pas) :

<system.web>
  <authentication mode="None" />
  <authorization>
    <deny users="?" />
  </authorization>
  <compilation debug="true" targetFramework="4.5" />
  <httpRuntime targetFramework="4.5" requestValidationMode="4.5" />
</system.web>

Vous pouvez désormais rajouter les sections de configurations system.identityModel et system.identityModel.Services à votre Web.config :

<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

C’est dans ces sections que vous allez configurer l’authentification via Windows Identity Foundation.

Tout d’abord system.identityModel :

<system.identityModel>
  <identityConfiguration>
    <audienceUris>
      <add value="https://monwaaddanstoncloud.onmicrosoft.com/EbookManager.FrontOffice" />
    </audienceUris>
    <securityTokenHandlers>
      <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    </securityTokenHandlers>
    <certificateValidation certificateValidationMode="None" />
  </identityConfiguration>
</system.identityModel>

Puis system.identityModel.services :

<system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/monwaaddanstoncloud.onmicrosoft.com/wsfed" realm="https://monwaaddanstoncloud.onmicrosoft.com/EbookManager.FrontOffice" requireHttps="false" />
    </federationConfiguration>
</system.identityModel.services>

Enfin, il est nécessaire de rajouter deux modules à la section system.webServer :

<modules>
  <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
  <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
</modules>

Avant de tester l’application, il est nécessaire de rajouter un dernier élément à l’application : la configuration d’un “issuer name registry”. Ajoutez une classe qui dérive de “ValidatingIssuerNameRegistery” à votre projet. Surchargez la méthode IsThumbprintValid. Pour le moment, renvoyez “true” :

public class MyIssuerNameRegistry : ValidatingIssuerNameRegistry
{
    protected override bool IsThumbprintValid(string thumbprint, string issuer)
    {
        return true;
    }
}

Attention, en aucun cas le code précédent doit partir en production !

Cette classe est là pour valider que le certificat qui a été utilisé pour signer le token et bien valide pour l’issuer du certificat en question ! Une bonne pratique consiste à récupérer régulièrement le certificat de signature depuis le fichier de publication des métadonnées XML exposées par le tenant, de calculer son thumbprint et de le stocker quelque part (en base de données par exemple).

Rajoutez alors la définition de votre IssuerNameRegistry dans la section system.identityModel/identityConfiguration dans le Web.Config :

<issuerNameRegistry type="WebApplication9.MyIssuerNameRegistry, WebApplication9" />

Si vous avez bien configuré l’application côté waad et votre application web, l’authentification devrait fonctionner sans souci :

Une fois authentifiez, vous pouvez alors récupérer l’identité de l’utilisateur sous la forme d’une ClaimsIdentity, directement sur la propriété Current du ClmailsPrincipal :

Vous pouvez alors récupérer les différents Claim qui caractérisent  votre utilisateur !

Sécurisation d’une Web API avec Windows Azure Active Directory

La sécurisation d’un Web API avec WAAD est un peu plus simple à mettre en place que ce que nous avons vu dans la section précédente, tout simplement parce que Microsoft propose une méthode d’extension à la configuration http, comme pour les autres fournisseurs d’identité. Attention, ce package est toujours en RC, il faut donc indiquer à la console NuGet d’inclure les pre-releases :

Et le bout de code pour configurer WebAPI via Owin :

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.UseWindowsAzureBearerToken(new WindowsAzureJwtBearerAuthenticationOptions()
        {
            Audience = "https://monwaaddanstoncloud.onmicrosoft.com/WebApplication10",
            Tenant = "monwaaddanstoncloud.onmicrosoft.com"
        });
    }
}

Et voilà, votre Web API est désormais capable d’accepter des requêtes http en mode authentification Bearer, dans lequel on passe un token JWT obtenu auprès de WAAD pour s’authentifier !

Conclusion

Dans ce billet, nous avons vu comment utiliser Windows Azure Active Directory pour sécuriser une application ASP.NET MVC et un service Web API !

Dans le prochain billet, nous verrons comment consommer cette Web API depuis un client Windows Store 8.1 avec authentification Windows Azure Active Directory !

A bientôt

Julien