SSL für Echtzeitknoten aktivieren

Zwischen JMS-Clients und Real-timeInput- und Real-timeOptimizedFlow-Knoten können optionale Authentifizierungsservices verwendet werden.

In einer Standardkonfiguration sind die Authentifizierungsservices inaktiviert.

So konfigurieren Sie das Produkt für die Verwendung der SSL-Authentifizierungsservices:

Benutzernamensserver konfigurieren

Der Benutzernamensserver verteilt an die Broker Kennwörter, die zur Unterstützung dieser Authentifizierungsprotokolle erforderlich sind.

Um den Benutzernamensserver so zu konfigurieren, dass eine Authentifizierung unterstützt wird, stehen für die Befehle mqsicreateusernameserver oder mqsichangeusernameserver die folgenden beiden Parameter zur Verfügung:

  • AuthProtocolDataSource beschreibt das Verzeichnis einer lokalen Datei mit den Informationen, die für eine Unterstützung der Authentifizierungsprotokolle erforderlich sind.
  • Das Flag -j gibt an, ob die Datei, auf die der Parameter AuthProtocolDataSource verweist, Angaben zu Gruppen und Gruppenzugehörigkeiten sowie Kennwortinformationen enthält.

Mit dem Flag -d des Befehls mqsichangeusernameserver wird diese Option inaktiviert.

Broker konfigurieren

Konfigurieren Sie einen Broker, sodass er die Authentifizierungsservices von WebSphere Ereignisbroker unterstützt. Sie müssen zwei Parameter für die Authentifizierung und die Zugriffssteuerung angeben und die Workbench verwenden, um die entsprechenden Real-timeInput-Knoten und die Protokolle zu konfigurieren, die im Broker unterstützt werden sollen.

Gehen Sie dazu wie folgt vor:

  1. Wechseln Sie in die Ansicht 'Brokeranwendungsentwicklung'.
  2. Für jeden Nachrichtenfluss in der Nachrichtenflusstopologie müssen Sie folgende Schritte ausführen:
    1. Wählen Sie den Real-timeInput- oder Real-timeOptimizedFlow-Knoten aus, um die Eigenschaftenansicht zu öffnen, oder klicken Sie mit der rechten Maustaste auf den Knoten, und klicken Sie auf Eigenschaften, um den Eigenschaftendialog zu öffnen. Die Knoteneigenschaften werden angezeigt.
    2. Wählen Sie Authentifizierung aus.
  3. Führen Sie für jeden Broker Folgendes in der Brokertopologie aus:
    1. Wählen Sie den Broker aus, um die Eigenschaftenansicht zu öffnen, oder klicken Sie mit der rechten Maustaste auf den Broker, und klicken Sie auf Eigenschaften, um den Eigenschaftendialog zu öffnen. Die Brokereigenschaften werden angezeigt.
    2. Geben Sie den erforderlichen Wert in Typ des Authentifizierungsprotokolls ein.

      Hier können Sie eine beliebige Kombination der Optionen 'P', 'M', 'S' und 'R' eingeben; zulässige Kombinationen sind beispielsweise 'S', 'SR', 'RS', 'R', 'PS', 'SP', 'PSR', 'SRM', 'MRS' oder 'RSMP'.

      Die Reihenfolge, in der die Optionen angegeben werden, ist relevant; der Broker sucht nach der ersten Option, die der Client unterstützt. Soll der Broker immer das stärkste Protokoll unterstützen, müssen Sie 'RSMP' auswählen.

    3. Bei Auswahl von 'S' oder 'R' im Feld Typ des Authentifizierungsprotokolls müssen Sie den Namen der SSL-Schlüsselringdatei sowie den Namen der SSL-Kennwortdatei angeben.
    4. Klicken Sie auf OK.
    5. Konfigurieren Sie den Broker mit dem Befehl mqsicreatebroker oder mqsichangebroker und den folgenden beiden Parametern:
      UserNameServerQueueManagerName (-s)
      Dieser Parameter definiert den Namen des Warteschlangenmanagers, der dem Benutzernamensserver zugeordnet ist. Geben Sie diesen Parameter an, wenn Sie entweder Authentifizierungsservices und/oder Publish/Subscribe-Zugriffssteuerungsservices benötigen.
      Publish/SubscribeAccess Control Flag (-j)
      Dieses Flag muss zusätzlich zum Parameter UserNameServerQueueManagerName gesetzt werden, wenn die Publish/Subscribe-Zugriffssteuerungsservices verwendet werden sollen.

      Die Verwendung der Authentifizierungsservices im Broker wird auf Ebene des IP-Empfangsknotens aktiviert, nicht durch einen Parameter in diesen Befehlen.

Beispielkennwortdateien

Zusammen mit WebSphere Event Broker werden die beiden Beispieldateien password.dat und pwgroup.dat geliefert.

  • Bei pwgroup.dat handelt es sich um die eine Beispieldatei, die Sie verwenden können, wenn das Flag -j gesetzt wird.
  • Die Datei password.dat ist eine Beispieldatei, die verwendet wird, wenn die Standardeinstellungen übernommen werden.
Die Datei password.dat hat das folgende Layout:
# Dies ist eine Kennwortdatei.

# Jede Zeile enthält zwei erforderliche Token, die durch Kommas
# getrennt sind. Das erste Token ist eine Benutzer-ID, das zweite
# das Kennwort dieses Benutzers.

#USERNAME PASSWORD
========================
subscriber,subpw
admin,adminpw
publisher,pubpw 

Der Inhalt dieser Datei ergänzt die Benutzer- und Gruppeninformationen, die vom Benutzernamensserver aus dem Betriebssystem abgerufen werden. Die Benutzernamen, die in der Datei, aber nicht im Betriebssystem definiert sind, werden von der Brokerdomäne als unbekannt eingestuft. Benutzernamen, die im Betriebssystem, nicht aber in der Kennwortdatei definiert sind, erhalten keinen Zugriff auf das System.

Die Datei pwgroup.dat enthält Gruppeninformationen sowie Benutzer- und Kennwortinformationen. Zu jedem Benutzereintrag gehört eine Liste mit Gruppennamen, bei denen es sich um die Gruppen handelt, zu denen der Benutzer gehört.

Die Datei pwgroup.dat hat das folgende Layout:
# Dies ist eine Kennwortdatei.
#Jede Zeile enthält mindestens zwei erforderliche Token, die durch
#Kommas getrennt sind. Das erste Token ist eine Benutzer-ID, das zweite
#ein Kennwort. Alle weiteren Token geben die Gruppen an, zu denen 
#der Benutzer gehört. 

#USERNAME PASSWORD  GROUPS 
subscriber,subpw,group1,group2,group3 
admin,adminpw,group2 
publisher,pubpw,group2,group4 
Wie oben schon erwähnt, kann diese Datei als einzige Quelle für die Benutzer-, Gruppen- und Kennwortinformationen für die Brokerdomäne verwendet werden.

Wenn die Benutzer- und Kennwortinformationen aus dem Betriebssystem abgerufen wurden und diese aktualisierten Informationen nun im Brokernetz implementiert werden sollen, müssen Sie den Benutzernamensserver und die Broker stoppen, die Datei aktualisieren und anschließend den Benutzernamensserver und die Broker erneut starten.

Wenn die Kennwörter aus dem Betriebssystem abgerufen wurden, werden Änderungen vom Broker automatisch verteilt. Benutzer oder Kennwörter werden mit den üblichen Managementtools des Betriebssystems geändert.

Authentifizierung im JMS-Client

Für Clientanwendungen, die WebSphere MQ-Klassen für Java Message Service Version 5.3 vor CSD4 verwenden, hat die Clientanwendung immer den Authentifizierungsprotokolltyp 'PM'. Die Clientanwendung und der Broker vereinbaren das Protokoll, das für eine Sitzung verwendet wird. Unterstützt der Broker beide Protokolle (wurde in der Workbench-Definition eines Brokers also 'PM' oder 'MP' gesetzt), wird das Protokoll ausgewählt, das in der Workbench zuerst angegeben wurde.

Für Clientanwendungen, die WebSphere MQ-Klassen für Java Message Service Version 5.3, CSD10 (plus APAR IC47044) bzw. CSD11 oder höher oder WebSphere MQ-Klassen für Java Message Service Version 6.0 oder höher verwenden, unterstützt die Clientanwendung zwei Authentifizierungsstufen.

Es besteht die Möglichkeit, eine TopicConnectionFactory zur Unterstützung des Authentifizierungsmodus MQJMS_DIRECTAUTH_BASIC oder MQJMS_DIRECTAUTH_CERTIFICATE zu konfigurieren. MQJMS_DIRECTAUTH_BASIC entspricht der Authentifizierungsstufe 'PM', MQJMS_DIRECTAUTH_CERTIFICATE der Authentifizierungsstufe 'SR'.

Wenn Sie die Authentifizierungsservices für einen Real-timeInput-Knoten erfolgreich konfiguriert haben, muss eine JMS-Clientanwendung beim Herstellen einer Verbindung ihre Berechtigungsnachweise angeben. Zur Herstellung einer Verbindung bei dieser Konfiguration übergibt die betreffende JMS-Clientanwendung ein Benutzer-ID/Kennwort-Paar an die Methode TopicConnectionFactory.createTopicConnection; Beispiel:
factory.createTopicConnection("user1", "user1pw");

Wurden keine oder ungültige Berechtigungsnachweise angegeben, empfängt die Anwendung eine eingebettete JMS-Ausnahme mit dem MQJMS-Fehlertext.

Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. Alle Rechte vorbehalten.
Letzte Aktualisierung : 2009-02-17 15:50:00

ap12233_