Le terme SSO ne comporte que 3 lettres, mais il renferme en fait une complexité relativement importante tant en termes de technologies que de gestion du changement. La problématique particulière du SingleSignOn est qu’il s’agit en fait d’un concept. Ce qui signifie qu’il peut y avoir plusieurs réponses technologiques à ce besoin de fournir une expérience utilisateur d’authentification unique.
Au sein de cet article, je vais tenter de vous fournir certaines approches d’architecture en utilisant Microsoft IAG 2007 en tant que « passerelle de SSO ». Elles sont toutes basées sur des architectures déjà en production chez les clients, IAG fait donc partie des « technologies » possibles pour y répondre.
Conceptuellement, le
SSO peut se résumer facilement en un processus à deux étapes. Premièrement, l’utilisateur va s’authentifier à un système c’est-à-dire qu’il va prouver son identité (login mot de passe, carte à puce, jeton SAML/ADFS, autre). Ensuite quelle que soit l’application publiée, l’utilisateur ne sera plus jamais sollicité pour prouver son identité.
Dans un système d’information, il est rare de trouver une uniformité dans les applications que ce soit en termes d’éditeur (Microsoft ou non), annuaire d’authentification (Active Directory, base métier comme SAP par exemple, …) et technique d’authentification (NTLM, Kerberos, Formulaire Web, …). C’est pour cela que le SSO est un réel challenge car il y a de nombreuses combinaisons à supporter.
Un système SSO devra donc être capable de s’adapter aux différentes combinaisons : « applications »/ »annuaires »/ « techniques d’authentification ». Notez également la montée en puissance des scénarios dits « de fédération d’identité ». C’est aujourd’hui le cas avec la technologie ADFS (Active Directory Federation Services) mais également demain à travers le « framework » Geneva (voir les annonces faites à la Professional Developer Conference-PDC). Comment allier ces visions d’avenir (fédération, full Kerberos, …) avec les contraintes techniques actuelles (applications diverses, authentifications multiples) ?
Par définition, un utilisateur devra donc être en mesure de se connecter, en fonction de son profil, à de nombreuses applications, et ce qu’il soit sur le réseau privé de l’entreprise ou en situation de mobilité. Dans la figure 2, nous trouvons une illustration de l’équation d’un système de SSO. Côté client, de nombreux types de matériel, de systèmes d’exploitation et de types d’utilisateur. Côté réseau privé, les applications d’entreprise. Dans cette figure, nous illustrons plusieurs types d’applications.
En bleu, des applications reposant sur un annuaire ActiveDirectory. Note: Afin d’évoquer les « combinaisons » possibles, les cercles de couleur illustrent des applications deman dant une authentification par formulaire Web, les triangles illustreront quant à eux des applications paramétrées pour supporter le mode dit « intégré » (NTLM/Kerberos). En rouge, cette autre application métier utilise une authentification par formulaire (symbolisée par un cercle) mais ce login et mot de passe sont liés à un autre annuaire qu’AD, c’est-à-dire la base interne de l’application n’ayant aucun lien avec cet AD. Le cas le plus fréquent pour illustrer cette contrainte est la mise en oeuvre d’un PGI/ERP d’entreprise.
Des login et mot de passe différents, pas de système de synchronisation (le client peut en revanche mettre en oeuvre Microsoft ILM). Comment fournir du SSO dans ce cas ? Continuons notre scénario. En vert, nous imaginons un autre système supportant cette fois-ci l’authentification Kerberos (Ticket de Service). Pour complexifier cet article et se rapprocher des réalités client, le système d’exploitation n’est pas un système Windows, le seul point d’interconnexion est donc Kerberos.
Nous avons donc ici un challenge relativement fort, mais plus important, très commun dans les entreprises et ce quelle que soit leur taille. Un système de SSO performant devra être capable de lier l’authentification de bordure de « n’importe quel type » (Login/PWD, carte à puce, … ) avec des systèmes d’authentification hétérogène, tant sur les crédentiels que sur la forme où nous allons les présenter aux applications (intégré, formulaire, …).
Téléchargez cette ressource
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
