Einträge von Zugriffssteuerungslisten (ACL) erlauben oder verweigern einem Benutzer den Zugriff auf ein Objekt. Einzelne Zugriffssteuerungslisteneinträge sichern jedoch das Objekt nicht, da der Zugriffssteuerungslisteneintrag nicht die Identität des Benutzers verifizieren kann. Ein Zugriffssteuerungslisteneintrag enthält den Benutzernamen und kann einen Hostnamen oder Domänennamen angeben. Es ist beispielsweise möglich, dass ein Benutzer Zugriff auf die Objekte erhält, indem er einen Account auf einem Computer anlegt, der einen Hostnamen aufweist, welcher der gleiche wie ein autorisierter Windows-Domänennamen ist. Verwenden Sie Zugriffssteuerungslisteneinträge, um den Zugriff auf die Objekte in der Brokerdomäne zu kontrollieren, aber benutzen Sie sie nicht, um Brokerdomänen zu schützen; verwenden Sie SSL oder Sicherheitsexits, um die Kanäle zwischen Komponenten in der Brokerdomäne zu schützen.
WebSphere Message Broker verwendet Zugriffssteuerungslisteneinträge, um festzulegen, welche Benutzer und Gruppen Objekte in der Brokerdomäne bearbeiten können. Einem Benutzer bzw. einer Gruppe können vier verschiedene Zugriffsebenen zugeordnet werden: Vollständig, Anzeigen, Implementieren und Bearbeiten. Für die jeweiligen Objekttypen sind nicht alle Zugriffsebenen zulässig; unter ACL-Berechtigungen finden Sie eine Liste mit den Berechtigungen, die den jeweiligen Objekttypen zugeordnet werden können, sowie eine Zusammenfassung der Aktionen, die der Benutzer bzw. die Gruppe ausführen können.
Um die Anzahl der Zugriffssteuerungseinträge, die von einem Brokeradministrator erstellt werden müssen, zu reduzieren, weisen die ACL-Berechtigungen ein hierarchisches Verhalten auf. Das Stammelement der Baumstruktur ist das ObjektConfigManagerProxy, dem drei untergeordnete Elemente zugeordnet sind: RootTopic, Subscriptions und PubSubTopology. Dem Objekt PubSubTopology sind null oder mehrere Broker untergeordnet, und jeder Broker verfügt über null oder mehrere untergeordnete Ausführungsgruppen. Wenn ein ACL-Eintrag zu einem bestimmten Objekt hinzugefügt wird, gilt diese Berechtigung für das Objekt und alle untergeordneten Objekte in der Hierarchie, es sei denn, die Berechtigung wird von einem anderen ACL-Eintrag außer Kraft gesetzt.
Unter z/OS müssen Sie ein OMVS-Segment für Benutzer-IDs und Gruppen erstellen, damit ein Konfigurationsmanager Benutzer-IDs und Gruppeninformationen aus der Datenbank des externen Sicherheitsmanagers (ESM; External Security Manager) abrufen kann.
Das folgende Diagramm stellt eine Beispielhierarchie dar:
Die folgenden Beispiele machen deutlich, wie das hierarchische Verhalten in der Praxis funktioniert.
Beispiel 1
Dem BenutzerA sind keine Zugriffsteuerungseinträge zugeordnet. Deshalb kann BenutzerA keine Objekte in der Hierarchie bearbeiten oder in der Hierarchie definierte Objekte anzeigen.
Beispiel 2
BenutzerB hat einen Zugriffssteuerungslisteneintrag, der ihm eine Implementierungsberechtigung für die Ausführungsgruppe 'Eg1A' verleiht. Dies verleiht ihm implizit eine Anzeigeberechtigung für 'PubSubTopology' und 'Broker1'. BenutzerB muss in der Lage sein, 'PubSubTopology' und 'Broker1' anzuzeigen (z. B. im Message Brokers Toolkit), damit er 'Eg1A' implementieren kann.
Da BenutzerB keine Zugriffssteuerungslisteneinträge für 'PubSubTopology' oder 'Broker1' hat, übernimmt er keinen Zugriff auf die anderen Broker oder Ausführungsgruppen in der Hierarchie. In der Praxis bedeutet dies, dass BenutzerB zwar sehen kann, dass eine andere Ausführungsgruppe für 'Broker1' definiert wurde, er kann jedoch keine Details (einschließlich des Namens der Ausführungsgruppe) anzeigen. Ebenso kann BenutzerB sehen, dass sich ein weiterer Broker in der Topologie befindet, es werden jedoch keine Details angezeigt. BenutzerB hat keinen Zugriff auf 'RootTopic' oder auf 'Subscriptions' (die Subskriptionstabelle).
mqsicreateaclentry testcm -u UserB -a -x D -b Broker1 -e Eg1AMit dem Befehl mqsilistaclentry werden dann die folgenden Informationen angezeigt:
BIP1778I: userb -USER - D - Broker1/Eg1A - ExecutionGroup
Beispiel 3
CMP Anzeigen
RootTopic Anzeigen
Subs Anzeigen
Topology Anzeigen
Broker1 Vollständig
Eg1A Vollständig
Eg1B Vollständig
Broker2 Anzeigen
Eg2A Anzeigen
Eg2B Anzeigen
mqsicreateaclentry testcm -u UserC -a -x V -p mqsicreateaclentry testcm -u UserC -a -x F -b Broker1Mit dem Befehl mqsilistaclentry werden dann die folgenden Informationen angezeigt:
BIP1778I: userc - USER - V - ConfigManagerProxy - ConfigManagerProxy BIP1778I: userc - USER - F - Broker1 - Broker
Beispiel 4
CMP Vollständig
RootTopic Vollständig
Subs Vollständig
Topology Vollständig
Broker1 Anzeigen
Eg1A Anzeigen
Eg1B Anzeigen
Broker2 Vollständig
Eg2A Vollständig
Eg2B Vollständig
mqsicreateaclentry testcm -u UserD -a -x F -p mqsicreateaclentry testcm -u UserD -a -x V -b Broker1Mit dem Befehl mqsilistaclentry werden dann die folgenden Informationen angezeigt:
BIP1778I: userd - USER - F - ConfigManagerProxy - ConfigManagerProxy BIP1778I: userd - USER - V - Broker1 - BrokerMit dem folgenden Befehl können dann die Zugriffssteuerungslisteneinträge für BenutzerD gelöscht werden:
mqsideleteaclentry testcm -u UserD -a -b Broker1
Um die Zugriffssteuerungseinträge für ein Objekt ändern zu können, muss der Benutzer über die vollständige Berechtigung für das Objekt oder eines der ihm übergeordneten Objekte in der Hierarchie verfügen. Dies bedeutet, dass bei der Berechtigung zum Ändern der ACLs nach dem oben beschriebenen Prinzip vorgegangen wird, mit der Ausnahme, dass Zugriffsberechtigungen für ACLs nicht durch Erteilen einer niedrigeren Berechtigung weiter unten in der Baumstruktur entfernt werden können; wäre dies nicht der Fall, könnte sich ein Benutzer selbst eine Anzeigeberechtigung erteilen und wäre dann nicht mehr in der Lage, diese zu entfernen.
ACL-Einträge können unter Verwendung der Java-Konfigurationsmanager-Proxy-API oder der Befehle mqsicreateaclentry, mqsideleteaclentry, und mqsilistaclentry bearbeitet werden.