Identitätsbasiertes Kommunikationsbeispiel

In diesem Beispiel wird eine identitätsbasierte Kommunikationslösung für ein Unternehmen mittlerer Größe mit etwa 1.000 bis 5.000 Mitarbeitern dargestellt. In der Regel ist eine ausführliche Geschäftsanalyse mit anschließender detaillierter Bestimmung der technischen Anforderungen erforderlich, um die logische Architektur zu entwerfen. Da es sich hierbei jedoch um ein theoretisches Beispiel handelt, wird davon ausgegangen, dass die folgenden Geschäftsanforderungen bestimmt wurden:

• Die Mitarbeiter des Unternehmens benötigen persönlichen Zugriff auf interne Websites, Kommunikationsdienste, Kalenderdienste und andere Ressourcen.

• Die unternehmensweite Authentifizierung und Autorisierung bietet Zugriff auf interne Websites und andere Dienste.

• Einzelne Identitäten werden für alle Unternehmensdienste verfolgt. Dies ermöglicht einen Single Sing-On (SSO), welcher den Zugriff auf die internen Websites und andere Dienste ermöglicht.

In den Anwendungsfällen für dieses Beispiel würden die Anmeldeverfahren, das Lesen und Senden von E-Mails, die persönliche Anpassung des Portals, die Synchronisierung von Kalendern und andere ähnliche Benutzeraktivitäten detailliert beschrieben.

In der folgenden Abbildung wird eine logische Architektur für diese Art von identitätsbasierter Kommunikationslösung dargestellt.

Anwendungsfälle für identitätsbasiertes Kommunikationsbeispiel

Für eine Bereitstellungslösung dieser Art werden in der Regel mehrere detaillierte Anwendungsfälle erstellt, in denen die Interaktion der Benutzer mit den durch die Lösung bereitgestellten Diensten beschrieben wird. Bei diesem Beispiel steht die Interaktion der Komponenten bei der Anmeldung eines Benutzers an einem Portal über einen Webbrowser-Client im Vordergrund. In diesem Beispiel wird das Anmeldungsszenario in zwei Anwendungsfälle unterteilt:

• Der Benutzer meldet sich an, wird authentifiziert und Portal Server ruft die Portalkonfiguration des Benutzers ab.

• Portal Server ruft E-Mail- und Kalenderinformationen zur Anzeige im Web-Client ab.

Die beiden Anwendungsfälle können als ein erweiterter Anwendungsfall betrachtet werden. In diesem Beispiel werden die Anwendungsfälle der Einfachheit halber separat dargestellt.

Anwendungsfall 1: Ein Benutzer meldet sich erfolgreich an und das Portal ruft die Konfiguration des Benutzers ab

Schritte

1. Der Webbrowser-Client sendet die Benutzer-ID und das Passwort an Portal Server.

2. Portal Server fordert die Authentifizierung von Access Manager an.

3. Access Manager fordert die Bestätigung der Benutzer-ID und des Passworts von Directory Server an.

4. Directory Server überprüft die Benutzer-ID und das Passwort.

5. Access Manager fordert das Benutzerprofil von Directory Server an.

6. Directory Server sendet das Benutzerprofil zurück.

7. Portal Server fordert das Anzeigeprofil des Benutzers von Access Manager an.

8. Access Manager sendet die Portalkonfiguration zurück.

9. Die Portalkonfiguration wird im Webbrowser-Client angezeigt.

   

Anwendungsfall 2: Portal Server zeigt E-Mail- und Kalenderinformationen an

Schritte

1. Nach erfolgter Anmeldung, Authentifizierung und dem Abruf der Portalkonfiguration fordert Portal Server E-Mail-Nachrichten von Messaging Server MMP an.

2. MMP fordert eine Nachrichtenliste von Messaging Server STR an.

3. STR sendet die Nachrichtenliste an MMP zurück.

4. MMP leitet die Nachrichten-Header an Portal Server weiter.

5. Portal Server fordert Kalenderinformationen von Communications Express an.

6. Communications Express fordert Kalenderinformationen vom Calendar Server-Back-End an.

7. Calendar Server-Back-End sendet Kalenderinformationen an Communications Express zurück.

8. Communications Express leitet Kalenderinformationen an Portal Server weiter.

9. Portal Server sendet alle Kanalinformationen an den Webbrowser-Client.