Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

L’authentification fédérée par claims, les grands principes

Poster un commentaire

Jusqu’à récemment les choses étaient simples: les entreprise maîtrisaient et hébergeaient elle-même les applications utilisées par son personnel. Il suffisait donc d’installer un AD quelque part, créer un compte et on pouvait accéder à des dizaines d’applications en se loguant une seule fois très facilement. En tout cas si l’application prend en charge l’authentification Windows!!!!

Les choses sont en train de changer depuis l’arrivée du cloud. Les applications ne sont alors plus gérées par l’entreprise et se trouvent à l’extérieur de son réseau. De nouvelles questions surgissent alors:

  • Comment assurer des services d’authentification sans être obligé de mettre en place un compte pour chaque application?
  • Chaque application cloud peut aussi avoir son propre protocole. Faudra t’il les comprendre et les gérer? Comment alors gérer les identités
  • Que faire lorsqu’une personne quitte l’entreprise? On doit supprimer un nombre indéterminé de compte?
  • Comment donner accès à un partenaire à notre application, comment gérer ses droits, son départ de chez le partenaire?

On voit vite que même dans une petite entreprise utilisant une demi douzaine d’applications le problème devient vite un challenge.

La réponse est la fédération des identités (ou authentification unique). Il s’agit un ensemble de mécanismes, de standards et de patrons bâtis autour des normes WS-* qui définissent différentes façons de partager des informations relatives à l’identité d’un utilisateur entre différentes applications.

Ainsi un organisme, pas forcément votre employeur, joue le rôle de fournisseur d’identité (Identity Provider, Idp ou issuer). Celui est chargé de gérer votre identité et de renvoyer un jeton à l’application demandeuse si l’authentification a réussi. On appelle application par partie de confiance ou Relying Party une telle application.
L’application n’a jamais accès à vos credentials, elle ne verra de vous que les informations que le fournisseur veut bien lui envoyer. Elle sait juste que le fournisseur d’identité auquel elle fait confiant à dit OK.

Notez bien l’utilisation du mot confiance, c’est cela qui est sous-jacent à la solution technique que je vais essayer de décrire dans cet article. Cette relation de confiance est peut aussi s’appeler une relation d’approbation. Elle est établie entre deux domaines d’approbation (trust domain).

 

Le jeton est aussi appelé jeton de sécurité. Il porte les informations sur l’identité d’une personne. Par exemple son nom, son adresse, sa date de naissance… Dans le cadre de cet article on ne considère que les jetons présentés sous la forme d’une collection de claims.

2014-11-22_14-08-45

L’intérêt des jetons par claims est que le format est nettement moins rigide et est évolutif de façon naturelle. Si on a besoin d’un claim supplémentaire, il suffit de l’ajouter ce qui est plus difficile par exemple avec un jeton Kerberos. Reste ensuite à gérer le transfert de ces jetons, il existe différentes solutions:

Protocole Description
SAML SAML 2.0 est un protocole très général: formats de jeton, profil, des protocoles…
WS-Federation Protocole à large portée comme SAML, mais autre implémentation. Protocole spécialisé dans l’authentification des applications Web.
WS-Trust Spécialisé dans l’authentification des services SOAP. WCF par exemple.
OAuth OAuth 2.0 est spécialisé dans la gestion de la délégation d’autorisation de services Web REST. Souvent détourné pour faire de l’authentification.
Open Id Connect Ajoute l’authentification à OAuth.

 

Edit 31/03/2017: J’ai commencé à écrire quelques articles démontrants de façon pratique certains concepts démontrés ici:

https://amethyste16.wordpress.com/2017/03/30/proteger-une-application-avec-azure-ad/

 

Claims? Jetons? Ok, mais ils viennent d’où?

Dans un précédent article, j’ai montré une vision développeur des claims:

https://amethyste16.wordpress.com/2014/11/11/gerer-lauthentification-et-les-authorisations-avec-les-claims/

Savoir manipuler les claims c’est bien, mais encore faut t’il être capable d’en trouver!

Dans la vie de tous les jours les tokens sont obtenus auprès d’un STS (Security Token Service). Un STS est une application, un logiciel, capable de créer, signer, valider, annuler, renouveler ou publier un jeton basé sur les claims. On rencontre essentiellement les formats:

  1. SAML
  2. SWT
  3. JWT

Pour être très clair: STS ==> Claims

Les STS sont mis en œuvre par un fournisseur d’identité (Identity Provider) qui se charge de fournir un service d’authentification et de gestion de l’identité.
Des exemples notoires sont Google, Microsoft, Facebook, Yahoo!… mais aussi votre employeur à travers l’AD de votre entreprise.

Regardez ce schéma qui montre comment un jeton est obtenu et utilisé dans un processus d’authentification:

2014-11-23_17-08-55

  1. Un utilisateur demande à s’authentifier auprès d’une application.
    Elle lui indique le liste des Idps et donc des STS auxquels elle fait confiance.
  2. L’utilisateur demande au STS un jeton d’authentification en lui fournissant ses credentials. Cette requête est appelée parfois une RST (Request for Security Token).
  3. Le STS authentifie le client à la vue des credentials proposés par l’application.
  4. Si l’authentification réussie, il a la possibilité de consulter un répertoire d’utilisateurs (par exemple un AD, une base de données…) afin d’enrichir la liste des claims.
  5. Un jeton contenant les claims est alors créé et signé afin de garantir son intégrité et indiquer par qui il a été créé. Le jeton est renvoyé à l’utilisateur. Cette réponse est appelée une RSTR (Request Security Token Response).
  6. Il peut le présenter à l’application auprès de laquelle il doit s’authentifier.
  7. Une librairie spécialisée valide la signature du jeton et vérifie que le STS est un STS de confiance. Ensuite elle extrait les claims et les fournit à l’application.
    Microsoft fournit une librairie appelée WIF (Windows Identity Foundation) pour cela.
    Si les STS fournis par WIF ne peuvent être utilisés que sur des sites ASP.NET ou WCF, le Framework peut en réalité servir dans tout environnement.
  8. L’application va lire les claims et analyser les droits dont dispose l’utilisateur.

Vous noterez que dans ce schéma l’application n’a aucune connaissance de l’origine des claims. Ce point est important car c’est lui qui assure la capacité à ce modèle d’authentification de fédérer ce processus, c’est à dire de le sous-traiter à des Idp. Nous allons voir comment on organise cela dans le prochain paragraphe.

Peut être que cela semble compliqué. Nous allons même le compliquer un peu tout à l’heure! Mais sachez qu’en pratique vous n’avez pas besoin de gérer vous même cette cinématique. Les SDK feront le travail à votre place et c’est transparent pour l’utilisateur. Enfin presque transparent car il pourra constater que l’authentification ne se fera pas sur le site de l’application, mais sur un site tiers. C’est un point important, car c’est cela qui assure que l’application à laquelle vous vous connectez ne pirate pas votre compte Twitter!

Un dernier détail. Le schéma ne représente qu’un seul STS. Mais ce n’est pas obligatoire. L’application peut très bien faire confiance à plusieurs fournisseurs d’identité.

Les fournisseurs de fédération

Que se passe t’il lorsque l’application à laquelle on souhaite accéder ne fait pas confiance aux STS pour lesquels on dispose d’une identité?

Même si l’application ne fait pas confiance dans vos STS, elle peut faire confiance dans un STS qui, lui, fait confiance à un de vos STS. Dans ce cas il est possible de demander à ce STS d’obtenir un jeton en votre nom acceptable par l’application. Le STS qui sert d’intermédiaire est appelé un fournisseur de fédération (federation provider).

Regardons comment ça marche sur ce schéma:

2014-11-23_17-49-55

 

 

  1. L’utilisateur demande un accès à une application par partie de confiance. Elle lui indique qu’elle fait confiance à tel fournisseur de fédération (FP)
  2. L’utilisateur s’adresse à FP qui lui indique la liste des STS dans lesquels il fait confiance.
  3. L’utilisateur repère un STS pour lequel il a un compte et s’authentifie. Le STS l’authentifie, construit ses claims et lui renvoie un jeton d’authentification.
  4. Ce jeton est adressé à FP
  5. FP le valide et créée un jeton FP dans lequel l’application à confiance.
    Une phase de transformation peut avoir lieu pour mettre les claims issus de STS au format attendu par l’application
  6. FP renvoie le jeton à l’utilisateur
  7. Qui le présente à l’application
  8. Le jeton est validé et les claims lus
  9. Les claims sont présenté à l’application qui les analyse pour associer des droits à l’utilisateur

 

Cette fois le scénario est beaucoup plus complexe. Mais pour l’utilisateur tout reste transparent. Il saisit juste un login/mot de passe après avoir éventuellement choisit un STS dans une liste.

Un dernier détail que je n’ai pas mentionné. Comment font les STS ou le FP pour connaître les claims attendus par l’application? Simplement parce que un administrateur les a configuré.

On voit apparaître un basculement de l’application vers le fournisseur d’identité concernant les données utilisateur. Il n’est normalement pas nécessaire pour l’application, chaque application en pratique, de détenir une base de données utilisateur. Ce travail est celui des STS. Il devient ainsi possible de centraliser toutes les informations utiles même si plusieurs applications différentes les utilisent.

Cools j’ai enrichit mon vocabulaire, mais après?

On en sait maintenant assez pour frimer un max devant la machine à café ou le boss, mais tôt ou tard il faudra proposer des architectures puis les mettre en œuvre concrètement. Le cadre technique de cet article sera les technologies Microsoft, mais en fait rien de tout ce qui a été exposé jusqu’à présent n’est spécifique à Microsoft. La fédération d’identité est une norme mise en place progressivement par de plus en plus de compagnies sur toute sorte d’environnement.

Commençons par l’inventaire des outils à notre disposition. Le tableau suivant résume la situation entre le cloud et le on premises:

STS Fournisseur de fédération SDK
Azure Aad Aad
Windows Azure Active Directory Access Control
WIF
On premises Windows Server Active Directory +
ADFS
Windows Server Active Directory +
ADFS
WIF

Note: La terminologie WAAD semble avoir évoluée en AAD (Azure Active Directory). Mais on peut évidemment rencontrer les deux termes. J’ai ajouté une mise à jour du texte.

Quel que soit l’environnement, WIF est le SDK au cœur des développements.

Sous Azure, Azure Active Directory permet d’apporter des services STS, mais aussi de fournisseur d’identité. Dans le dernier cas on dispose aussi d’un deuxième outil: ACS.

ACS existe depuis toujours dans Azure, tandis que AAD date d’avril 2013. Il est donc plus récent. Il est probable qu’une migration progressive se fasse d’un outil vers le deuxième, mais c’est loin d’être achevé. Actuellement chaque outil à ses avantages, mais le message est le suivant pour un nouveau projet:

Si AAD suffit à votre scénario, partez sur AAD.

Vous trouverez une analyse des différences entre les deux outils ici (un peu datée tout de même):

http://salvoz.com/blog/2013/07/30/windows-azure-acs-and-ad/

Retenez au moins que AAD offre un support pour groupes d’utilisateur et est de plus capable de se synchroniser avec un AD on premises. De plus il offre des services d’identification ce que ne fait pas ACS.

Côté On premises, Active Directory n’a pas nativement de capacités STS, d’où l’ajout obligatoire de ADFS.

Je propose de démonter quelques architectures typique autour de la gestion d’identité par claims. Certains on premises, d’autres Azure.

Je n’ai pas trouvé de document Microsoft qui fait le bilan des scénarios supportés, mais en cherchant un peu il n’est pas difficile de trouver des exemples. J’ai fait une sélection de ceux qui me semblent les plus courants. C’est intéressant car cela permet de partir sur une base lorsque l’on est en situation réelle.

Cas 1: une application d’entreprise

Variante 1: Une entreprise met à disposition une application hébergée en interne. L’application est une application par partie de confiance, mais on voudrait s’y connecter avec le compte de domaine. Windows Active Server Active Directory est déployé on premises comme tous les autres modules et les utilisateurs se connectent depuis l’entreprise.

La mise en œuvre est une lecture directe de la dernière ligne du tableau qui précède. Dans ce scénario nous n’avons pas besoin de fournisseur de fédération, par conséquent l’architecture sera la suivante:

2014-11-24_23-21-04

Notez bien que l’ensemble de ces modules sont déployés on premises.

  1. Un utilisateur démarre sa session Windows et s’authentifie auprès du domaine de son entreprise. Il reçoit un ticket Kerberos
  2. Ensuite l’application essaye de se connecter à une application. L’application l’informe qu’elle attend des claims et que le STS auquel elle fait confiance est l’ADFS de l’entreprise
  3. L’utilisateur présente son jeton Kerberos comme credentials et demande à ADFS de le transformer en claims
  4. ADFS retrouve les claims dans AD et  créée un jeton comme demandé par l’application
  5. ADFS renvoie le jeton à l’utilisateur
  6. Le jeton est ensuite soumis à l’application qui grâce à la couche WIF va le valider et lire les claims
  7. Les claims sont présentés à l’application

Variante 2: On garde notre scénario précédent, mais cette fois l’utilisateur se connecte depuis Internet. L’utilisateur est toujours un utilisateur de l’entreprise

On peut penser à ces 2 solutions:

  1. Monter un ADFS par dessus l’AD
  2. Installer Windows Azure Active Directory (AAD) et le synchroniser avec l’AD en utilisant DirSync

ADFS offre à AD les capacités STS réclamées par l’application et la possibilité d’accéder à son compte de domaine via Internet.

2014-11-24_23-42-46

  1. Un utilisateur appartenant à l’entreprise se connecte depuis chez lui à une application Web hébergée par son entreprise on premises. L’application attend un jeton par claims et fait confiance à l’ADFS de l’entreprise
  2. L’utilisateur s’authentifie à ADFS en fournissant son login/mot de passe et obtient un jeton au format voulu
    Dans ce scénario, contrairement au précédent, on ne peut pas utiliser son ticket Kerberos qui passe mal à travers Internet. Mais puis que l’utilisateur a un compte de domaine, ADFS pourra l’authentifier sans problèmes.
  3. L’utilisateur se connecte ensuite à l’application en lui présentant le jeton
  4. L’application reçoit les claims

Evidemment l’utilisateur devra se ré authentifier une deuxième fois. Mais il le fera avec le même compte que son compte AD ce qui est tout de même une amélioration.

Un scénario AAD est également possible, il sera présenté plus loin dans un contexte plus général.

Variante 3: Toujours le même scénario, mais cette fois c’est l’application qui est déployée quelque part sur Internet, sur un Azure par exemple. Bien entendu on souhaite s’y connecter via son compte entreprise.

2014-11-25_00-26-09

  1. Un utilisateur se connecte à l’application qui lui indique qu’elle fait confiance à ADFS
  2. L’utilisateur réclame un jeton à ADFS en présentant son ticket Kerberos
  3. L’utilisateur présente le jeton à l’application qui connecte alors l’utilisateur

Note: on pourrait imaginer des scénarios dans lesquels AD est déployé dans une VM sous Azure. Cela permet entre autre d’utiliser Group Policy pour gérer des VM déployées sur Azure. AAD ne permet pas de faire cela.
Dans ce cas il faut se souvenir qu’un serveur de domaine à besoin d’une IP persistante. On devra donc créer la VM dans un réseau virtuel.

On peut avoir d’autres raisons de déployer AD dans Azure:

  • Profiter des fonctions de sauvegarde d’Azure. Vous pouvez par exemple conserver quelques VM critiques dans Azure et en particulier un serveur de domaine. Ce jeu de VM peut ensuite servir de base pour prendre le relais en cas de défaillance ailleurs.
  • Donner un accès de proximité à votre AD à une filiale située à l’autre bout du monde qui ne dispose pas des ressources suffisantes pour gérer elle même son propre contrôleur de domaine. Cela lui épargne des latences importantes lorsque son personnel voudra se connecter au domaine.
  • Vous avez déployé sur Azure des applications comme SharePoint qui ont besoin d’accéder à un contrôleur de domaine pour gérer les demandes d’authentification.
    On pourrait effectivement envisager de déployer un annuaire local, configurer un contrôleur de domaine directement dans Azure améliorera les performances.

Note: Dans le cas du scénario précédent notez également qu’il ne sera pas possible de déployer l’application sur Azure dans le même cloud service que le serveur de domaine car tous deux ont besoin d’écouter les ports 80 et 443

Microsoft a rédigé des guides de déploiement de Windows Server Active Directory sur Azure:

http://msdn.microsoft.com/en-us/library/azure/jj156090.aspx

http://msdn.microsoft.com/en-us/library/azure/dn151466.aspx

http://azure.microsoft.com/en-us/documentation/articles/active-directory-new-forest-virtual-machine/

Ces architectures permettent de connecter des contrôleurs de domaine de la même façon que s’ils étaient on premises. Mais il y a tout de même quelques différences à bien avoir en tête:

  • Une connexion on premises/Azure est significativement plus lente qu’une connexion on premises/on premises
     Il faudra donc veiller à limiter ce type de connexion
  • Azure propose certes un service de DNS, mais il n’offre pas certains services nécessaires à AD (telles que la prise en charge des enregistrements DNS dynamiques et SRV).
    Pour cette raison il faudra configurer son propre serveur DNS dans Azure.
  • Si vous déployez AD dans Azure, il va bien entendu se poser la question de la synchronisation.
    Azure facture uniquement le trafic sortant d’un data center. Cela peut avoir un impact pour décider de l’architecture de déploiement dans Azure de vos serveurs de domaines.

 Cas 2: une entreprise X héberge une application, les utilisateurs de l’entreprise Y veulent y accéder

Variante 1: Une entreprise X héberge une application sur son réseau. Elle souhaite ouvrir l’accès à l’application à son partenaire Y. Ceux devront pouvoir y accéder via leur compte de domaine.

Analysons la situation.

Côté Y on est on premises. Si on veut se connecter à travers Internet à une application, on devra donc installer ADFS.
Il serait maladroit d’ajouter l’ADFS de Y dans le domaine d’approbation de l’application car on ne veut pas avoir à faire ce travail pour toutes les applications de X que l’on ouvre aux partenaires. Pour peu que les applications et les partenaires sont nombreux, l’opération deviendra fastidieuse et dangereuse.
La solution qui s’impose est donc l’utilisation d’un fournisseur de fédération.

C’est le cas d’école d’usage des fournisseurs de fédération. Le FP pourrait être aussi bien ACS que Windows Azure Active Directory, voire un outil tiers.

A titre d’exercice, essayez de reconstituer vous même les étapes pour voir!

Les choses se présentent ainsi:

2014-11-25_09-47-19

  1.  L’utilisateur Y (partenaire) tente de se connecter à l’application X. Il découvre qu’elle ne fait confiance qu’au STS du fournisseur de fédération de l’entreprise X (FP X).
  2. L’utilisateur demande un ticket à FP X et découvre que FP X veut bien lui créer un jeton FP, mais à condition de lui présenté un jeton créé par l’ADFS de son entreprise auquel il fait confiance
  3. L’utilisateur est dans son domaine, il présente donc son ticket Kerberos à ADFS Y pour obtenir un jeton IdP
  4. Le jeton IdP est ensuite présenté à FP X. Il le valide et le transforme en jeton FP
  5. FP X retourne le jeton FP demandé à l’utilisateur
  6. L’utilisateur à tout ce qu’il lui faut pour s’authentifier à l’application X et lui présente donc son jeton FP

Dans le schéma le FP n’a qu’un seul STS dans sa liste d’approbation, mais en pratique il y en aura toujours plusieurs. dans ce cas comment s’effectue la sélection?

Ce problème est appelé « découverte d’accueil de domaine » (home realm discovery). Plusieurs solutions sont possibles:

  1. On peut présenter une page une liste de possibilités
    ADFS supporte pleinement cette option, mais aussi ACS et AAD
  2. Le fournisseur de fédération peut tenter d’inférer le nom de domaine de l’utilisateur en analysant par exemple son adresse email et en déduire vers quel STS le rediriger

Vous pouvez trouver une démonstration de la dernière méthode ici:

https://syfuhs.net/2011/07/12/adjusting-the-home-realm-discovery-page-in-adfs-to-support-email-addresses/

http://blog.torresdal.net/2010/04/19/home-realm-discovery-in-wif-and-adfs-2-0-by-query-string/

Cas 3: AAD utilisé comme un fournisseur d’identité

Variante 1: Un utilisateur tente de se connecter depuis son entreprise à une application SaaS, cad déployée sur Azure. L’application fait confiance à Azure Active Directory pour résoudre l’identité de l’utilisateur en utilisant son compte de domaine.

2014-11-25_17-46-38

  1. L’utilisateur se connecte à l’application Saas
    Cette application fait confiance à Windows Azure Directory
  2. L’utilisateur s’authentifie sur AAD avec son compte d’entreprise
    AAD est une application multi tenant, cela signifie qu’elle peut prendre en charge plusieurs types d’utilisateurs comme par exemple des utilisateurs venus d’entreprises différentes. X est justement un des tenants.
  3. AAD renvoie un jeton
  4. L’utilisateur présente le jeton à l’application (via la couche WIF) qui le valide, extrait les claims et les proposent à l’application
  5. Optionnellement, l’application peut interroger AAD via l’interface Graph pour réclamer des informations supplémentaires sur l’utilisateur

 

J’ai déjà rédigé un tutoriel sur Graph que l’on trouve ici:

https://amethyste16.wordpress.com/2014/08/24/explorer-graph-api/

Il faut retenir que Aad n’est absolument pas la version Azure d’AD. Les services sont très différents, le besoin aussi. Aad est un service d’annuaire, de gestion d’identité et d’accès à des applications que l’on peut (optionnellement) synchroniser avec un AD on premises. On ne peut pas faire de synchronisation de Waad vers AD par contre.

Aad présente un schéma beaucoup plus simple qu’AD. D’ailleurs la création et la gestion d’un tenant Aad est largement à la portée d’un simple développeur. J’en suis la preuve. Je ne me sens pas les compétences pour gérer des serveurs de domaine AD par contre.

Dernier point, vous ne pouvez pas ouvrir de session Windows depuis Aad. Ce scénario n’est pas supporté.

 Cas 4: Se loguer avec Facebook, Yahoo! … + ACS

On pourrait encore multiplier les cas de figure, mais ils ne nous apprendraient rien de plus que ce qui a été vu jusqu’à présent. Je vais me contenter de décrire un exemple très classique: l’authentification en SSO via des fournisseurs d’identité des réseaux sociaux.

Comme cela a été expliqué dans le cas 2, la bonne architecture consiste à utiliser un fournisseur de fédération. Dans notre exemple il s’agira d’ACS, on aurait pu choisir AAD. Autre différence notable, cette fois on ne cherche pas à s’authentifier avec un compte de domaine, mais uniquement avec un compte extérieur à l’entreprise:

2014-11-25_21-51-03

Dans ce scénario tous les éléments sont déployés dans Azure.

  1. L’utilisateur se connecte à l’application Saas et découvre qu’elle fait confiance à l’ACS
  2. L’utilisateur se rend donc vers l’ACS qui fait office de fournisseur de fédération.
    ACS fait confiance à divers STS dont il fournit la liste: Google, ADFS, Facebook…
  3. L’utilisateur se voit présenter un écran de sélection. Il sélectionne l’IdP de son choix et s’authentifie en fournissant les credential proposés
  4. Il reçoit un jeton fournit par l’Idp
  5. Il présente ce jeton à l’ACS qui le valide et lui renvoie un jeton ACS accepté par l’application
  6. L’utilisateur s’authentifie avec le jeton ACS auprès de l’application

Conclusion

J’ai décris les différentes briques qui interviennent dans les scénarios d’authentification par claims. Plus important j’ai montré des scénarios concrets développant leur mise en œuvre pratique.

Certains de ces scénarios ont déjà été démontrés dans des précédents articles:

https://amethyste16.wordpress.com/2014/08/23/mettre-en-place-lauthentification-avec-visual-studio-2013-partie-ii/

https://amethyste16.wordpress.com/2014/11/07/lauthentification-ws-federation-avec-azure-windows-active-directory/

Je pense que d’autres articles viendront par la suite.

Bibliographie

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s