Le problème des registres utilisateur multiples (2)

problèmes
de sécurité. Cette forme de
SSO résout le problème en stockant en
un point central tous les ID et mots de
passe utilisateur en texte clair ou en
format déchiffrable. S’ils utilisent un
format déchiffrable, les produits doivent
stocker la clé de cryptage quelque
part sur le même système. Donc, tous
les administrateurs système peuvent
apprendre très facilement le mot de
passe de chacun. En outre, les produits
SSO de reproduction de mot de passe
préfèrent les environnements
client/serveur statiques ; ils aiment
moins les environnements multi
niveaux.

L’une des premières constatations
d’IBM en commençant à  s’attaquer à  ce
problème, a été que toutes les approches
existantes ont un point commun
: elles essaient de dissimuler ou
d’ignorer le fait qu’il existe actuellement
des registres utilisateur multiples.
En fait, elles disent : « Ignorez
simplement le fait que vous avez déjà 
des utilisateurs définis dans des registres
existants et que vous avez déjà 
de nombreux téra-octets de données
sécurisés avec les mécanismes de sécurité
correspondants associés à  ces registres.
Utilisez simplement le registre
utilisateur et la sémantique de sécurité
de ce produit et vos problèmes sont
réglés. »

Du point de vue du produit, ce raisonnement
tient debout. Mais du point de vue administratif et utilisateur, il est
généralement dangereux, et parfois
impossible, d’ignorer l’existence de registres utilisateur multiples. Considérons, par exemple, une application
qui stocke des données dans
une base de données DB2 et qui applique
à  ces données le contrôle d’accès
au niveau application. Tant que
l’utilisateur n’accède qu’à  cette application
sur ce système, un produit SSO
de réplication de mot de passe peut
être suffisant. Mais c’est rarement le
cas. La plupart des utilisateurs doivent
accéder à  de nombreuses applications
différentes et à  des interfaces fournies
par l’OS/400, pour accomplir leurs
tâches, et les administrateurs ne peuvent
pas ignorer ce fait.

IBM a décidé d’emblée qu’une
bonne solution devait :
• admettre le fait qu’il existe des registres utilisateur multiples et qu’il
en sera ainsi pendant un certain
temps
• faciliter le traitement du problème
par toutes les parties
• être utilisée par les systèmes d’exploitation
et les applications
• être largement disponible sur des
plates-formes non-IBM