Exemple de communications basées sur les identités

Cet exemple illustre une solution de communications basées sur les identités pour une entreprise de taille moyenne (1 000 à 5 000 employés). Une analyse d'exploitation exhaustive, suivie d'une analyse détaillée des exigences techniques, est requise pour concevoir l'architecture logique. Cet exemple étant théorique, supposons que les exigences d'entreprise suivantes ont été définies :

• Les salariés de l'entreprise doivent disposer d'un accès personnalisé aux sites Web internes, aux services de communication, aux services de calendrier et à d'autres ressources.

• L'authentification et l'autorisation au niveau de l'entreprise fournissent l'accès aux sites Web internes et à d'autres services.

• Un suivi de toutes les identités uniques est effectué dans l'ensemble des services de l'entreprise, ce qui permet une connexion unique (Single Sign-On ou SSO) fournissant l'accès aux sites Web internes et à d'autres services.

Les cas d'utilisation associés à cet exemple détailleraient les procédures de connexion, la lecture et l'envoi de messages, la personnalisation du portail, la synchronisation des calendriers et d'autres activités utilisateur du même type.

Le shcéma ci-dessous illustre une architecture logique pour ce type de solution de communications basées sur les identités.

Cas d'utilisation pour l'exemple de communications basées sur les identités

Pour une solution de déploiement de ce type, il existe de nombreux cas d'utilisation détaillés décrivant les interactions utilisateur avec les services fournis par la solution. Cet exemple détaille les interactions entre composants lors de la connexion d'un utilisateur à un portail à partir d'un client Web. Il divise ce scénario de connexion en deux cas d'utilisation :

• L'utilisateur se connecte, est authentifié, puis Portal Server récupère sa configuration de portail.

• Portal Server récupère les informations de messagerie et de calendrier afin de les afficher dans le client Web.

Ces deux cas d'utilisation peuvent être considérés comme un seul cas étendu. Toutefois, dans cet exemple, les cas d'utilisation ont été séparés dans un souci de simplification.

Cas d'utilisation n°1 : l'utilisateur se connecte correctement et le portail récupère sa configuration

Étapes

1. Le client Web envoie l'ID utilisateur et le mot de passe à Portal Server.

2. Portal Server fait une demande d'authentification auprès d'Access Manager.

3. Access Manager demande la vérification de l'ID utilisateur et du mot de passe à Directory Server.

4. Directory Server vérifie l'ID utilisateur et le mot de passe.

5. Access Manager demande le profil utilisateur à Directory Server.

6. Directory Server renvoie le profil utilisateur.

7. Portal Server demande le profil d'affichage utilisateur à Access Manager.

8. Access Manager renvoie la configuration du portail.

9. La configuration du portail s'affiche dans le client de navigation Web.

   

Cas d'utilisation n°2 : Portal Server affiche les informations de messagerie et de calendrier

Étapes

1. Une fois la connexion, l'authentification et la récupération de la configuration du portail correctement effectuées, Portal Server lance une requête pour récupérer les messages auprès de Messaging Server MMP.

2. MMP demande la liste des messages à Messaging Server STR.

3. STR renvoie la liste des messages à MMP.

4. MMP transfère les en-têtes de messages à Portal Server.

5. Portal Server lance une requête pour récupérer les informations de calendrier au près de Communications Express.

6. Communications Express lance une requête pour récupérer les informations de calendrier auprès du composant d'arrière-plan Calendar Server.

7. Le composant d'arrière-plan Calendar Server renvoie les informations de calendrier à Communications Express.

8. Communications Express transfère les informations de calendrier à Portal Server.

9. Portal Server envoie les informations de canal au client de navigation Web.