Étude et déploiement d’un mécanisme de centralisation d’une : ~ authentification: Cas de SSD sous Windows

Étude et déploiement d’un mécanisme de centralisation d’une :authentification: Cas de SSD sous Windows

Étude et fonctionnement de la centralisation de l’authentification 

 Architectures SSO 

L’architecture de la plupart des produits de SSO est inspirée de Kerberos; ils utilisent largement sa terminologie ct partagent ses concepts de base qui sont les suivants : ~ Les applications sont déchargées du travail d’authentification des utilisateurs. Cette tâche est assurée par un serveur d’authentification dédié. ~ Le serveur d’authentification délivre des tickets au client (maintien de la session d’authentification) et aux applications (transmission de l’ identité de l’utilisateur). Ce second ticket transite également par le client. ;;. L’application ne recueille jamais les éléments d’ authentification de l’ utilisateur (couple identifiant + mot de passe par exemple). );> Il existe une relation de confiance entre les applications et le serveur d’authentification. À noter que Kerberos n’ utilise que des techniques de cryptographie symétriques ; l’utilisation de certificats X509 (utilisant des algorithmes asymétriques) peut permettre de simplifier l’ architecture du système. Les principes de base d’un système de Single Sign-On web ont été définis dans des documents de référence. Compte tenu du développement par plusieurs universités américaines de systèmes de SSO, Internet 2 a initié le groupe de travail WebiSO chargé de définir les caractéristiques d’ un système de Single Sign-On web. Le projet Liberty Alliance, quant à lui, est un regroupement d’ entreprise (AOL, Cisco, France Telecom, HP, Novell, Sun, Verisign, … )qui, en réaction face au projet « Microsoft Passeport », publie des recommandations autour de la notion de « Federated Network Identity», une authentification unique avec partage des données de l’utilisateur avec des partenaires de confiance.

Les types de SSO

 Pour comprendre l’authentification unique de l’entreprise (SSO), il est utile d’examiner les trois types de services Single Sign-On disponibles aujourd’hui : Windows intégré, extranet et intranet. Ceux-ci sont décrits dans les sections suivantes, avec Enterprise Single Sign-On tombant dans la troisième catégorie. ~ Windows Connexion unique intégrée . Ces services nous permettent de nous connecter à plusieurs applications de notre réseau qui utilisent un mécanisme d’authentification commun. Ces services demandent et vérifient vos informations d’identification après vous être connecté au réseau et utilisent nos informations d’identification pour déterminer les actions que nous pouvons effectuer en fonction de nos droits d’utilisateur. Par exemple, si les applications intègrent Kerberos, une fois que le système a authentifié nos informations d’identification utilisateur, nous pouvons accéder à toute ressource du réseau intégrée à Kerberos. );> Extranet Single Sign-On (Web SSO) Ces services vous permettent d’accéder à des ressources sur Internet en utilisant un seul ensemble d’informations d’identification utilisateur. L’utilisateur fournit un ensemble d’informations d’identification pour se connecter à différents sites Web appartenant à différentes organisations. Un exemple de ce type d’authentification unique est Microsoft Passport Network pour les applications grand public. Pour les scénarios fédérés, Active Directory Fédération Services active Web SSO. >- Connexion unique intranet basée sur le serveur Ces services nous permettent d’intégrer plusieurs applications et systèmes hétérogènes dans l’environnement d’entreprise. Ces applications et systèmes peuvent ne pas utiliser l’authentification commune. Chaque application possède son propre répertoire d’utilisateurs. Par exemple, dans une organisation, Windows utilise le service d’annuaire Active Oirectory pour authentifier les utilisateurs et les ordinateurs centraux utilisent la fonction RACF (Resource Access Control Facility) d’IBM pour authentifier les mêmes utilisateurs. Au sein de l’entreprise, les applications intègrent les applications front-end et back-end. Enterprise Single Sign-On permet aux utilisateurs de l’entreprise de se connecter à l’extrémité frontale et à l’extrémité arrière tout en utilisant un seul jeu d’informations d’identification  permet à la fois l’authentification unique initiée par Windows (dans laquelle la demande initiale est faite à partir de l’environnement de domaine Windows) et l’authentification unique lancée par l’hôte (dans laquelle la requête initiale est effectuée à partir d’un environnement de domaine non Windows) dans le domaine Windows. En outre, la synchronisation des mots de passe simplifie l’administration de La base de données SSO et conserve la synchronisation des mots de passe entre les répertoires utilisateur. Nous pouvons le faire en utilisant des adaptateurs de synchronisation de mot de passe, que nous pouvons configurer et gérer à l’aide des outils de synchronisation de mot de passe. 

Architecture classique d’un 550 web 

 Le serveur d’authentification 

Le serveur d’authentification est l’élément central du système de SSO puisqu’ il assure l’authentification de l’utilisateur, la persistance de sa connexion et la propagation de l’ identité de l’utilisateur auprès des applications. L’utilisateur fournit ses éléments d’authentification au serveur d’authentification. Si le mode d’ authentification est le mot de passe, la phase d’authentification implique la vérification du mot passe de l’utilisateur auprès d’une base de référence. La plupart des systèmes de SSO implémentent plusieurs backend d’authentification (/etc/password, LDAP). Si le serveur implémente l’ authentification par certificats sa tâche consistera à vérifier la validité du certificat, la chaîne de certification et les listes de révocation. En concentrant la logique d’authentification sur un serveur d’authentification, on peut plus facilement faire évoluer les méthodes d’authentification (certificats, OTP,) ainsi que les bases d’ authentification reconnues (Radius,). Lorsque l’utilisateur a été authentifié, le serveur d’authentification maintiendra la session de l’utilisateur en positionnant un cookie HTTP sur le poste de l’utilisateur. Les données stockées dans le cookie sont protégées (cryptage ou utilisation d’un ticket interprété par le serveur) et sa portée est idéalement limitée au serveur d’authentification. Le cookie HTTP est le seul moyen technique fiable à notre disposition pour que l’utilisateur soit reconnu comme authentifié lors de son prochain accès au serveur. Si l’ utilisateur a été orienté vers le serveur d’authentification par une application cible, leserveur doit, en retour, fournir l’ identité de l’ utilisateur à l’application. Par identité on entend soit uniquement un identifiant, un email et/ou un ensemble d’attributs de l’utilisateur. La transmission de l’identité de l’utilisateur à l’application transitera forcément par le poste de l’utilisateur. Soit le serveur d’ authentification utilise une redirection HTTP, soit il renvoie à l’utilisateur un document HTML incluant un programme Javascript de redirection. Dans tous les cas le navigateur de l’ utilisateur est redirigé vers l’ application, muni des éléments d’ identification. L’application ne fait appel qu’une fois au serveur d’ authentification et gère ensuite une session applicative classique avec l’utilisateur. 

 L’agent d’authentification

 L’agent d’authentification est la brique du SSO intégrée à l’application cible par exemple sous forme d’une librairie applicative ou d’un module apache. L’agent vérifie que l’utilisateur est authentifié; s’il ne l’est pas, ille redirige vers Je serveur d’authentification. Si le client s’est déjà authentifié auprès du serveur d’authentification (attesté par la présence d’un cookie) le serveur Je redirige directement vers l’agent d’authentification demandeur, de façon non bloquante. Lorsque l’utilisateur revient du serveur d’authentification, authentifié, l’agent vérifie l’origine des données (les données peuvent être signées) et les transmet à l’application. Certains systèmes de SSO ne véhiculent pas directement les attributs de l’ utilisateur entre Je serveur d’authentification et l’agent mais un jeton d’authentification; l’agent d’authentification contacte directement le serveur d’authentification (accès HTIPS ou web services) et lui présente le jeton pour validation ; en retour il reçoit les données sur l’ utilisateur. Ce type de SSO est particulièrement adapté aux architectures multi tiers. Il peut se révéler coûteux ou difficile de modifier les applications pour y intégrer un agent d’authentification. On peut envisager une solution de type« reverse proxy »où on installe un agent d’authentification en frontal d’un ensemble d’applications. L’agent reverse proxy intercepte les accès utilisateurs ; une fois l’utilisateur identifié il transmet les données d’ identification à l’application via des variables d’ environnement (dans le cas d’un module du serveur web) ou dans des champs d’en-têtes HTIP. La plupart des SSO est fournie avec un module de ce type pour Apache. 

Architectures multi tiers

 L’authentification dans une architecture multi tiers, comportant au moins un intermédiaire entre l’ utilisateur et l’application cible, pose le problème de la délégation des privilèges. Deux exemples de ce type : -un portail web agissant comme intermédiaire vis -à-vis d’une application; -un Webmail, intermédiaire vis -à-vis du serveur IMAP. Ce type de relation est donc courante et doit supporter la migration vers un système de SSO web. L’adaptabilité d’un SSO à ce type d’architecture est un critère de choix important. L’article Trusted Délégation of Privilèges in an N-Tiers Environnent décrit bien les 4 mécanismes permettant de transmettre une authentification dans une architecture multi tiers : « Usurpation d’identité » (masquerade) :.J’intermédiaire transmet les éléments d’authentification (identifiant + mot de passe) à l’application comme s’il était l’utilisateur. Ce mécanisme est adapté à des applications offrant une interface d’authentification simple (Ex : soumission d’un formulaire auprès d’un CGI). 2. « Relation de confiance » : l’intermédiaire, une fois authentifié auprès de l’application cible, peut demander un service à l’application pour n’importe quel utilisateur. Inconvénient du système : si l’application intermédiaire est compromise, l’attaquant a accès à toutes les applications du réseau de confiance. 3. « Accès direct aux données »: l’intermédiaire court-circuite l’application et accède directement à ses données. Cette solution requiert une bonne connaissance de l’application finale. 4. « Procuration » (proxied credentials) : le serveur d’authentification attribue à l’intermédiaire une procuration sous forme d’un ticket à présenter à l’application finale. L’application vérifiera le ticket auprès du serveur d’application. La solution (1) est utilisée dans certains produits de SSO décrits plus loin. (2) correspondrait à une relation de confiance entre un portail et ses canaux, le portail fournissant au canal l’identité de l’utilisateur. La solution (4) est celle qui offre les meilleurs gages de sécurité puisque l’application fournissant l’ identité de l’utilisateur est dédiée. En revanche ce type de produits impose de modifier toutes les applications concernées (webmail + serveur IMAP dans le cas d’ un webmail). La version 2.0 de CAS, le SSO développé par l’Université de Yale, gère la délégation de cette manière.