Microsoft.com au jour le jourUtilisation des services ADFS (Active Directory Federation Services)

Jim Guthrie

À Microsoft, nous disposons d'un extranet permettant à nos partenaires commerciaux d'accéder aux ressources internes. L'architecture de l'extranet nécessite que chaque participant externe à l'entreprise possède un compte de domaine unique pour cet espace. Ce compte est créé et géré par les employés de Microsoft plutôt que par ses

partenaires, pour des raisons évidentes. Toutefois, et bien que fonctionnel, ce système est peut-être moins satisfaisant du point de vue de l'expérience l'utilisateur ; de plus, il monopolise un certain nombre de ressources de Microsoft, qui doit gérer tous les utilisateurs partenaires.

Voici comment l'extranet fonctionne actuellement. Lorsqu'un client ou partenaire s'inscrit dans une application, il doit saisir ses informations d'authentification. Au cours de la même session, si cet utilisateur décide d'accéder à une ressource différente, il devra de nouveau saisir ses informations d'authentification. Et ces informations lui seront demandées à chaque fois qu'il voudra accéder à d'autres ressources. Si l'utilisateur ouvrait une session dans une application unique qui utilise des ressources multiples, par exemple une base de données financière, il devrait s'authentifier indépendamment pour chaque ressource. Un tel système n'est pas très pratique et risque d'irriter les utilisateurs.

Fort heureusement, grâce à Active Directory® Federation Services (AFDS), nous pouvons résoudre facilement le problème des authentifications multiples, et vous aussi. ADFS est un composant de Windows Server® 2003 R2 qui permet à plusieurs entreprises de partager des ressources tout en conservant la capacité de chacune à gérer ses propres utilisateurs. Dans cet article, j'illustre la manière dont Microsoft prépare l'utilisation d'ADFS pour résoudre ce problème d'extranet à ressources multiples, ce qui vous fournira les informations dont vous aurez besoin pour mettre en œuvre une solution similaire. Cependant, avant d'entrer dans les détails, jetez un coup d'œil sur la figure 1 pour vous familiariser avec certains termes ADFS de base.

Figure 1 Terminologie ADFS

Une solution ADFS

Lorsqu'un utilisateur tente d'accéder à une application gérant ADFS, le navigateur est envoyé au FS-R (Federation Service Resource) pour la découverte de domaine. C'est ici que l'utilisateur sélectionnera la série d'informations d'authentification qu'il utilisera pendant la session. Selon le domaine que le client a choisi, l'utilisateur sera ensuite redirigé vers le serveur FS-A (Federation Service Accounts). C'est dans ce serveur qu'il recevra un jeton de compte valide (dans un cookie) qui sera basé sur les informations d'authentification qu'il a saisies sous forme d'un ID Windows Live™ (qui remplace le compte Passeport), d'une authentification intégrée de Windows ou d'une authentification SSL (voir la figure 2). Dans ce modèle, ce sont les entreprises individuelles qui doivent gérer leur propre serveur de fédération de comptes. Dans le cas des serveurs des partenaires de Microsoft, ce système permet de soulager Microsoft.com de la gestion de ces comptes dans l'environnement. Bien sûr, lorsque l'on met en œuvre ce niveau de responsabilité, il faut sélectionner soigneusement les entreprises avec lesquelles on construit cette fédération et s'assurer qu'elles gèrent leurs informations de comptes de façon active.

Figure 2** Flux ADFS **(Cliquer sur l'image pour l'agrandir)

L'étape suivante consiste à retourner au serveur FS-R pour échanger le jeton de compte contre un jeton de ressources. Dans notre configuration, ce jeton contient une liste complète des autorisations qui ont été accordées à l'utilisateur par un système de déclarations et de mappage effectué sur le serveur FS-R. Une fois le jeton reçu, cet utilisateur obtient la fonctionnalité d'authentification unique (SSO) sur les applications gérant l'ADFS valide pour toute la durée de la session ou jusqu'à 24 heures par défaut (cette durée est configurable). Le résultat est que vous avez activé le SSO pour ces applications gérant l'ADFS, ce qui aboutit à une expérience client plus sûre et plus efficace. Pour une description étape par étape du processus d'authentification ADFS, voir l'article de Matt Steele publié dans le numéro de juillet 2006 de TechNet Magazine et intitulé « Simplification de l'authentification unique avec ADFS ».

Afin d'assurer la sécurité des ressources de l'entreprise Microsoft, nous avons isolé le côté orienté Internet de l'extranet du côté de l'entreprise, ce qui signifie que tous les serveurs sont potentiellement doubles. Nous autorisons une approbation à sens unique des utilisateurs internes de l'entreprise et nous utilisons les serveurs pour fournir la protection nécessaire. Nous possédons également un domaine séparé pour l'espace de l'extranet dans lequel nous fournissons aux utilisateurs externes l'accès aux ressources dont ils ont besoin.

Les deux problèmes principaux auxquels nous avons été confrontés pendant sa mise en œuvre étaient l'équilibrage de la charge et les modifications des fichiers de stratégie ADFS. L'équilibrage de la charge était un défi au niveau global et au niveau local. Au début dans la production, nous utiliserons l'équilibrage de la charge globale d'Akamai ou Savvis, nos partenaires CDN (Content Delivery Network), pour les clusters de serveurs Web frontaux dans deux régions. Nous assurons ainsi la disponibilité du système aux utilisateurs finaux, même dans le cas peu probable où deux serveurs régionaux viendraient à être déconnectés. Pour ce faire, nous utilisons le principe du basculement automatique basé sur les vérifications de l'état du serveur fournis par les CDN. De plus, nous pouvons facilement ajouter d'autres clusters à l'avenir. Etant donné l'objectif de réduction de coût, nos déploiements de pré-production n'utiliseront pas le service CDN.

Au niveau régional, nous avons associé les serveurs pour un basculement local grâce au clustering NLB (Network Load Balancing). Nous n'utilisons pas de fonctionnalité d'équilibrage de charge particulière : nous aurions donc tout aussi bien pu accomplir cela à l'aide de matériel. Toutefois, et vu que l'objectif est de réduire les coûts, nous utilisons le NLB. Cette configuration nous permettra d'assurer 99,9 % de disponibilité de fonctionnement dans tous les environnements pris en charge.

Autre défi auquel nous devions faire face : le fichier de stratégie ADFS, la colonne vertébrale de l'ADFS, doit être correctement distribué à travers notre environnement et les modifications qui lui sont apportées doivent être également copiées. Pour ce faire, nous nous servons d'une autre fonctionnalité intégrée à Windows Server 2003 R2, la DFS-R (Distributed File System Replication), un nouveau moteur de réplication multi maître basé sur l'état. Sur chacun des serveurs principaux, nous avons activé une appartenance au groupe de DFS-R avec une réplication à maille pleine de 24 heures. Les modifications apportées au fichier de stratégie seront distribuées à tous les serveurs. Tant que nous contrôlons la modification des fichiers, nous avons un service stable et hautement disponible.

Nous avons essayé de nous assurer que toutes les modifications soient effectuées par le composant logiciel enfichable ADFS. Cependant, dans la pratique, nous nous sommes rendu compte que nous devions de temps en temps mettre ce fichier à jour manuellement. Lors d'une mise à jour manuelle, il est important de se rappeler que l'ADFS assure le suivi de la version de ce fichier. Vous devez donc incrémenter le fichier pour que vos modifications soient reflétées dans l'environnement :

<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri> 
<TrustPolicyVersion>127
</TrustPolicyVersion> 

Il vous faut également vous souvenir que, comme tout XML, le fichier XML de stratégie est sensible à la casse. Ce fichier renferme de nombreuses références aux applications ou aux autres serveurs ADFS, et elles doivent toutes être copiées mot à mot de serveur à serveur. Veuillez noter les exemples communs suivants, la première référence, RevocationCheckFlags, ayant été entrée manuellement et la seconde étant l'URL d'une application de confiance modifiée par l'Interface utilisateur :

<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>

Pour renforcer la sécurité, nous utilisons un autre composant de l'ADFS, le FS-P (Federation Service Proxy), qui s'assure que les FS-R restent inaccessibles aux requêtes directes provenant d'Internet. Chez Microsoft.com, nous avons trouvé une façon innovante d'implémenter les proxys en utilisant une seule série de proxys pour héberger plusieurs environnements ADFS dans notre zone de pré-production. Fait intéressant, lors de nos premiers tâtonnements avec cette technologie, nous avons découvert qu'il nous suffisait de modifier une clé de registre pour y parvenir. La clé en question se situe dans HKLM\Software\Micro­soft\WebSSO. Une simple modification de la valeur de l'annuaire initial dans cette clé vous permettra d'utiliser le proxy pour plusieurs environnements. La valeur par défaut était :

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”

Pour basculer entre environnements, vous devez modifier la clé comme suit :

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”

La création d'un fichier de commandes peut simplifier la gestion de ce processus. Malheureusement, la version actuelle du composant logiciel enfichable MMC pour ADFS ne prend pas en charge les basculements entre environnements, car il existe une relation de type un à un entre le proxy et le serveur de ressource ou compte. C'est le seul moyen d'optimiser l'utilisation des serveurs proxy. Le résultat final est une énorme réduction des coûts, car il limite le nombre de serveurs physiques nécessaires, quel que soit le nombre d'environnements différents que vous choisissez d'héberger.

D'un point de vue architectural, nous exécutons notre environnement de pré-production avec des machines virtuelles, ce qui représente une économie de coûts supplémentaire. Ceci élimine le besoin d'acheter et d'héberger six serveurs supplémentaires. A ce jour, nous n'avons eu aucun problème de performances. Cependant, pour répondre à la demande sans cesse croissante dans l'environnement de production, nous avons choisi d'utiliser des machines physiques hautes performances.

Pas uniquement pour Active Directory

Microsoft.com ne se contente pas d'utiliser des comptes Active Directory pour l'authentification : nous avons également intégré les comptes Windows Live ID. Nous avons trouvé qu'en utilisant Windows Live ID (WLID) 4.5, nous pouvions utiliser un compte WLID unique pour déléguer l'accès aux ressources de Microsoft utilisant une transformation de déclarations personnalisée. C'est un énorme avantage pour effectuer l'authentification SSO, car nous n'avons plus besoin d'un compte de domaine spécifique.

Défis restants

Le plus grand défi auquel nous sommes aujourd'hui confrontés est la gestion d'ADFS pour le partage de certificats de signature de jetons. Nous utilisons des certificats standard qui restent valides typiquement pendant une année avant de nécessiter un renouvellement. Au moment du renouvellement, chacun des serveurs appropriés devra être mis à jour en conséquence, ce qui aura un impact considérable sur les FS-R. Si la situation est à peu près gérable pour 15 ou 20 fédérations, elle devient vraiment problématique à l'échelle que envisageons, c'est-à-dire au moins des centaines, voire des milliers de fédérations. Cela nécessiterait une équipe à temps complet dédiée à la gestion de certificats de SSL pour un seul environnement. Nous avons plusieurs équipes qui réfléchissent à la meilleure façon d'automatiser cette solution, mais qui ne sont pas encore parvenue à une conclusion satisfaisante.

Autre défi : les applications ne gèrent pas toutes l'ADFS dès l'installation. Nous aurons besoin de programmation pour que les sites profitent de l'opportunité fournie par l'ADFS. Nous travaillons en étroite collaboration avec l'équipe de Microsoft® Office SharePoint® Services pour veiller à ce que la version de SharePoint nouvelle génération prenne en charge nos besoins d'implémentation pour ADFS.

Conclusion

Avant de prendre la décision de passer à un modèle ADFS, vous devez prendre en considération plusieurs facteurs. L'un d'eux concerne les ressources auxquelles les clients accèderont. Le processus de création d'une confiance fédérée entre les entreprises peut être une tâche triviale, mais l'écriture, la relecture et l'exécution de stratégies d'accès acceptables nécessitent du temps et des efforts. Donc s'il n'existe qu'une seule ressource à laquelle vos clients auront accès, vous devrez décider si le jeu en vaut la chandelle. Cependant, à mesure que le nombre de ressources grandit, les avantages augmentent.

Pour plus d'informations, voir Introduction à ADFS et Active Directory Federation Services : vers une identité et une gestion d'accès fédérées.

Jim Guthrietravaille au sein de l'équipe d'exploitation informatique Microsoft.com. Outre sa contribution aux services ADFS, il est ingénieur système dans l'équipe de support à la plateforme du portail d'entreprise.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.