Nous partons ici du principe qu’ADFS a été installé sur votre réseau interne.
Configurer UAG pour utiliser ADFS
Pour une introduction à Active Directory Federation Services (ADFS) et Forefront Unified Access Gateway (UAG), lisez la première partie de ce dossier : UAG SP1 et ADFS.
Ce dossier est issu de notre publication IT Pro Magazine (01/11). Pour consulter les schémas et illustrations associés, rendez-vous dans le club abonnés.
Du point de vue UAG, lorsque vous créer un point d’entrée (appelé « Trunk », en fait l’URL d’accès à des ressources), vous devez indiquer quel va être le type d’authentification demandé à l’utilisateur (login et mot de passe, carte à puce, clé type OTP). Depuis UAG Service Pack 1, un nouveau type de « repository » est arrivé, dont le nom est ADFS V2.
Comment configurer UAG pour utiliser ADFS ?
Il suffit de le sélectionner dans l’assistant de création du Trunk, et de répondre aux autres questions : voir figure 1.
Vous indiquez en « etape 1 » l’url qui va permettre à UAG de discuter avec un serveur ADFS déployé sur le réseau privé. En cliquant sur le bouton « retrieve data », UAG va demander à votre infrastructure ADFS les éléments qu’elle expose (appelé Métadata ». En étape 3, nous indiquons à UAG que nous allons sélectionner le « name » comme étant l’identifiant (pour la traçabilité) de l’utilisateur.
A ce niveau, le trunk sait qu’il devra chercher un jeton SAML pour l’authentification de bordure. Comme vous le constatez ceci est très rapide, très logique.
Maintenant que nous savons authentifier l’utilisateur, voyons comment nous définissons les autorisations, à la fois sur « l’autorisation de se connecter au portail UAG », puis ensuite, l’autorisation de se connecter à chaque application publiée. Voir figure 2.
Les autorisations se trouvent comment pour les autres types d’authentification dans l’onglet « authorization » de chaque application. Ici vous voyez que pour accéder à « application1 », je dois avoir une revendication dans mon jeton dont le nom est « Group » (la traduction ADFS de « je dois être membre de ce groupe »), et la valeur doit « Application1group ». Mais comment arrivent ces revendications ? Dans ce scénario, j’ai demandé à l’infrastructure ADFS d’ajouter cette assertion si l’utilisateur est membre d’un groupe de sécurité AD.
Console d’administration ADFS
Voici la console d’administration d’ADFS. Pour chaque application que je souhaite publier, je précise l’URL d’accès, et quelles sont les assertions que je souhaite voir présentes dans ce jeton. ADFS va faire le travail de récupération de ces informations, et d’ajout dans le jeton. Voir figure 3.
Chaque application doit être explicitement décrite dans ADFS (elles apparaissent ici dans la section « relying party trust ». Dans cet exemple, vous pouvez constater que UAG (le portail) est déclaré comme une application compatible ADFS, et que nous demandons à notre infrastructure de fédération de nous ajouter, dans le jeton de l’utilisateur (par exemple au moment de l’authentification), à la fois le nom de celui-ci, mais aussi une assertion de type « group». Voir figure 4.
Pour ce faire je vais ajouter (en tant qu’administrateur ADFS) une règle qui indique à mon infrastructure d’aller chercher un attribut LDAP dans la base « ActiveDirectory » dont le nom est « tokengroups ». En retour, pour chaque groupe AD (cet attribut est multi évalué), une assertion de type « Group » sera créé dans mon jeton.
Nous voyons ici deux exemples très simples où UAG va être en mesure d’authentifier et de donner des autorisations d’accès sur la base de ce jeton SAML.
Téléchargez cette ressource
Travail à distance – Guide complet pour les Directions IT et Métiers
Le travail à distance met à l'épreuve la maturité numérique des entreprises en termes de Cybersécurité, d'espace de travail, de bien-être des collaborateurs, de communication et gestion de projet à distance. Découvrez, dans ce nouveau Guide Kyocera, quels leviers activer prioritairement pour mettre en place des solutions de travail à domicile efficaces, pérennes et sécurisées.