L’identité née du marché

Dans un scénario IAM, un utilisateur
est ajouté à  un référentiel de droits ou
d’autorités. Pour les employés, ce référentiel
est le plus souvent rattaché à 
l’application ressources humaines.
Pour les utilisateurs extranet, le référentiel
peut être rattaché à  une application
LOB (line-of-business) ou à  un
service d’auto-inscription. Pour les utilisateurs
qui se situent entre ces deux
catégories (partenaires professionnels,
sous-traitants, employés temporaires),
le référentiel est généralement rattaché
à  une autre application (par
exemple, une application de paie pour
les sous-traitants et les temporaires,
une application LOB pour les partenaires
professionnels).
Dès lors que l’utilisateur se trouve
dans le référentiel d’autorités (quel
qu’il soit), la magie IAM commence.
Tout d’abord, la solution IAM détecte
(en temps réel ou dans une fenêtre de
traitement batch) l’ajout d’un utilisateur
et entreprend de générer des
comptes utilisateur sur tous les systèmes
applicables. Ainsi, un nouvel utilisateur
peut être ajouté à  un répertoire
de courrier électronique, à  un
répertoire de portails d’avantages sociaux,
à  des serveurs d’accès AD
(Active Directory) pour Windows,
à  un répertoire iSeries et à  d’autres
systèmes serveur (Unix, mainframe,
par exemple). C’est l’aspect création de comptes automatisée d’IAM.
Dans une solution IAM de base,
une simple création de comptes peut
parfois suffire : l’utilisateur est établi
dans chaque répertoire à  l’aide d’une
information rudimentaire sur les
groupes de comptes. Mais les entreprises
demandent souvent à  la solution
IAM bien plus qu’une simple création
de comptes. Elles lui demandent de
définir des droits d’accès plus granulaires
et d’associer une logique de gestion
supplémentaire.
Si le nouvel utilisateur est un vendeur,
par exemple, il devrait être validé
pour des applications qui s’associent
aux bases de données de clients et de
prospects. Et si l’utilisateur est un vendeur
de la région nord-ouest, le
compte utilisateur des applications de
ventes devrait être établi de manière à 
le tenir à  l’écart des clients ou des prospects
hors de sa région de ventes.
Dans cet exemple, la solution IAM
doit comprendre les droits d’accès basés
sur des rôles ou sur des règles. Il ne
suffit plus alors de générer simplement
un nouvel utilisateur dans le groupe
« ventes ». La solution IAM doit comprendre
l’architecture sécuritaire des
applications qu’elle sert et elle doit
être capable d’associer l’utilisateur
à  un ensemble approprié de droits
d’accès.
Cet exemple d’utilisateur de ventes
peut aussi illustrer comment des solutions
IAM peuvent s’intégrer à  des processus
de gestion. Quand l’utilisateur
est reconnu comme un vendeur, la solution
IAM peut générer les formulaires
permettant de commander un
portable et un téléphone mobile. Dans
ces habilitations qui demandent une signature,
la solution IAM peut prévoir
des étapes conditionnelles. Par
exemple, elles pourraient générer des
bons de commande et envoyer un email
pour demander l’approbation du
VP des ventes. Dès que le VP approuve
l’achat, la solution IAM émet les bons
de commande.
On peut même aller plus loin. Une
fois que le téléphone mobile et le portable
ont été approuvés, commandés
et reçus, la solution IAM peut mettre à 
jour l’information du compte utilisateur
avec des fiches d’inventaire du
matériel et bien sûr ajouter le numéro
de téléphone mobile au répertoire de
la société.
Cette description illustre la création
de comptes automatisée et la
maintenance des droits d’accès des solutions
IAM, mais ce n’est que la partie
visible de l’iceberg.