Freigeben über

Azure AD B2C

  • Artikel

Bonjour à tous;

Le 16 Septembre a été annoncé l'arrivée d'une nouvelle fonctionnalité dans Azure AD : le mode B2C et B2B.
Vous pouvez d'ailleurs lire l'annonce sur le blog officiel de l'équipe Active Directory ici : https://blogs.technet.com/b/ad/archive/2015/09/09/azure-ad-b2c-and-b2b-are-now-in-public-preview.aspx 

Aujourd'hui nous allons nous intéresser au modèle B2C.

L'intéret du truc ?

Beaucoup d'entre vous ont déjà utilisé différents SDK pour gérer l'authentification de vos utilisateurs par Facebook, Twitter ou Google+ (ou Microsoft Account ? )

Bien entendu, on a pas attendu ce jour béni pour fournir des services "all in zi-box" pour gérer l'authentification :

  • Mutualisation de ces mécanismes dans Azure Mobile Services.
  • Templates évolués ASP.NET pour gérer le multi auth avec le middleware OWIN
  • Différents SDK clients comme PASSPORT pour Node.js
  • Les SDK ADAL.NET et ADAL.JS pour gérer l'authentification 
  • Et plein d'autres dont je ne me rappelle plus et que vous connaissez suremment

Tout ça fonctionne bien, mais la question qui revient en boucle c'est "On fait quoi des informations de notre utilisateur une fois celui ci connecté ? "

Aujourd'hui, vous allez pouvoir gérer vos utilisateurs dans un annuaire unique, quelque soit le fournisseur d'acès qu'a choisit votre utilisateur.
Avant, il fallait obligatoirement gérer vos utilisateurs depuis votre propre backend (Bon, il faut bien avouer que beaucoup de choses étaient bien automatisées et créés pour vous, et qui masquaient la tuyauterie)

Vous n'avez PLUS besoin de gérer les informations par vous même lors du retour de l'API Facebook, Twitter ou autre. Avant, lors d'une authentification Facebook par exemple, il fallait récupérer les informations de l'utilisateur comme son ID, email, Ville etc ... et les enregistrer dans une base locale ou autre.
Aujourd'hui ce service est fourni par Azure AD B2C.
Mieux, vous allez pouvoir ajouter vos propres champs personnalisés, et c'est encore géré pour vous (et c'est cadeau)

Un meilleur management de vos fournisseurs d'accès. Avant, pour ajouter ou supprimer un fournisseur d'accès externe, il fallait, à m'ment-donné (Copyright Sud Ouest),  mettre les mains dans le camboui et ajouter ou supprimer du code, ne serait-ce que pour faire apparaitre ou disparaitre les boutons de login :)
Aujourd'hui, tout ça est encore une fois géré pour vous.

Plus besoin de paramétrer l'ensemble de vos ClientID / ClientSecret dans votre application, tout ça se fait depuis Azure AD B2C. Cool !

Bref, un véritable concentrateur d'ididentité externe arrive, et va vraiment nous faciliter la vie. Et ça ... c'est swag...

Créer votre AD B2C

Attention : Une limitation "pour l'instant" : Une fois créé, vous ne pouvez plus supprimer votre annuaire (je vous aurai prévenu hein. Pas taper, pas taper, ça va venir)

Attention bis : Une autre limitation : On crée l'annuaire depuis l'ancienne interface (https://manage.windowsazure.com) et on administre depuis la nouvelle interface (https://portal.azure.com) (pas taper touça touça)

Vous vous loguez donc sur l'ancien portail et créé un Azure AD où vous précisez bien que cet AD est un AD B2C :

Une fois créé, tout le reste se passe dans le nouveau portail. Il suffit donc de cliquer sur Gestion des paramètres B2C pour ouvrir le nouveau portail :

et hop !

A partir de là, il ne reste plus qu'à configurer :)

Applications

Vous crééz une application (un peu comme sur Facebook ou Twitter ou Microsoft Account) qui sera de type Web App / Native Client.
C'est cette application seule qui sera à configurer depuis votre application mobile ou votre site web (c'est elle qui fédère tous les autres)

Lorsque vous crééz votre application, n'oubliez pas de noter votre Application Client Id et votre App key (on dit souvent Client Secret aussi)

Identity Providers

Ici vous allez empiler les fournisseurs que vous voulez utiliser pour authentifier vos utilisateurs.
Ce qui est TRES BIEN ici c'est que vous ajoutez et configurez vos fournisseurs, mais vous n'êtes pas obligé de tous les utiliser (dans un premier temps)
Globalement on ajoute des fournisseurs et on les utilise ... ou pas (sans être obligé de les supprimer)

Chaque fournisseur doit être configuré. Voici une documentation récente sur comment ça marche :

  1. Facebook : https://azure.microsoft.com/en-gb/documentation/articles/active-directory-b2c-setup-fb-app/
  2. Google+ : https://azure.microsoft.com/en-gb/documentation/articles/active-directory-b2c-setup-goog-app/ 
  3. Amazon : https://azure.microsoft.com/en-gb/documentation/articles/active-directory-b2c-setup-amzn-app/ 
  4. Linked IN : https://azure.microsoft.com/en-gb/documentation/articles/active-directory-b2c-setup-li-app/ 

Oui je sais, il manque encore Twitter ou Microsoft Account (pas taper ...) ça va venir !

Attributs personnalisés

Encore un truc bien cool et bien pensé. Par défaut vous allez pouvoir utiliser des champs pour ajouter de la valeur au profil de votre utilisateur. De base évidemment, on a des champs disponibles comme le mail, nom, ville, User Object ID etc...

Mais vous pouvez en ajouter à volonté. Pour le moment, on est limité à des chaines de caractères. On peut imaginer un champ Fidility Points, représentant des points de fidélité (imagination débordante de votre serviteur ...) 

Policies ou Règles de sécurité

Tout ce que nous avons fait jusque là représente de la configuration. C'est maitenant que nous allons vraiment utiliser notre application /  fournisseurs / champs perso. pour créer une expérience d'authentification. Mais pas que ...

Comme on l'a vu, on va avoir la possiblité de manager nos utilisateurs : S'inscrire, Se signer, Modifier son profil, Faire un reset de son mot de passe etc ...

Pour chaque grande famille, nous allons créer des "policies". Appelons ça des règles de sécurité :

  1. Une règle pour l'inscription
  2. Une règle pour l'authentification
  3. Une règle pour l'édition du profil

Chaque règle va comporter plusieurs choix :

  1. Quelle application ? (cette application qui contient ClientId / ClientSecret)
  2. Quels fournisseurs ? Un ou plusieurs (Classique, Facebook, Google+ etc ...)
  3. Quels attributs on veut exposer / récupérer ? (On va voir ça en détail)
  4. Est-ce que l'authentification multifacteur doit être activée ?
  5. Comment personnaliser la page exposée ?

Règle pour l'inscription : Sign Up Policy

Cette règle doit exécuter plusieurs choses:

  1. Exposer les fournisseurs s'il y a plus d'un.
  2. S'authentifier auprés du fournisseur et récupérer les champs que vous avez configuré.
  3. Proposer des champs de saisie pour les champs qui ne sont pas proposés par le fournisseur.

Pour mon exemple, je décide de créer une règle qui expose tous les fournisseurs, je la nomme ALL (A postériori j'aurai dû l'appeler ALL_SIGN_IN, vu que les noms de policies doivent être uniques)

Si demain, vous decidiez de ne plus utiliser par exemple le fournisseur Google+ il suffit juste de le décocher ici, et vous n'avez pas besoin de reconfigurer / recompiler votre application :) good !

Attributs : Ils représentent les éléments que vous voulez utiliser pour enrichir le profil de votre utilisateur. Dans mon cas, je veux au moins gérer les champs "Ville", "Nom d'usage", "Email" et mes fameux "FidelityPoints" :

Applications Claims : Ici on paramètre les champs qu'on veut récupérer par le fournisseur : Evidemment tous les fournisseurs ne fournissent pas tous les champs, mais on peut tout de même tenter :)

Dans mon cas, je sais que Facebook me récupère facilement la ville, email, given name, alors on va pas se priver ! Des champs intéressants comme le User Object ID ou le User Is New peuvent aider..

Testage  (C'est toulousain, cherchez pas) : A partir de là (et après avoir sauvegardé), on peut déjà tester le comportement de notre page d'inscription (bouton Run Now) !

Voici l'enchainement des écrans dans mon cas :

(J'ai zappé l'étape "Vérification du Mail" qui vous envoie un code par mail pour vérifier toute inscription "fake")

Aprés la création, nous sommes redirigés vers l'application / site web hôte, que nous n'avons pas encore créé. Ne vous étonnez pas d'avoir une 404 au bout :)

Comment vérifier que cet utilisateur existe ? Et bien, il suffit d'aller dans votre annuaire fraichement créé (depuis l'ancien portail, pas taper, touça touça)

Bon évidemment là, on voit deux comptes m'appartenant, le premier est le compte admin de l'AD, le deuxième ... mon test ! Mais vous imaginez bien le truc.

Et evidemment si on regarde le détail de ce nouvel utilisateur, on voit trés bien l'intéret de ce système :

Règle pour l'authentification et Règle pour l'édition du profil / Sign In policy & Editing policy

Ces deux règles se paramètrent de la même manière que la précédente. On règle les fournisseurs, et les éléments qu'on présente et qu'on veut récupérer dans le Token de retour.

Au final, je me retrouve avec mes trois règles paramétrées :

Note : Les noms de règles étant uniques, j'aurais suremment dû appeler la première règle ALL_SIGN_UP (le B2C_1_ étant ajouté automatiquement par le système)

Et voici l'expérience utilisateur, en test.

S'authentifier :

Modifier son profil :

Intégrer ce système dans votre application Web

Aujourd'hui, les templates Visual Studio ne sont pas forcément à jour. Le mieux reste encore de prendre un exemple existant, et de l'adapter.

Vous trouverez sur le Github de l'équipe Azure AD les exemples adéquates : https://github.com/AzureADQuickStarts.
Dans notre cas, j'utilise celui ci : https://github.com/AzureADQuickStarts/B2C-WebAPI-DotNet 

Pour le faire fonctionner, il suffit "juste" de paramétrer correctement le fichier de configuration :

  1. ClientId
  2. Tenant
  3. Policy de Sign Up
  4. Policy de Sign In
  5. Policy d'Edit

Une copie d'écran de mon fichier de configuration :

That's ALL !

Bon, vous remarquerez quand même qu'il y a un peu de code dans le sample...

A noter :

  1. Fichier Startup.Auth.cs Où vous allez paramétrer votre middleware Owin pour utiliser l'authentification OpenId / Oauth2
  2. Répertoire PolicyAuthHelpers : Celui là on va pas l'inventer, il permet de gérer les règles exposés par OpenId
  3. Class AccountController : Les appels aux urls d'authentification / inscription / édition de profil
  4. Vue Claims.cshtml : L'énumération des "Claims" exposés par votre fournisseur Azure AD B2C

Voici, une fois connecté, la page Claims, récapitulant les propriétés que j'ai paramétrées et que je veux récupérer aprés authentification :

Vous noterez que je récupère bien mon nombre de points fidélité :)

Bref, une bien belle nouveauté qui arrive et qui va VRAIMENT permettre de mutualiser la gestion de l'identité, sans être obligé de rajouter son propre système à coté pour gérer tout ce qui n'est pas authentification et qui est pourtant si important :)

Pour les ressources, dont est bien inspiré l'article de votre serviteur :  https://azure.microsoft.com/en-us/services/active-directory-b2c/ 

Happy coding !

Seb

Comments

  • Anonymous
    October 30, 2015
    Rassurez vous, je vais pas vous tapez. Mais simplement vous ignorez tant que vous vous obstinerez à écrire des articles sur des produits et/ou technologies qui sont inutlisables.

  • Anonymous
    November 01, 2015
    C'est peut être parce que vous n'avez jamais tenté de les utiliser ?