coeur » applicatif, mais de nombreuses interfaces en fonction des « métiers ».

Dans l’exemple en figure 4, j’illustre une interface pour la finance, une autre pour la paye, une autre pour les ventes. Dans ce scénario, l’utilisateur doit s’authentifier chaque jour avec le même login et le même mot de passe 4 fois. On peut imaginer également qu’après déjeuner, en raison des timeout applicatifs l’ayant déconnecté, il devra de nouveau se reconnecter 4 fois. L’objectif d’IAG sera donc, puisqu’il n’est pas possible de connaître le mot de passe de l’utilisateur (différent de celui utilisé en bordure), de minimiser l’impact de cette contrainte. Voir Figure 4.

Comment faire pour aider nos utilisateurs ? Au sein d’IAG, nous indiquons à IAG que nous souhaitons du Web SSO pour ces 4 applications. Nous lui indiquons qu’elles sont toutes liées à un même « repository » que nous allons appeler par exemple « Repository_ERPPGI ». IAG ne connaît pas ces crédentiels. Grâce à ces paramétrage, lors de l’accès à la première de ces applications (finance dans notre exemple), IAG va 1) demander ces crédentiels à l’utilisateur 2) les garder en mémoire pour la durée de la session 3) fournir le SSO.

Sur ce premier accès, l’utilisateur aura malheureusement une expérience SSO nulle, puisqu’il aura indiqué ses crédentiels au système. En revanche, lors de l’accès aux autres applications reposant sur ce même « repository », IAG connaît maintenant les éléments d’authentification et fournira une expérience SSO totale. Par ce système de paramétrage très efficace, nous allons avoir un retour utilisateur très positif, tout en gardant un niveau de sécurité équivalent.