Contrôle utilisateur

même
nom d’utilisateur et mot de passe sur
tous les systèmes. Pour se hisser au niveau
suivant d’une solution IAM, un
composant de connexion réduit ou
contrôlé s’impose.
Il existe deux ensembles de composants
de connexion : un concerne
les adresses des applications de type
Web et l’autre concerne les adresses
pour toute l’entreprise. Ce dernier
n’est pas une mince affaire, car la
connexion pour l’ensemble de l’entreprise
implique généralement un large
éventail d’applications tournant sur
une gamme de types de serveurs encore
plus large auxquels accèdent des
types d’applications desktop très diverses
(émulation de terminal pour
des applications basées sur l’hôte, applications
client/serveur, applications
client léger, par exemple). On voit
donc que la mise en place d’un sign-on
réduit à  l’échelle de l’entreprise est
loin d’être simple.
Mais le sign-on dans un environnement
Web n’est pas aussi difficile –
principalement parce que tout l’accès
utilisateur passe par une interface
unique : un navigateur Web. Une fois
que l’utilisateur se connecte via le navigateur,
toutes les applications Web suivantes
peuvent s’exécuter dans le
contexte de ce navigateur. Cela ne signifie
pas pour autant que toutes les
applications Web honoreront le signon
initial.
Par conséquent, le rôle du jeu de
composants de sign-on Web IAM est
d’arbitrer entre l’utilisateur et les applications
Web. Si l’utilisateur accède à 
une application Web qui demande l’authentification,
les composants IAM
font l’une des deux choses suivantes :
ils (1) passent le nom et le mot de
passe utilisateur initiaux à  l’application
pour authentification en coulisses, ou
(2) associent le nom et le mot de passe
utilisateur à  un nom et mot de passe
utilisateur différents et fournissent cela
à  l’application pour l’authentification
en coulisses.
Mais quel est l’intérêt d’associer un
nom et un mot de passe utilisateur à 
un nom et mot de passe utilisateur différents
? On pourrait le faire, par
exemple, pour canaliser un ensemble
d’utilisateurs externes dans un nom
d’utilisateur commun. Ainsi, si un portail
Web sert un million d’utilisateurs
externes dont tous ont besoin d’accéder
à  une application basée sur l’hôte,
il serait déraisonnable de créer un million
de noms d’utilisateurs unique sur
l’hôte. Il est préférable que tous les utilisateurs
externes partagent une identité
commune.
Autre exemple : celui où des systèmes
de noms ou mots de passe utilisateur
différents sont requis par les
systèmes hôtes supportant les applications
Web. Si, par exemple, l’une des
applications Web est réellement une
application iSeries qui a été « webifiée
», l’application iSeries demandera
obstinément un nom et un mot de
passe contrôlés par le mainframe – et,
bien entendu, ces noms et mots de
passe ont des règles de formatage très
strictes. Par conséquent, les composants
sign-on Web IAM peuvent associer
le nom et mot de passe utilisateur Web conviviaux à  un nom et mot de
passe utilisateur conviviaux pour
l’iSeries – et tout cela sans que l’utilisateur
s’en aperçoive.