EIM : la nouvelle approche d’IBM

de registres utilisateur
qui sont enregistrés dans ce domaine,
et des identités utilisateur dans les registres utilisateur qui sont associées
aux identificateurs EIM.

En concevant EIM, IBM a identifié
trois éléments d’information différents
qui définissent de manière unique
toute ID utilisateur : le nom de l’utilisateur
(appelé UID dans certains registres),
le type de registre utilisateur,
et l’instance particulière de ce registre
utilisateur. (La liste des profils utilisateur
sur un iSeries est une instance
d’un registre utilisateur OS/400, et la
même liste de profils sur un second
iSeries est une autre instance.)

Un registre utilisateur EIM représente
le type et l’instance d’un registre
utilisateur. Il existe une association
entre l’ID utilisateur, le registre EIM et
l’identificateur EIM auquel il est associé.
Avant qu’une identité utilisateur
dans un registre utilisateur puisse être
associée à  un identificateur EIM, le registre
utilisateur lui-même doit être défini
(ou enregistré) vis-à -vis du domaine
EIM.

EIM n’est pas simplement un autre
registre utilisateur. Aucun ID utilisateur,
mot de passe ou attribut spécifique
au registre utilisateur n’y est défini.
Il ne fournit aucun mécanisme
d’authentification : les applications
s’en occupent encore. EIM permet
simplement aux fournisseurs d’écrire
des applications qui utilisent quelques
registres autres que le registre de
plate-forme natif pour l’authentification,
tout en exploitant le registre de
plate-forme natif pour l’autorisation.
Avec EIM, cela peut se faire sans que
l’application doive authentifier l’utilisateur
dans les deux registres utilisateur.

Je reviendrai plus loin sur l’infrastructure.
Mais, tout d’abord, pour
mieux expliquer comment l’infrastructure
fonctionne, considérons quelques
possibilités SSO d’EIM.