L’espace d’application de la solution (2)

encapsuler
toutes les particularités
propriétaires uniques des divers systèmes
sécurisés, afin de pouvoir imiter
le sign-on d’un utilisateur, en jouant un
rôle d’intermédiaire.

Le serveur proxy d’authentification
contient la liste des utilisateurs
autorisés, les entités (serveurs et
services) auxquelles ils ont le droit
d’accéder et l’ID et mot de passe
pour chaque utilisateur sur ces entités
(figure 2). Le serveur stocke ces
informations sous forme cryptée
pour limiter les dégâts dans l’hypothèse
où le proxy d’authentification
serait compromis.

L’utilisateur s’identifie auprès du
serveur proxy d’authentification
puis choisit dans une liste de services
préconfigurés (cibles), pour
chacun desquels le serveur d’authentification
connaît déjà  l’ID et
mot de passe utilisateur. Le proxy effectue
ensuite le sign-on en lieu et place de l’utilisateur avec l’ID et mot
de passe stockés de ce dernier. Après
quoi, le proxy redonne la main à  l’utilisateur
pour conduire la session. Ou, si
la session n’est pas amovible, l’utilisateur
continue à  accéder au système
cible par l’intermédiaire du proxy.

L’avantage de cette approche est
de pouvoir (en théorie) fonctionner
avec tout système ou application sans
aucune modification de ces cibles.
Son inconvénient est que, bien
qu’elle résolve le problème des mots
de passe multiples pour l’utilisateur,
elle est impuissante quand il faut administrer
de multiples identités sur un
grand nombre de services. Le proxy
peut aussi ralentir les utilisateurs qui
doivent passer par son intermédiaire
pour toutes les activités à  distance.

La plupart des proxys d’authentification
ne prennent en charge qu’un
petit nombre de services cibles.
Comme les fournisseurs de serveurs
développent souvent des proxys d’authentification,
ils tendent à  ne supporter
que les produits de leur catalogue.
Ainsi, le site Web SuiteSpot de
Netscape comporte un proxy d’authentification,
mais il ne peut se
connecter qu’à  d’autres composants
de SuiteSpot.

Deuxième problème : Bien que le
serveur proxy d’authentification
stocke les mots de passe sous forme
cryptée, le cryptage est réversible,
parce que le serveur doit décrypter les
valeurs stockées pour pouvoir les envoyer
au système cible. Le mot de
passe décrypté est exposé et vulnérable
pendant le transit, et le proxy
d’authentification lui-même est en
danger dans l’hypothèse où un intrus
parviendrait à  accéder à  la fonction de
décryptage du serveur.

Registres centralisés. Un développement
récent promet d’être une stratégie
SSO largement adoptée. C’est
l’utilisation de registres centralisés (appelés
parfois répertoires). Un registre
central est semblable à  un serveur
d’authentification, mais plutôt que de
répondre par oui ou par non, il sert simplement de référentiel pour des références
d’authentification plus sophistiquées
sous la forme d’un certificat
numérique pour chaque utilisateur
(voir l’article « Comment les certificats
numériques sont (et ne sont pas)
utilisés »).

Le registre central est constitué
d’une base de données d’utilisateurs,
d’un schéma décrivant celle-ci, et d’un
moteur d’accès à  la base de données
qui analyse syntaxiquement les requêtes
et les traite pour extraire ou
mettre à  jour l’information du registre
(figure 3). Le registre ne permet des
mises à  jour qu’à  partir d’entités prédéfinies.

Les registres ainsi utilisés pour l’authentification
peuvent également servir
à  d’autres usages. Ils peuvent, par
exemple, jouer le rôle de carnets
d’adresses e-mail d’entreprise ou de
listes de services disponibles. Cette
double casquette des registres centralisés
séduit les implémenteurs qui peuvent
ainsi faire d’une pierre deux
coups.

Le principal inconvénient des registres
centralisés est le fait que chaque
service doit mettre en oeuvre les méthodes
d’accès du registre. L’un des
standards de registre centralisé les plus
connus aujourd’hui est le LDAP
(Lightweight Directory Access
Protocol). De nombreuses platesformes
serveur, dont OS/400,
WebSphere, Unix et diverses implémentations
VPN, acceptent LDAP pour
l’authentification. Microsoft a également
glissé son propre « standard »
propriétaire dans son service Active
Directory. En combinant ce service
avec Passport (une référence d’authentification
fondée sur un certificat numérique),
Microsoft vise à  offrir une
possibilité SSO pour toutes les applications
tournant sur les derniers logiciels
de Microsoft.