Authentifizierungsservices

Authentifizierungsservices werden nur zwischen Clientanwendungen unterstützt, die WebSphere MQ Real-time Transport und die WebSphere Event Broker-Knoten Empfangsknoten für Echtzeiteingabe und Knoten 'Echtzeitoptimierter_Fluss' verwenden.

Die WebSphere Event Broker-Authentifizierungsservices prüfen, ob ein Broker und eine Clientanwendung tatsächlich die sind, die sie vorgeben zu sein, und daher zur Teilnahme an einer Publish/Subscribe-Sitzung berechtigt sind.

Jeder Teilnehmer in einer Sitzung verwendet ein Authentifizierungsprotokoll, um der anderen Seite zu beweisen, dass er der ist, der er vorgibt zu sein, und es sich nicht etwa um einen Eindringling handelt, der nur vorgibt, ein zulässiger Sitzungspartner zu sein.

WebSphere Event Broker unterstützt die folgenden vier Protokolle:

Die ersten beiden Protokolle und die Anforderungen an deren Infrastruktur werden unter Einfache Telnet-ähnliche Kennwortauthentifizierung bzw. Gegenseitige Challenge/Response-Kennwortauthentifizierung beschrieben. Asymmetrische und symmetrische SSL-Protokolle werden unter SSL-Authentifizierung beschrieben.

Die Stärke der Protokolle unterscheidet sich im Zugriffsschutz gegen Teilnehmer, bei denen es sich in der Sitzung nicht um gültige Teilnehmer handelt; P ist dabei das schwächste und R das stärkste Protokoll.

Authentifizierungsprotokolle konfigurieren

Die Gruppe der Protokolle, die in der Brokerdomäne von einem bestimmten Broker unterstützt werden, kann mit Hilfe der Workbench konfiguriert werden. Für jeden Broker können ein oder mehrere Protokolle angegeben werden. Verwenden Sie die Workbench, um die Authentifizierung auf jedem Echtzeitempfangsknoten, der für einen bestimmten Broker definiert wurde, zu aktivieren oder zu inaktivieren. Wenn die Authentifizierung auf einem Echtzeitempfangsknoten aktiviert ist, werden von diesem Knoten alle Protokolle unterstützt, die für den zugehörigen Broker angegeben wurden. Die Konfigurationsoptionen werden im folgenden Diagramm wiedergegeben:

Übersicht über eine Authentifizierungskonfiguration

Übersicht über eine Authentifizierungskonfiguration
Prozess zur Authentifizierung der Laufzeit in zwei Stufen

In diesem Diagramm wird die erste Stufe des Prozesses zur Authentifizierung der Laufzeit gezeigt. Das Protokoll der Sitzung wird ermittelt.

In diesem Diagramm wird die zweite Stufe des Prozesses zur Authentifizierung der Laufzeit gezeigt. Der Anwendung wird der Zugriff auf die Sitzung entweder erteilt oder verweigert.

Einfache Telnet-ähnliche Kennwortauthentifizierung

Dieses Protokoll kann auch als Kennwort im Klartext bezeichnet werden, da das Kennwort unverschlüsselt im Netz übertragen wird. Die Clientanwendung stellt über TCP/IP eine Verbindung zum Empfangsknoten für Echtzeiteingabe her. Der Empfangsknoten fordert den Client auf, sich auszuweisen. Als Antwort sendet der Client seine Benutzer-ID und sein Kennwort.

Dieses einfache Protokoll basiert auf der Annahme, dass dem Client und Broker das Kennwort der Benutzer-ID bekannt ist. Insbesondere benötigt der Broker Zugriff auf ein Repository, das Benutzer-IDs und Kennwörter enthält. Die Benutzer-ID und das Kennwort werden vom Benutzernamensserver an alle Broker in einer WebSphere Event Broker-Domäne verteilt. Der Benutzernamensserver holt sich Benutzer-ID und Kennwort aus einer Datei des Betriebssystems.

Die Verwendung eines Benutzernamensservers ermöglicht eine zentrale Verwaltung der Quelle mit den Benutzer-IDs und Kennwörtern, eine automatische Verteilung dieser Informationen an alle Broker und bei Bedarf die automatische Aktualisierung dieser Informationen. Darüber hinaus hat dieses Verfahren auch Vorteile für die Verfügbarkeit, da die Benutzer-IDs und Kennwörter persistent in jedem Broker gespeichert sind.

Jeder Clientanwendung muss die eigene Benutzer-ID bekannt sein, und sie muss ihr Kennwort geheim halten. Beim Herstellen einer Verbindung gibt ein Client seinen Berechtigungsnachweis in Form eines Name/Kennwort-Paars an.

Dieses Protokoll bietet nur geringe Sicherheit. Es wird kein Sitzungsschlüssel erstellt, und es sollte daher nur in Umgebungen verwendet werden, in denen keine 'Lauscher' oder 'Man-in-the-Middle'-Angriffe befürchtet werden.

Wenn Benutzer-ID und Kennwort in einer unstrukturierten Datei im System des Benutzernamensservers gespeichert werden, wird das Kennwort 'unverschlüsselt' gespeichert und verteilt.

Dieses Verfahren beansprucht Client- und Serversystem kaum.

Gegenseitige Challenge/Response-Kennwortauthentifizierung

Hier handelt es sich um ein komplexeres und sichereres Protokoll, bei dem ein geheimer Sitzungsschlüssel erstellt wird. Client und Server erstellen diesen Schlüssel unter Verwendung des Clientkennworts. Über ein Challenge/Response-Protokoll beweisen sich Client und Server gegenseitig, dass sie diesen geheimen Schlüssel kennen.

Der Client muss zuerst die Abfrage (Challenge) des Servers zufriedenstellend beantworten, bevor der Server die Abfrage des Clients beantwortet. Dies bedeutet, dass Unbefugte, die sich als Client ausgeben, keine Informationen für einen Offline-Angriff sammeln können, um das Kennwort zu erraten. Da Client und Server sich gegenseitig beweisen müssen, dass sie das Kennwort kennen, ist dieses Protokoll nicht anfällig gegen Angriffe, bei denen eine Identität vorgetäuscht wird.

Wie beim einfachen Telnet-ähnlichen Protokoll muss der Broker Zugriff auf Benutzer-IDs und Kennwörter haben. Diese Informationen werden vom Benutzernamensserver an alle Broker innerhalb der Domäne verteilt. Der Benutzernamensserver holt sich diese Informationen aus einer Datei des Betriebssystems.

Jeder Clientanwendung muss die eigene Benutzer-ID bekannt sein, und sie muss ihr Kennwort geheim halten. Beim Herstellen einer Verbindung gibt ein Client seinen Berechtigungsnachweis in Form eines Name/Kennwort-Paars an.

Auch dieses Verfahren beansprucht Client- und Serversystem nur wenig.

Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2005 Letzte Aktualisierung: Nov 17, 2005
aq01206_