Authentification des locataires de Windows Azure Pack avec ADFS (1/7)

Toujours là? Vous en redemandez? Vous avez trouvé cela très "simpliste". OK, élevons un peu le niveau, j’annonce : Web Application Proxy, fournisseur d’identité de confiance seront les nouveaux instruments de torture. J’ai sorti le chevalet, prenez place. Le bourreau va s’occuper de vous.

clip_image001

 

Si on avait fait l’impasse sur le Web Application Proxy (WAP aussi je sais) pour le portail des administrateurs, on ne peut plus y couper pour les locataires. Coté tenant, c’est un peu plus compliqué. Pour les administrateurs, nous utilisions l’annuaire Active Directory "Windowsazurepack.lan" comme fournisseur d’identités. Pour nos locataires, notre fournisseur d’identité par défaut, c’est ASP.Net membership, qui est pris en charge par le module AuthSite de Windows Azure Pack. En plus de fournir l’authentification de nos locataires, il offre deux fonctionnalités importantes :

  • L’enrôlement des locataires en libre-service (Le Sign-up en haut de la page)
  • La réinitialisation de mot de passe (lien forgot password)

clip_image002

 

Mettre en place une authentification ADFS pour nos locataires, cela veut dire que nos locataires auront une mire d’authentification ressemblant à celle-là :

clip_image003

 

C’est un peu plus léger. Certes on peut habiller la chose (merci Maxime Rastello), mais il manque quand même nos "Sign-up" et "Forgot Password". C’est un peu logique. Si nous mettons en place une authentification ADFS, c’est que nous avons un Identity Provider derrière (Active Directory par exemple) et c’est lui qui est en charge des opérations de provisionning d’identité pas Windows Azure Pack. Pareil pour le "Forgot Password". Pour corser un peu plus la chose, un portail de Windows Azure Pack, ne peut utiliser qu’un seul fournisseur d’identité.

C’est un peu bloquant. Dans un scénario de type "Hosting provider", on aimerait bien pouvoir proposer aux locataires de pouvoir venir avec leur propre identité (implique qu’il disposent d’un Security Token Server correctement configuré pour générer des jeton d’accès consommables par Windows Azure Pack) ou d’utiliser une identité tierce. Pour arriver à ce résultat, un moyen, c’est d’avoir plusieurs portails pour les locataires de Windows Azure Pack. Avec cette approche, on pourrait avoir :

  • Un portail grand public
  • Un portail dédié aux entreprises
  • Des portails personnalisés pour les entreprises

Windows Azure Pack autorise cette souplesse. Il est effectivement possible d’avoir plusieurs instances du portail des locataires, chacune d’entre elle utilisant un fournisseur d’identité distinct. C’est une démarche qui est documenté dans cette série de billets : Azure Pack Tenant portal extensibilities.

clip_image004

Pour l’instant, je laisse cette solution de côté. On va déjà voir ce qu’implique une mise en œuvre plus traditionnelle pour nos locataires.

 

Un peu de réflexion pour commencer

Déjà posons-nous la question : Pouvons-nous nous contenter du fournisseur d’identité ASP.Net Membership? Voyons cela de plus près :

  • Auto-enrôlement des utilisateurs : Chaque utilisateur peut venir lui-même créer son propre compte. Celui-ci peut être automatiquement approuvé ou soumis à approbation. Cependant, c’est une identité supplémentaire à gérer pour l’utilisateur. De plus, si coté fournisseur nous devons fournir le service pour tous les utilisateurs d’une entreprise qui a souscrit le service, chaque utilisateur devra s’enrôler manuellement.
  • Gestion de son identité : A part désigner des Co-administrateurs et gérer les certificats d’accès, la gestion des identités vu du locataire est on ne peut plus sommaire. En même temps, c’est pas la fonction première de Windows Azure Pack.

clip_image005

  • Réinitialisation de mot de passe : L’utilisateur peut changer son mot de passe de lui-même et même le réinitialiser. Un mail lui sera envoyé pour générer un nouveau mot de passe. C’est pas mal pour des utilisateurs individuels mais pour des entreprise, c’est un peu limité (pas de jeu de question/réponse, politique de mot de passe spécifique par population, …).

clip_image006

  • Enfin, la gestion des comptes des locataires de Windows Azure Pack : C’est ce qu’il y a de plus sommaire, y a pas plus d’options que celles présentes dans l’interface ci-dessous :

clip_image007

 

Au final, le fournisseur d’identité ASP.Net Membership assure un service minimum. En même temps, c’est pas là qu’on attendait Windows Azure Pack. Ce qu’on attend de lui, c’est d’être capable de s’interfacer avec un autre fournisseur d’identité. C’est certainement pour ces raisons que Microsoft nous recommande d’utiliser un fournisseur d’identité tiers pour nos locataires. ADFS est le premier choix qui vienne à l’esprit. En même temps, c’est la solution la plus simple à mettre en œuvre.

 

Prenons un peu de hauteur

On a déjà abordé le sujet coté Administrateurs, coté locataires, c’est presque la même chose. La seule différence, c’est que le jeton ne sera pas généré par notre infrastructure ADFS (windowsazurepack.Fr) mais par l’infrastructure ADFS de notre locataire, laquelle nous reconnaissons le statuts de fournisseur d’identité. Coté infrastructure, voilà ce que cela donne :

clip_image008

 

Ça commence à piquer les yeux. Et encore, j’ai fait le choix d’utiliser l’infrastructure ADFS déjà existante (sans haute disponibilité) pour l’authentification de mes futurs locataires. C’est tout à fait envisageable tant que nous pouvons bien distinguer les différents fournisseurs d’identité avec des suffixes UPN bien distincts. C’est sur ce point que ça va devenir fun.

Une fois en place, la cinématique de connexion sera la suivante :

  1. Un utilisateur au sein d’un de nos locataires veut accéder au portail https://tenantportal.windowsazurepack.fr
  2. Le portail constatant l’absence de jeton va le renvoyer vers notre infrastructure ADFS (En fait, c’est même le Web Application Proxy qui va se charger de cela)
  3. L’infrastructure ADFS (windowsazurepack.Fr) demande à l’utilisateur de renseigner son adresse de messagerie ou la notation UPN de son compte
  4. En fonction des données renseignées, notre infrastructure ADFS va identifier le suffixe UPN et rediriger l’utilisateur vers l’infrastructure ADFS du locataire pour authentification
  5. L’infrastructure ADFS du locataire va authentifier l’utilisateur et générer un jeton d’accès signé pour l’utilisateur en sollicitant l’annuaire Active Directory du locataire comme fournisseur d’identité
  6. L’infrastructure ADFS du locataire va renvoyer l’utilisateur vers le portail https://tenantportal.windowsazurepack.fr pour que celui consomme le jeton
  7. Le portail sollicite l’infrastructure ADFS de Windows Azure Pack pour délivrer un nouveau jeton en utilisant les informations contenues dans celui qui a été généré par l’infrastructure ADFS de notre locataire (notion de confiance dans le fournisseur d’identité)
  8. L’infrastructure ADFS de Windows Azure Pack renvoie l’utilisateur vers le portail https://tenantportal.windowsazurepack.fr pour que celui-ci exploite le jeton signé

 

Si nos clients ne disposent pas encore d’une infrastructure ADFS, on va les aider. Sur cette partie, j’ai pas de plus-value, le travail a déjà été très bien fait et c’est en français. C’est du Next-Next-Finish direct dans Azure :

 

Après, cela va se dérouler en plusieurs étapes que je vais publier progressivement :

 

Prêt pour le début de la séance? Patience, ça arrive. Détendez-vous, …

 

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

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.