Windows Azure Pack – Les fondations de l’authentification Admin-side

Vous avez aimé « Windows Azure Pack–Les APIs publiques des locataires« ? Parfait. Ce n’était que la surface des choses. Maintenant on va rentrer dans le dur. Les premiers services que notre plateforme Windows Azure Pack doit fournir ce sont l’authentification (qui accède à la plateforme) et l’autorisation (quel privilèges/rôles). Le premier périmètre qui nous intéresse c’est les exploitants. Pour cette population, faut faire mieux que la configuration par défaut. On verra plus tard que pour les locataires, ca partira sur les mêmes bases.

Quelques rappels pour commencer

Notre maquette évolue. Ci-dessous les composants installés et les URL et ports tel que configurés à ce stade suite au billet Windows Azure Pack–Les APIs publiques des locataires :

Module

URL

Port

Admin portal https://wapadmin.windowsazurepack.lan 443
Admin API https://wapadmin.windowsazurepack.lan 30004
Admin Authentication site https://wapadmin.windowsazurepack.lan 444
Tenant portal https://wapcloud.Windowsazurepack.lan 443
Tenant public API https://wapcloud.Windowsazurepack.lan 30006
Tenant Authentication Site https://wapcloud.Windowsazurepack.lan 444

 

Donc, pour nos exploitants, ce qui va nous intéresser c’est :

  • L’Admin portal
  • L’Admin Authentication Site

A partir de maintenant, on passe en mode disruptif. Scoop, on ne va pas parler d’authentification Windows IIS intégrée comme nous l’avons toujours connue avec les produits Microsoft, tout du moins pas comme on en avait l’habitude. Pour illustrer mon propos, voilà ci-dessous une vue simplifiée du processus d’authentification pour les exploitants d’une plateforme Windows Azure Pack.

clip_image001

Lorsqu’un utilisateur se connecte au portail, ce dernier ne trouve pas de token (On me parle d’ADFS? Pas encore, ça viendra bien assez tôt). Le portail redirige donc vers le Security Token Server (STS) dédié à l’authentification des exploitants (Admin Authentication Site). C’est ce module qui est chargé de délivrer un JSON Web Token. Une fois l’authentification réalisée, l’utilisateur est redirigé vers le portail pour lui présenter son jeton d’accès. Le portail va alors solliciter le module « Admin API » et lui soumettre le jeton qui sera resoumis au Security Token Server (STS) pour déterminer les autorisations effectives de l’utilisateur. Dans ce processus standard, le STS va exploiter l’annuaire Active Directory pour obtenir les services d’authentification et d’autorisation. Normalement, ce stade, j’ai perdu personne. C’est assez disruptif comme démarche non? Pas assez? OK, alors on va mettre les doigts dans la prise électrique et voir ce que cela donne, …

Mettre les doigts dans la prise

D’un point de vue sécurité, le processus par défaut est pas mal, mais peut mieux faire :

  • Où est l’authentification forte?
  • Peut-on minimiser l’exposition de l’annuaire Active Directory?
  • Est-on obligé d’avoir un annuaire Active Directory?

Pour améliorer la chose, on va introduire ADFS dans l’histoire. C’est là que ça va se compliquer dans la cinématique d’authentification.

clip_image002

Jusqu’à maintenant, du point de vue de Windows Azure Pack, le partenaire de confiance pour l’authentification des administrateurs était directement Active Directory via le module « Admin Authentication Site ». Cela implique que nos utilisateurs avaient nécessairement un compte utilisateur dans un annuaire Active Directory.

Ce que nous allons faire, c’est court-circuiter ce module pour que le module « Admin portal » sollicite directement le partenaire de confiance que sera ADFS (Security Token Provider). C’est ce dernier qui va se charger de construire le token JSON et non plus le module « Admin Authentication Site ». C’est aussi simple que cela.

ADFS va devenir un partenaire de confiance de Windows Azure Pack au point de lui déléguer ses fonctions d’authentification et d’autorisation. C’est lui qui va nous fournir les capacités suivantes :

  • Prise en charge de l’authentification forte (Multi-Factor Authentication)
  • Prise en charge de plusieurs annuaires Active Directory (sans besoin de relation d’approbation)
  • Authentification auprès d’autres source qu’Active Directory (ADLDS, base SQL, …)

 

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!

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.