Authentifizierungsservices werden nur zwischen Clientanwendungen unterstützt, die WebSphere MQ Real-time Transport und die WebSphere Message Broker-Knoten 'Real-timeInput' und 'Real-timeOptimizedFlow' verwenden.
Die WebSphere Message 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 Message Broker unterstützt die folgenden vier Protokolle:
Die beiden ersten Protokolle und ihre Infrastrukturvoraussetzungen werden unter Einfache Telnet-ähnliche Kennwortauthentifizierung bzw. Gegenseitige Challenge/Response-Kennwortauthentifizierung beschrieben. Asymmetrische und symmetrische SSL-Protokolle werden unter SSL-Authentifizierung beschrieben.
Die Protokolle unterscheiden sich hinsichtlich des Schutzes, den sie gegen unzulässige Sitzungspartner bieten; P bietet den schwächsten, R den stärksten Schutz.
Die Protokolle, die von einem Broker in der Brokerdomäne unterstützt werden, können in der Workbench konfiguriert werden. Für jeden Broker können ein oder mehrere Protokolle angegeben werden. Über die Workbench können Sie die Authentifizierung für jeden Echtzeiteingabeknoten inaktivieren, der für einen Broker definiert ist. Wird die Authentifizierung für einen Echtzeiteingabeknoten aktiviert, unterstützt dieser Knoten alle für den Broker definierten Protokolle. Die Konfigurationsoptionen werden in den folgenden Abbildungen veranschaulicht:
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 Echtzeiteingabeknoten her. Der Empfangsknoten fordert den Client auf, sich zu 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 Message Broker-Domäne verteilt. Der Benutzernamensserver holt sich Benutzer-ID und Kennwort aus einer Datei des Betriebssystem.
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 permanent 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 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.
Hier handelt es sich um ein komplexeres und sicheres 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.