Archives mensuelles : août 2016

Découverte Azure AD B2C

Ça faisait quelques temps que qu’Azure B2C trainait en Preview, le service est maintenant officiellement disponible, donc officiellement utilisable en production, avec un cadeau, la facturation ne commencera qu’en 2017 :). Le pricing est basé sur deux critères :

  • Le nombre d’utilisateurs
  • Le nombre d’authentification

C’est une facturation par palier. Dès lors qu’on est en dessous des 50000 utilisateurs et 50000 authentifications, autant dire que le service est gratuit. Attention quand je dis gratuit car les services dépendants tel qu’Azure Multi-Factor Authentication eux ne le seront pas. L’aspect le plus ennuyeux étant clos, passons maintenant aux réjouissances. Pour rappel, Microsoft avait mis en Preview deux services :

  • Azure B2C (l’objet de ce billet)
  • Azure B2B (qui lui est encore en Preview)

 

Présentation du service

Pour faire simple Azure B2C va nous proposer un système de gestion des utilisateurs externes / consommateurs, pour une application Web (mais pas que) avec toute les fonctionnalités que cela implique (inscription, gestion de profil, réinitialisation de mot de passe, …), bref tout un ensemble de services qui vont faciliter la vie de nos développeurs. A l’opposé Azure B2B est destiné aux mêmes applications mais pour le contexte Business to Business. Voilà pour le positionnement d’Azure B2C. Intégrer l’authentification à une Web App, ce n’est pas nouveau (Expanding App Service Authentication/Authorization), on sait déjà le faire. Par contre, cela nous impose de développer tout ce qui va autour :

  • Le formulaire d’inscription
  • Le formulaire d’authentification
  • Le formulaire pour permettre aux utilisateurs de mettre à jour leur profil
  • Le formulaire pour réinitialiser le mot de passe
  • L’intégration avec nos applications

Bref, être responsable de tout cela et surtout coupable (le leaking de mots de passe est à la mode en ce moment et il n’épargne personne), c’est pas forcément ce qu’on recherche. Au final, ce serait bien si on avait un service capable de prendre en compte tous ces points en proposant en plus de prendre en charge des fournisseurs d’authentifications tiers (Facebook, Linkedin, Google+ Live ID, …), des trucs modernes donc. Tout ce que je viens d’énumérer sont des fonctionnalités D’Azure AD B2C.

Prérequis

Pour les besoins de la démonstration, j’ai retenu la Web Application. J’ai mis en place une Web App et le App Service qui lui est associé, le tout dans un groupe de ressources comme illustré ci-dessous :

clip_image001

Note : La feature Application Insight s’est glissé dans la configuration. Le problème, c’est qu’actuellement en Preview, elle n’est pas encore disponible dans la région West Europe.

Ma Web Application est tout ce qu’il y a de plus classique. La commande PowerShell : Get-AzureWebsite -Name b2Cwebapplication | select name, sku,state, enabled, EnabledHostNames, HostNameSslStates va nous fournir l’information essentielle :

clip_image002

L’information essentielle, c’est l’url de cette WebApp : https://b2cwebapplication.azurewebsites.net/. C’est à cette URL que le service Azure AD BC2 va rediriger les requêtes après inscription, authentification ou mise à jour de profil.

Mise en place

Pour l’instant, la création et la gestion des instances du service Windows Azure Active Directory dépendent encore de l’ancien portail. C’est donc dans celui-ci que nous allons créer une nouvelle instance du service Azure AD. Ce qui a changé par rapport à la Preview, c’est qu’on est plus obligé de créer un nouveau tenant Windows Azure Active Directory. On peut aussi conserver son tenant existant. Tout de suite, on y voit un intérêt immédiat de réutiliser des comptes existants.

clip_image003

Pour cette démonstration, j’ai retenu la création d’une nouvelle instance Azure Active Directory dont je suis moi-même devenu administrateur. J’ai aussi créé un premier utilisateur tout ce qu’il y a de plus classique.

clip_image004

Dans l’onglet Configure, on va découvrir un lien nommé « Manage B2C Settings ».

clip_image005

Maintenant on découvre que cela ne se passe plus dans l’ancien portail mais bien dans le nouveau portail, ce qui est une excellente nouvelle. Déclarer une application dans Azure AD, c’est quelque chose que nous avons déjà vu dans le billet Découverte d’Azure Disk Encryption (Preview). Par contre, c’est maintenant dans le nouveau portail que cela se passe. Mon application étant de type Web, il est logique que la case soit cochée. J’ai aussi référencer l’URL de mon application.

clip_image006

De cette interface, nous conservons deux choses :

  • L’Application ID
  • La clé de l’application

Ces informations seront essentielles pour configurer notre application. Azure B2C est un service d’authentification configurable à plusieurs niveaux :

  • La politique d’enregistrement (Sign-up policy)
  • La politique d’authentification (Sign-In policy)
  • La politique de gestion du profil (Profile Policy)
  • La politique de réinitialisation de mot de passe (Password Reset Policy)
Sign-up policy

C’est la politique d’enregistrement. On y référence les éléments suivants. Le ou les fournisseurs d’authentification que nous allons proposer à l’enregistrement (uniquement le mail pour commencer). Les deux autres sont visibles car au moment de la rédaction de ce billet, j’avais commencé la configuration d’autres fournisseurs.

clip_image007

Notre choix, c’est un enregistrement par mail pour commencer. Prochaine étape, la sélection des attributs que nous allons exiger de l’utilisateur pendant son enregistrement. On notera que ce sont des attributs Built-In. Cela signifie que l’on peut aussi demander d’autres informations.

clip_image008

Au terme de l’enregistrement, un jeton d’accès sera généré à destination de l’application. Il contiendra les informations suivantes :

clip_image009

La subtilité, c’est l’attribut « User Is new » qui permettra de traiter différemment la création d’un profil de la mise à jour d’un profil pour notre application. On pourrait exiger l’utilisation de Multi-Factor Authentication ou personnaliser la page d’enregistrement mais pas besoin de compliquer les choses pour une découverte.

Sign-In Policy

La politique d’authentification va reprendre les mêmes éléments que pour la politique d’enregistrement. On peut choisir :

  • Le ou les fournisseurs d’authentification à prendre en compte pour le formulaire d’authentification
  • Les attributs à intégrer au Claims qui sera généré et mis à disposition de notre application
  • La durée de vie de notre token et la configuration du SSO entre plusieurs applications
  • Le fait d’exiger l’authentification Multi-Factor pour notre application
  • La personnalisation de l’interface graphique mise à disposition des utilisateurs

 

Profile Policy

C’est le même principe que pour les politiques précédentes mais pour gérer l’interface de configuration du profil qui sera mise à disposition des utilisateurs. Au terme de la mise à jour, un jeton d’accès sera mis à disposition de l’application.

Password Reset Policy

L’interface de réinitialisation de mot de passe est valable uniquement pour le fournisseur d’identité Local Account. Pour les autres, c’est sous la responsabilité des fournisseurs respectifs (LinkedIn, Facebook, Google, …).

clip_image010

Attention, la politique de mot de passe applicable ainsi que la capacité de réinitialiser eux même leur mot de passe est lié au tenant Windows Azure AD B2C.

clip_image011

Après, encore faut-il que les utilisateurs aient renseigné une adresse de messagerie alternative :

clip_image012

 

C’est fini pour la partie mise en place. On va s’attaquer maintenant à Visual Studio.

Intégration Web Application

C’est maintenant que commence la phase développement. Là j’ai eu un peu d’aide ici : Azure AD B2C: Sign-Up & Sign-In in a ASP.NET Web App. Au début, j’ai commencé avec cet exemple disponible sur GitHub . Problème, n’étant plus dans la branche développement depuis bien longtemps (environ 15 ans), ça a été compliqué, je suis un peu rouillé en C#. J’ai donc pris un raccourci avec un package complètement opérationnel, lui aussi disponible sur GitHub. La toute la configuration tiens en quelques ligne du fichier « Web.Config » de notre Web Application. La cela me parle beaucoup plus. Nous devons référencer les points suivants :

  • Tenant : le nom de la souscription Windows Azure active Directory
  • ClientID : l’identifiant unique de notre application
  • RedirectUri : L’URL de redirection de notre application.
  • SignUpPolicyId : Le nom de la politique de Sign-up à utiliser avec notre application
  • SignInPolicyId : Le nom de la politique de Sign-in à utiliser avec notre application
  • UserProfilePolicyId : Le nom de la politique de profil à utiliser avec notre application

 

clip_image013

Y a plus qu’à sauver et builder. C’est maintenant qu’on va savoir si cela fonctionne. Mon instance App Service est déjà opérationnelle dans Azure, prête à accueillir mon package Web Deploy.

clip_image014

Mon instance se nomme b2Cwebapplication, c’est celle que j’avais créé en prérequis.

clip_image015

Visual Studio s’occupe de tout. Avec mes credentials il organise la publication de mon package Web Deploy.

clip_image016

On va direct en prod, pas de staging slot.

clip_image017

 

Expérience de l’enregistrement d’un nouvel utilisateur

Une fois l’application publiée, on peut aller faire un tour à l’URL https://b2cwebapplication.azurewebsites.net/. La première chose qui saute aux yeux, c’est que d’un point de vue design, ça ne casse pas trois pattes à un canard. En même temps, ce n’est pas le but et vous n’êtes pas arrivé jusqu’à ce paragraphe pour cela. Ce qui nous intéresse, c’est la barre en haut.

clip_image018

Si on clique sur « Sign up », alors la politique d’inscription que nous avons configurée devrait apparaître. Il nous faut prouver notre identité. Après avoir renseigné notre adresse email, on clique sur le bouton « Send verification code ». Le code nous est communiqué par mail. Nous n’avons qu’à le renseigner et cliquer sur le bouton « Verify ».

clip_image019

Tant que j’ai pas cliqué sur le bouton « Verify », pas possible d’aller plus loin. Ce n’est qu’une fois mon identité vérifiée qu’on va pouvoir finaliser la création du nouvel utilisateur dans le tenant Windows Azure Active Directory :

SignupPolicyExperience1

Dans l’application, il est maintenant bien référencé que je suis authentifié et reconnu :

clip_image021

 

Si on regarde sous la moquette (dans le tenant Azure AD B2C), on constate bien un nouvel utilisateur.

Get-MsolUser | Where {$_.DisplayName -eq « Simple by design but Business compliant »} | Format-List -Property Displayname, Userprincipalname, PostalCode, UserType, WhenCreated

clip_image022

On peut tester le formulaire d’authentification (Sign-in policy). Avec un seul fournisseur (Azure Active Directory), l’interface est des plus austères.

clip_image023

L’utilisateur peut mettre à jour les attributs dans son profil. Dans ma politique, j’avais indiqué que l’utilisateur pouvait modifier :

  • Son Code postal
  • Son Display Name
  • Son Pays

clip_image024

Si on va regarder ce qu’on a en PowerShell avec le module Azure AD.

$Cred = Get-Credential

Connect-msolservice -credential $cred

get-msoluser | where {$_.UserPrincipalname -eq « b2ccustomer@b2csimplebydesign.onmicrosoft.com »} | format-

list -Property Userprincipalname, Displayname, PostalCode, country

clip_image025

Ça correspond à ce que l’utilisateur a renseigné dans son profil. Pour finir, le lien Claims permet de consulter le Claims constitué et mis à disposition de notre application.

clip_image026

 

C’est une découverte rapide. Il y a encore beaucoup à dire sur le sujet Azure B2C. Quand je vais avoir un peu de temps, on s’attardera sur des sujets tel que :

  • L’utilisation d’autres fournisseurs d’authentification (Google, Facebook, LinkedIn)
  • L’utilisation d’attributs personnalisés dans le profil des utilisateurs

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)