Répondre aux besoins SingleSignOn avec Microsoft AIG

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, …).