Mehrere Sicherheitsdomänen

WebSphere Security Domains (WSD) bietet die Flexibilität, mehrere Sicherheitskonfigurationen in WebSphere Application Server zu verwenden. WSD wird auch unter den Bezeichnungen "mehrere Sicherheitsdomänen" oder einfach "Sicherheitsdomänen" verwendet. Sie können für unterschiedliche Anwendungen unterschiedliche Sicherheitsattribute, z. B. "UserRegistry" konfigurieren.

Anmerkung: WebSphere Application Server Version 7.0 bietet Unterstützung für mehrere Sicherheitsdomänen. Sie können unterschiedliche Sicherheitskonfigurationen erstellen und sie unterschiedlichen Anwendungen in Prozessen von WebSphere Application Server zuordnen. Wenn Sie mehrere Sicherheitsdomänen erstellen, können Sie unterschiedliche Sicherheitsattribute für Verwaltungs- und Benutzeranwendungen in einer Zellenumgebung konfigurieren. Sie können unterschiedliche Anwendungen für die Verwendung unterschiedlicher Sicherheitskonfigurationen konfigurieren, indem Sie die Server oder Cluster oder SIBs (Service Integration Bus), in denen diese Anwendungen ausgeführt werden, den Sicherheitsdomänen zuordnen. Mehrere Sicherheitsdomänen können nur von Benutzern mit Administratorrolle konfiguriert werden.

Vorteile der Sicherheitsdomänen

WebSphere Security Domains bieten zwei wichtige Vorteile:

  • Verwaltungsanwendungen unter WebSphere Application Server können mit einem anderen Satz Sicherheitskonfigurationen konfiguriert werden wie die Benutzeranwendungen.
  • Bei Verwendung von Sicherheitsdomänen kann eine Gruppe von Anwendungen einen anderen Satz Sicherheitskonfigurationen verwenden wie eine andere Gruppe von Anwendungen.

    [z/OS]Beispielsweise kann die Verwaltung von WebSphere Application Server für die Verwendung einer RACF-Benutzerregistry konfiguriert werden, während die Anwendungen für eine LDAP-Benutzerregistry konfiguriert werden.

    [AIX Solaris HP-UX Linux Windows][IBM i]Beispielsweise kann die Verwaltung von WebSphere Application Server für die Verwendung eines eingebundenen Repositorys als Benutzerregistry konfiguriert werden, während die Anwendungen für eine LDAP-Benutzerregistry konfiguriert werden.

In früheren Versionen von WebSphere Application Server verwenden alle Verwaltungsanwendungen und Benutzeranwendungen die meisten Sicherheitsattribute gemeinsam. Alle Verwaltungsanwendungen und Benutzeranwendungen in WebSphere Application Server verwenden standardmäßig Attribute für globale Sicherheit. Beispielsweise wird eine in der globalen Sicherheit definierte Benutzerregistry verwendet, um einen Benutzer für jede Anwendung in der Zelle zu authentifizieren.

In diesem Release von WebSphere Application Server können Sie jedoch mehrere weitere Sicherheitsattribute für Benutzeranwendungen verwenden, eine Sicherheitsdomäne für die Sicherheitsattribute festlegen, die abweichend definiert werden müssen, und diese Attribute den Servern und Clustern zuordnen, auf denen sich die entsprechenden Benutzeranwendungen befinden. Es ist auch möglich, eine Sicherheitsdomäne einer Zelle zuzuordnen. Alle Benutzeranwendungen in der Zelle verwenden diese Sicherheitsdomäne, wenn ihnen vorher keine Sicherheitsdomäne zugeordnet wurde. Allerdings werden die Attribute der globalen Sicherheit weiterhin für Verwaltungsanwendungen benötigt, z. B. für die Administrationskonsole, für Namensressourcen und MBeans.

Wenn Sie in früheren Releases von WebSphere Application Server die Sicherheit auf Serverebene verwendet haben, sollten Sie jetzt mehrere Sicherheitsdomänen verwenden, weil sie flexibler und einfacher zu konfigurieren sind.

Die Sicherheit auf Serverebene wird in diesem Release nicht weiter unterstützt. Nähere Informationen finden Sie im Artikel Beziehung zwischen globaler Sicherheit und Sicherheitsdomänen.

Beziehung zwischen globaler Sicherheit und Sicherheitsdomänen

Die globale Sicherheit gilt für alle Verwaltungsfunktionen und die Standardsicherheitskonfiguration für Benutzeranwendungen. Mit Sicherheitsdomänen können Sie für Benutzeranwendungen eine angepasste Konfiguration definieren.

Damit Sicherheitsdomänen erstellt werden können, muss zuvor die Konfiguration der globalen Sicherheit definiert worden sein. Die Konfiguration der globalen Sicherheit wird von allen Verwaltungsanwendungen, wie Administrationskonsole, Namensressourcen und MBeans, verwendet. Sind keine Sicherheitsdomänen konfiguriert, verwenden alle Anwendungen die Informationen aus der Konfiguration der globalen Sicherheit. Benutzeranwendungen wie EJBs (Enterprise JavaBeans) und Servlets sowie die Verwaltungsanwendungen verwenden dieselbe Sicherheitskonfiguration.

Wenn Sie eine Sicherheitsdomäne definieren und ihr einen Geltungsbereich zuordnen, verwenden nur die Benutzeranwendungen in diesem Geltungsbereich die in der Sicherheitsdomäne definierten Sicherheitsattribute. Die Verwaltungsanwendungen sowie die Benennungsoperationen in diesem Geltungsbereich verwenden die Konfiguration der globalen Sicherheit. Definieren Sie die Sicherheitsattribute auf Domänenebene, die von den Attributen auf globaler Ebene abweichen müssen. Wenn die Informationen identisch sind, müssen sie in der Sicherheitsdomäne nicht dupliziert werden. Attribute, die in der Domäne nicht definiert sind, werden aus der globalen Konfiguration abgerufen. Die Konfigurationsdaten der globalen Sicherheit sind in der Datei security.xml im Verzeichnis $WAS_HOME/profiles/$ProfileName/cells/$CellName gespeichert.

In der folgenden Abbildung ist ein Beispiel für eine Sicherheitsdomäne dargestellt, in der der Zelle, einem Server und einem Cluster unterschiedliche Sicherheitsdomänen zugeordnet sind. Wie in der Abbildung dargestellt verwenden die Benutzeranwendungen im Server S1.1 und im Cluster die in den Domänen Domain2 bzw. Domain3 definierten Sicherheitsattribute (weil diesen Domänen diese Geltungsbereiche zugeordnet sind). Server S2.2 ist keiner Domäne zugeordnet. Folglich verwendet die Benutzeranwendung in S2.2 die Domäne, die der Zelle standardmäßig zugeordnet ist (Domain1). Sicherheitsattribute, die in der Domänenebene nicht angegeben sind, werden aus der globalen Konfiguration abgerufen.

Abbildung 1. Geltungsbereiche, die einer Sicherheitsdomäne zugeordnet werden könnenEin Beispiel für eine Umgebung mit mehreren Sicherheitsdomänen, in der die Zelle, ein Server und ein Cluster unterschiedlichen Sicherheitsdomänen zugeordnet sind. Wie in der Abbildung gezeigt, verwenden die Benutzeranwendungen in Server S1.1 und der Cluster Sicherheitsattribute, die in der Domäne Domain2 bzw. Domain3 definiert sind (diese Geltungsbereiche sind den Domänen zugeordnet). Server S2.2 ist keiner Domäne zugeordnet. Deshalb verwendet die Benutzeranwendung in S2.2 die Domäne, die der Zelle (Domain1) standardmäßig zugeordnet ist. Sicherheitsattribute, die auf der Domänenebene fehlen, werden aus der globalen Konfiguration abgerufen.

In der folgenden Abbildung sind die verschiedenen allgemeinen Sicherheitsattribute dargestellt, die in der Konfiguration der globalen Sicherheit definiert werden können, und diejenigen, die auf Domänenebene überschrieben werden können.

Abbildung 2. Sicherheitsattribute, die in der Sicherheitsdomäne konfiguriert werden könnenVerschiedene allgemeine Sicherheitsattribute, die in der globalen Sicherheitskonfiguration definiert werden können, und Sicherheitsattribute, die auf Domänenebene überschrieben werden können.

Inhalt einer Sicherheitsdomäne

Eine Sicherheitsdomäne wird durch zwei Konfigurationsdateien dargestellt. Eine Konfigurationsdatei enthält die Liste der Attribute, die in der Sicherheitsdomäne konfiguriert sind. Die andere Konfigurationsdatei enthält den Geltungsbereich, in dem die Sicherheitsdomäne verwendet wird. Die Informationen der Sicherheitsdomäne sind im Verzeichnis $WAS_HOME/profiles/$ProfileName/config/waspolicies/default/securitydomains/$SecurityDomainName gespeichert. Für jede konfigurierte Sicherheitsdomäne wird ein Verzeichnis mit dem Namen $SecurityDomainName erstellt, das folgende zwei Dateien enthält: Die Datei security-domain.xml enthält die Liste der Sicherheitsattribute, die für die Sicherheitsdomäne konfiguriert sind, und die Datei security-domain-map.xml enthält den Geltungsbereich, in dem die Sicherheitsdomäne verwendet werden soll.

In der folgenden Abbildung sind die Position und der Inhalt der wichtigsten Dateien für die Sicherheitsdomäne dargestellt:

Abbildung 3. Position und Inhalt der wichtigsten Dateien für die SicherheitsdomänePosition und Inhalt der wichtigsten Dateien für die Sicherheitsdomäne.
Anmerkung: Diese Dateien sollten nicht manuell geändert werden. Verwenden Sie statt dessen die Tasks der Administrationskonsole oder Scripting-Befehle, um die Dateien zu ändern. Eine vollständige Liste der Verwaltungstasks und Scripting-Befehle finden Sie am Ende dieses Artikels unter den zugehörigen Tasks.

Sicherheitsdomänen erstellen

Verwenden Sie statt dessen die Tasks der Administrationskonsole oder Scripting-Befehle, um Sicherheitsdomänen zu erstellen. Klicken Sie in der Administrationskonsole auf Sicherheit > Sicherheitsdomänen, um die Sicherheitsdomänen aufzurufen. Für jede Anzeige in der Administrationskonsole ist Hilfe verfügbar.

Eine vollständige Liste der Tasks der Administrationskonsole und der Scripting-Befehle finden Sie in den Links unter den zugehörigen Tasks am Ende dieses Artikels.

Wenn Sie eine Sicherheitsdomäne definieren müssen sie einen eindeutigen Namen für die Domäne angeben, die Sicherheitsattribute, die für die Sicherheitsdomäne konfiguriert werden sollen, und die Geltungsbereiche, in denen die Sicherheitsdomäne verwendet werden soll. Nach der Konfiguration müssen die Server, die die Sicherheitsdomäne verwenden, erneut gestartet werden. Die Benutzeranwendungen in diesen Geltungsbereichen verwenden anschließend die in der Sicherheitsdomäne definierten Attribute. Attribute, die auf Domänenebene nicht konfiguriert sind, werden aus der globalen Konfiguration abgerufen. Verwaltungsanwendungen und Benennungsoperationen in den Geltungsbereichen verwenden immer die Sicherheitsattribute aus der Konfiguration der globalen Sicherheit. Diese Attribute müssen aktiv verwaltet werden.

Neue Attribute der Sicherheitsdomäne müssen mit den Attributen der globalen Sicherheit, die von den der Domäne zugeordneten Benutzeranwendungen übernommen werden, kompatibel sein.

Abgesehen von JAAS- und angepassten Eigenschaften werden globale Attribute nach ihrer Anpassung für eine Domäne von den Benutzeranwendungen nicht mehr verwendet.

In der Anzeige für die Sicherheitsdomäne in der Administrationskonsole können Sie für Ihre Domäne Ressourcen zuordnen und die geeigneten Sicherheitsattribute auswählen. In der Anzeige sind die wichtigsten Sicherheitsattribute der globalen Konfiguration aufgeführt. Sie können entscheiden, ob diese Attribute gegebenenfalls auf Domänenebene überschrieben werden sollen. Nachdem Sie die Attribute auf Domänenebene konfiguriert und gespeichert haben, wird im Summenwert der Anzeige der angepasste Wert für die Domäne angezeigt (durch das in schwarzem Text dargestellte Wort "Angepasst" gekennzeichnet).

Ein Geltungsbereich (Server, Cluster, SIB oder Zelle) kann nur einer Domäne zugeordnet werden. Beispielsweise können nicht zwei Domänen mit zellenweitem Geltungsbereich definiert werden. Es ist jedoch möglich, in derselben Sicherheitsdomäne mehrere Geltungsbereiche zu definieren. Beispielsweise kann eine Domäne innerhalb der Zelle die Geltungsbereiche Server1 und Server2 haben.

Unter "Zugeordnete Geltungsbereiche" in der Anzeige der Sicherheitsdomäne werden zwei Ansichten angezeigt: eine Ansicht, in der die Geltungsbereiche für die Domäne ausgewählt und zugeordnet werden können, und eine Ansicht, in der eine Liste der derzeit zugeordneten Geltungsbereiche angezeigt wird. Zu Ihrer Unterstützung wird außerdem die Flexibilität bereitgestellt, alle Sicherheitsattribute aus einer vorhandenen Sicherheitsdomäne oder die globale Konfiguration in eine neue Sicherheitsdomäne zu kopieren und anschließend nur diejenigen Attribute zu ändern, die abweichend definiert werden müssen. Es ist jedoch weiterhin erforderlich, diesen kopierten Domänen die Geltungsbereiche zuzuordnen.

Mit Scripting-Befehlen können Sie ebenfalls Sicherheitsdomänen erstellen, kopieren und ändern. Nachdem Sie eine Domäne erstellt haben, müssen Sie die geeigneten Befehle ausführen, um ihr Sicherheitsattribute und Geltungsbereiche zuzuordnen.

Attribute für Sicherheitsdomänen konfigurieren

Nachfolgend sind die Sicherheitsattribute aufgeführt, die auf Domänenebene in WebSphere Application Server Version 9.0 konfiguriert werden können:

  • Anwendungssicherheit
  • Java™-2-Sicherheit
  • Benutzerrealm (Registry)
  • Trust-Association
  • SPNEGO-Webauthentifizierung (Simple and Protected GSS-API Negotiation)
  • RMI/IIOP-Sicherheit (CSIv2)
  • JAAS-Anmeldung (Application, System and J2C Authentication Data)
  • Java Authentication SPI
  • Attribute für das Authentifizierungsverfahren
  • Berechtigungsprovider
  • Eingebundene Repositorys
  • [z/OS]z/OS-Eigenschaften
  • Angepasste Eigenschaft

In den Anzeigen für Sicherheitsdomänen in der Administrationskonsole werden alle diese Sicherheitsattribute angezeigt.

Einige andere bekannte Attribute, die auf Domänenebene nicht überschrieben werden können, sind Kerberos, Audit, Web Single Sign-on (SSO) und Tivoli Access Manager (TAM). Das Attribut "Secure Socket Layer (SSL)" unterstützt bereits unterschiedliche Geltungsbereiche, ist aber nicht Teil der Domänenkonfiguration. Für alle Attribute, die nicht auf Domänenebene unterstützt werden, gilt, dass die Benutzeranwendungen in einer Domäne Konfiguration dieser Attribute aus der globalen Ebene verwenden.

Neue Attribute in der Sicherheitsdomäne müssen mit denjenigen Attributen der globalen Sicherheit kompatibel sein, die von den der Domäne zugeordneten Benutzeranwendungen übernommen werden. Diese Attribute müssen aktiv verwaltet werden. Wenn Sie beispielsweise eine JAAS-Konfiguration auf Domänenebene anpassen, müssen Sie sicherstellen, dass sie mit der auf globaler Ebene konfigurierten Benutzerregistry verwendet werden kann (falls die Benutzerregistry nicht auf Domänenebene angepasst wurde).

Abgesehen von JAAS- und angepassten Eigenschaften werden globale Attribute nach ihrer Anpassung für eine Domäne von den Benutzeranwendungen nicht mehr verwendet.

Die Clientlaufzeitumgebung von Tivoli Access Manager wird für die Authentifizierung (die von TrustAssociationInterceptor und PDLoginModule verwendet wird) und die Berechtigung (wird für JACC verwendet) verwendet, indem eine Verbindung zu TAM-Servern hergestellt wird. Es gibt nur eine einzige TAM-Laufzeitumgebungen (Tivoli Access Manager), die von allen Servern in einer Zelle gemeinsam genutzt wird. Weitere Informationen finden Sie im Artikel zur Konfiguration des JACC-Providers von Tivoli Access Manager.

Es ist nicht möglich, auf Sicherheitsdomänenebene eine abweichende Tivoli Access Manager-Konfiguration zu verwenden, um die Konfiguration auf Zellenebene zu überschreiben. Sie können die TAI- (Trust-Association-Interceptor) und JACC-Konfiguration jedoch bis zu einem gewissen Grad auf Sicherheitsdomänenebene konfigurieren. Beispielsweise können Sie einen anderen Trust Association Interceptor (TAI) oder Berechtigungsprovider verwenden. Da die TAM-Serverkonnektivität können nur auf globaler Ebene definiert werden kann, können Sie verschiedene TAIs auf Sicherheitsdomänenebene definieren und konfigurieren. Einige dieser TAIs verwenden das TAM-Benutzerrepository möglicherweise nicht, aber andere schon. Die TAIs, die keine verbindung zu TAM herstellen müssen, stellen auch eine Verbindung zum global definierten TAM-Server her. Für die Berechtigung können Sie ebenfalls verschiedene externe Berechtigungsprovider auf Domänenebene konfigurieren. Falls einer dieser externen Berechtigungsprovider jedoch eine Verbindung zu TAM herstellen muss, kommunizieren sie dann letztendlich mit dem einem global konfigurierten TAM-Server.

Sicherheitsdomänen Geltungsbereiche zuordnen

In WebSphere Application Server Version 9.0 können Sie eine Sicherheitsdomäne auf Zellenebene, Serverebene, Clusterebene und SIB-Ebene zuordnen.
Anmerkung: Weitere Informationen zum Service Integration Bus und zur Bussicherheit in mehreren Sicherheitsdomänen für WebSphere Application Server Version 9.0 finden Sie im Artikel Nachrichtensicherheit und mehrere Sicherheitsdomänen.

Wenn einer Sicherheitsdomäne ein Server zugeordnet wird, der nicht Teil eines Clusters ist, verwenden alle Benutzeranwendungen in dem betreffenden Server die Attribute aus der Sicherheitsdomäne. Sicherheitsattribute, die nicht angegeben sind, werden aus der Konfiguration der globalen Sicherheit abgerufen. Wenn der Server zu einem Cluster gehört, kann die Sicherheitsdomäne dem Cluster, aber nicht einzelnen Membern dieses Clusters zugeordnet werden. Das Sicherheitsverhalten ist in allen Cluster-Membern konsistent.

Wenn ein Server in ein Cluster aufgenommen werden soll, erstellen Sie zunächst den Cluster und ordnen Sie ihm die Sicherheitsdomäne zu. Möglicherweise haben Sie einem Server eine Domäne zugeordnet, bevor der Server Teil eines Clusters war. In diesem Fall beachtet der Code der Sicherheitslaufzeit die Domäne nicht, obwohl sie dem Server direkt zugeordnet ist. Wenn ein Server ein Cluster-Member ist, ignoriert die Sicherheitslaufzeit Sicherheitsdomänen, die dem Server direkt zugeordnet sind. Entfernen Sie den Servergeltungsbereich aus der Sicherheitsdomäne und ordnen Sie statt dessen den Clustergeltungsbereich zu.

Eine Sicherheitsdomäne kann auch der Zelle zugeordnet werden. Dies geschieht normalerweise dann, wenn alle Benutzeranwendungen in WebSphere Application Server einer Sicherheitsdomäne zugeordnet werden sollen. In diesem Szenario verwenden alle Verwaltungsanwendungen und Benennungsoperationen die Konfiguration der globalen Sicherheit, während aller Benutzeranwendungen die Konfiguration der Domänenebene verwenden. Wenn Sie die Informationen der Sicherheitskonfiguration für Verwaltungsanwendungen und für Benutzeranwendungen aufteilen möchten, ist dies die erforderliche Vorgehensweise.

Wenn Sie eine heterogene Umgebung verwenden oder künftig verwenden werden und wenn Sie Sicherheitsdomänen auf Zellenebene zuordnen möchten, lesen Sie die Informationen im Artikel Sicherheitsdomänen in einer heterogenen Umgebung.

Wenn Sie mit einem Basisprofilserver arbeiten, für den eine eigene Sicherheitsdomäne konfiguriert ist, die anschließend in einen Deployment Manager eingebunden wird, dann ordnen Sie den Geltungsbereich des Servers der Sicherheitsdomäne zu, nicht den Geltungsbereich der Zelle. Wenn Sie den Knoten einbinden werden die Informationen der Sicherheitsdomäne an den Deployment Manager weitergegeben. Wenn der Domäne der Geltungsbereich der Zelle zugeordnet ist, dann wird diese Sicherheitskonfiguration von der Network-Deployment-Konfiguration verwendet. Dies kann Auswirkungen auf vorhandene Anwendungen haben. Während der Einbindung wird der Geltungsbereich der Zelle in den Geltungsbereich des Servers geändert, der eingebunden wird. Wenn der Sicherheitsdomäne der Geltungsbereich des Servers zugeordnet wird, verwendet nur dieser Server die Sicherheitsdomäne, nachdem er eingebunden wurde. Andere Anwendungen in anderen Servern und Clustern sind nicht davon betroffen. Wenn dieser Basisprofilserver jedoch bei dem Prozess des Verwaltungsagenten registriert ist, können Sie der Sicherheitsdomäne den Geltungsbereich der Zelle zuordnen, wenn alle Server aus dem Basisprofil dieselbe Sicherheitsdomäne für alle ihre Benutzeranwendungen verwenden sollen. Weitere Informationen finden Sie im Artikel Knoten mit Sicherheitsdomänen einbinden.

Es ist möglich, eine Sicherheitsdomäne auf Zellenebene und weitere Sicherheitsdomänen verschiedenen Clustern oder Einzelservern (die nicht Teil eines Clusters sind) zuzuordnen. In diese Fall prüft die Sicherheitslaufzeit zunächst, ob dem Server oder Cluster Sicherheitsdomänen zugeordnet sind. Ist dem Server oder Cluster eine Sicherheitsdomäne zugeordnet, werden die darin definierten Sicherheitsattribute für alle Anwendungen in dem betreffenden Server oder Cluster verwendet. Sicherheitsattribute, die in dieser Server- oder Clusterdomäne nicht angegeben sind, werden aus der Konfiguration der globalen Sicherheit abgerufen und nicht aus der Domänenkonfiguration, die der Zelle zugeordnet ist.

Wenn für den Server oder Cluster keine eigene Domäne definiert ist, verwendet der Code der Sicherheitslaufzeit die Sicherheitsattribute aus der Domäne, die der Zelle zugeordnet ist (falls eine solche Domäne definiert ist). Sicherheitsattribute, die in der Zellendomäne nicht angegeben sind, werden aus der Konfiguration der globalen Sicherheit übernommen.

Beziehung zwischen früherer Sicherheit auf Serverebene und neuen Sicherheitsdomänen

In früheren Releases von WebSphere Application Server konnte eine kleine Gruppe von Sicherheitsattributen auf Serverebene zugeordnet werden. Diese Attribute wurden von allen Anwendungen auf der Serverebene verwendet. Die Vorgehensweise, die zur Konfiguration dieser Sicherheitsattribute verwendet wurde, wird in WebSphere Application Server 7.0 nicht weiter unterstützt und wird in einem der künftigen Releases entfernt.

Sie sollten jetzt die neue Unterstützung der Sicherheitsdomänen in WebSphere Application Server 7.0 verwenden, da diese Sicherheitsdomänen einfacher verwaltet werden können und viel flexibler eingesetzt werden können. Beispielsweise müssen Sie in früheren Versionen von WebSphere Application Server eine Sicherheitskonfiguration allen Cluster-Membern manuell zuordnen, indem Sie dieselben Sicherheitsattribute für jeden Server in einem Cluster konfigurieren.

Das Migrationstool migriert die vorhandene Sicherheitskonfiguration auf Serverebene auf die neue Konfiguration der Sicherheitsdomäne, wenn der Script-Kompatibilitätsmodus auf false (-scriptCompatibility="false") gesetzt ist. Für jede Sicherheitskonfiguration eines Servers, der nicht Teil eines Clusters ist, wird eine neue Sicherheitsdomäne erstellt. Wenn ein Server zu einem Cluster gehört, wird eine Sicherheitsdomäne dem Cluster zugeordnet anstatt allen Servern, die Teil dieses Clusters sind. In beiden Fällen werden alle Sicherheitsattribute, die in früheren Releases auf Serverebene konfiguriert wurden, auf die Konfiguration der neuen Sicherheitsdomäne migriert, und den Sicherheitsdomänen werden die geeigneten Geltungsbereiche zugeordnet.

Wenn der Script-Kompatibilitätsmodus auf true gesetzt ist, wird die Sicherheitskonfiguration auf Serverebene nicht auf die neue Konfiguration der Sicherheitsdomänen migriert. Die alte Sicherheitskonfiguration der Server wird unverändert migriert. Die Sicherheitslaufzeit erkennt die alte Sicherheitskonfiguration und verwendet diese Informationen, selbst wenn dem Server direkt oder indirekt eine Sicherheitsdomäne zugeordnet ist. Wenn der Script-Kompatibilitätsmodus auf true gesetzt ist, entfernen Sie die Sicherheitskonfiguration aus der Serverebene und erstellen Sie anschließend eine Sicherheitsdomäne mit derselben Gruppe von Sicherheitsattributen.

Verwendung der Sicherheitsattribute auf Domänenebene durch die Sicherheitslaufzeit und Anwendungen

In diesem Abschnitt wird beschrieben, wie die einzelnen Attribute auf Domänenebene von der Sicherheitslaufzeit verwendet werden und wie sich dies auf die Sicherheit der Benutzeranwendung auswirkt. Weil alle diese Sicherheitsattribute auch auf globaler Ebene definiert werden, finden Sie an anderer Stelle ausführliche Informationen zu diesen Attributen. Dieser Abschnitt konzentriert sich auf die Beschreibung des Verhaltens auf Domänenebene.

  1. Anwendungssicherheit:

    Wählen Sie Anwendungssicherheit aktivieren aus, um die Sicherheit für Benutzeranwendungen zu aktivieren oder zu inaktivieren. Ist diese Option inaktiviert, werden die EJBs und Webanwendungen der Sicherheitsdomäne nicht mehr geschützt. Der Zugriff auf diese Ressourcen wird ohne Benutzerauthentifizierung gewährt. Wenn Sie diese Option aktivieren, wird die J2EE-Sicherheit für alle EJBs und Webanwendungen in der Sicherheitsdomäne durchgesetzt. Voraussetzung hierfür ist, dass die globale Sicherheit in der globalen Sicherheitskonfiguration aktiviert ist. (Sie können die Anwendungssicherheit erst aktivieren, nachdem Sie die globale Sicherheit auf globaler Ebene aktiviert haben.)

  2. Java-2-Sicherheit:

    Wählen Sie "Java-2-Sicherheit verwenden" aus, um die Java-2-Sicherheit auf Domänenebene zu aktivieren oder zu inaktivieren oder um Eigenschaften für die Java-2-Sicherheit zuzuordnen oder hinzuzufügen. Diese Option aktiviert oder inaktiviert die Java-2-Sicherheit auf Prozessebene (JVM), so dass alle Anwendungen (Verwaltungs- und Benutzeranwendungen) die Java-2-Sicherheit aktivieren oder inaktivieren können.

  3. Benutzerrealm (Benutzerregistry):

    In diesem Abschnitt können Sie die Benutzerregistry für die Sicherheitsdomäne konfigurieren. Sie können jede Registry, die auf Domänenebene verwendet wird, gesondert konfigurieren. Weitere Informationen finden Sie im Artikel Attribute für Sicherheitsdomänen konfigurieren.

    Wenn Sie eine Registry auf Domänenebene konfigurieren, können Sie Ihren eigenen Realmnamen für die Registry definieren. Anhand des Realmnamens können Benutzerregistrys voneinander unterschieden werden. Der Realmname wird an mehreren Stellen verwendet: in der Anmeldeanzeige des Java-Clients mit der Eingabeaufforderung an den Benutzer, im Authentifizierungscache und bei Verwendung der nativen Berechtigung.

    Auf der Ebene der globalen Konfiguration erstellt das System den Realm für die Benutzerregistry. In früheren Releases von WebSphere Application Server wird nur eine Benutzerregistry im System konfiguriert. Wenn mehrere Sicherheitsdomänen vorhanden sind, können Sie mehrere Registrys im System konfigurieren. Damit die Realms in diesen Domänen eindeutig sind, konfigurieren Sie einen eigenen Realmnamen für die Sicherheitsdomäne. Sie können auch auswählen, dass vom System ein eindeutiger Realmname erstellt werden soll, wenn dieser eindeutig genug ist. In diesem Fall basiert der Realmname auf der verwendeten Registry.

    Für LDAP-Registrys ist die Angabe "host:port" des LDAP-Servers der vom System generierte Realmname. Für localOS ist der Name der localOS-Maschine der Realmname. Für angepasste Benutzerregistrys ist der Realm der von der Methode getRealm ( ) der angepassten Retistry-Implementierung zurückgegebene Realm.

    Wenn die vom System generierten Namen eindeutig genug sind, können Sie die Option zum Generieren des Realmnamens durch das System auswählen. Andernfalls legen Sie für jede Sicherheitsdomäne, in der die Benutzerregistry konfiguriert ist, einen eindeutigen Real-Namen fest. Wenn dasselbe Benutzerrepository zu Grunde liegt, verwenden Sie in unterschiedlichen Domänen denselben Realmnamen. Aus der Perspektive der Sicherheitslaufzeit haben dieselben Realmnamen dieselben Benutzer- und Gruppeninformationen. Wenn beispielsweise die Benutzer- und Gruppeninformationen aus einem Realm erforderlich sind, wird das erste Benutzerrepository verwendet, das mit dem Realm übereinstimmt.

    Wenn eine nicht zentrale Registry vom Typ "localOS" für eine Domäne konfiguriert wird und diese Domäne Servern oder Clustern auf Knoten zugeordnet ist, die sich nicht auf demselben System wie der Deployment Manager befinden, muss der Realmname angegeben werden. Dieser Realmname muss so lauten, als wäre er auf dem Knoten generiert worden. Dieser Realmname kann durch Aufruf der Methode getRealm() in der MBean "SecurityAdmin" auf diesem Knoten abgerufen werden. Gewöhnlich ist der Realmname für Registrys vom Typ "localOS" der Hostname der Maschine. In diesem Fall sollten Sie den Realmnamen nicht vom System generieren lassen, sondern den Realmnamen abrufen, der von den Prozessen auf dem Knoten verwendet wird.

    Wenn Sie bei der Konfiguration der Benutzerregistry festlegen, dass das System den Realm für die Registry vom Typ "localOS" generieren soll, wählt das System die Registry vom Typ "localOS" aus, die vom Deployment Manager verwendet wird. Sollte der konfigurierte Realm nicht mit dem von den Servern verwendeten Realm übereinstimmen, treten Berechtigungsprobleme auf. Außerdem ist in diesem Fall zu beachten, dass die Domäne, die diese lokale Registry verwendet, nur Servern und Clustern zugeordnet werden kann, die zu Knoten auf derselben Maschine gehören.

    In WebSphere Application Server Version 7.0 kann die Benutzerregistry für eingebundene Repositorys nur auf globaler Ebene konfiguriert werden, aber jede Domäne kann die Registry verwenden, indem sie sie als aktive Registry konfiguriert. In WebSphere Application Server Version 8.0 können Sie eine eindeutige Instanz eines eingebundenen Repositorys auf Domänenebene in einer Umgebung mit mehreren Sicherheitsdomänen konfigurieren.

    Wenn eine Sicherheitsdomäne von der globalen Ebene kopiert wird, werden die auf der globalen Ebene definierten Benutzer und Gruppen ebenfalls in die Sicherheitsdomäne kopiert. Dies trifft auch beim Kopieren aus einer vorhandenen Domäne zu. Eine neu erstellte Sicherheitsdomäne, die das dateibasierte Repository VMM verwendet, setzt voraus, dass der Benutzer im Repository Benutzer und Gruppen ablegt.

    Ebenfalls neu in diesem Release von WebSphere Application Server ist das Kontrollkästchen "Globales Schema für das Modell verwenden" in der Administrationskonsolseite "Realmkonfigurationen", mit dem die globale Schemaoption in einer Umgebung mit mehreren Sicherheitsdomänen gesetzt werden kann. Das globale Schema ist das Schema der Verwaltungsdomäne.

    Wenn mehrere Benutzerregistrys in einem Prozess vorhanden sind, gibt die Namenssuche, die “UserRegistry” als Suchbegriff verwendet, die von den Benutzeranwendungen verwendete Benutzerregistry zurück. Die von Verwaltungsanwendungen verwendete Benutzerregistry ist an den Suchbegriff “AdminUserRegistry” gebunden.

    Wie im Artikel Realmübergreifende Kommunikation beschrieben, müssen die Realms vertrauenswürdig sein, wenn eine Anwendung in einem Realm über LTPA-Token mit einer Anwendung in einem anderen Realm kommuniziert. Die Vertrauensbeziehung kann über den Link Anerkannte Authentifizierungsrealms - eingehend – in der Benutzerregistry-Anzeige oder mit dem Befehl addTrustedRealms aufgebaut werden. Sie können zwischen verschiedenen Realms Vertrauen aufbauen. Ein Benutzer, der an einem Realm angemeldet ist, kann auf Ressourcen in einem anderen Realm zugreifen. Wenn zwischen den beiden Realms kein Vertrauen aufgebaut ist, scheitert die Validierung des LTPA-Tokens.

    Anmerkung: Der in der Datei "web.xml" verwendete Realmname steht mit dem Realm der Benutzerregistry nicht in Beziehung.
  4. Trust-Association:

    Wenn Sie den Trust Association Interceptor (TAI) auf Domänenebene konfigurieren, werden die auf globaler Ebene konfigurierten Interceptor zur Ihrem Komfort auf die Domänenebene kopiert. Sie können die Interceptor-Liste auf Domänenebene an Ihre Anforderungen anpassen. Konfigurieren Sie nur die Interceptor, die auf der Domänenebene verwendet werden sollen.

    Die Trust-Association-Interceptor von Tivoli Access Manager können nur auf globaler Ebene konfiguriert werden. Die Domänenkonfiguration kann sie ebenfalls verwenden, sie darf aber keine andere TAI-Version (Trust Association Interceptor) haben. In der Zelle kann nur eine Instanz der TAIs von Tivoli Access Manager existieren.

  5. SPNEGO-Webauthentifizierung:

    Über die SPNEGO-Webauthentifizierung können Sie SPNEGO für die Authentifizierung von Webressourcen auf der Domänenebene konfigurieren.

    Anmerkung: In WebSphere Application Server Version 6.1 wurde ein TAI eingeführt, der SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) nutzt, um HTTP-Anforderungen für geschützte Ressourcen sicher auszuhandeln und zu authentifizieren. Seit WebSphere Application Server 7.0 wird diese Funktion nicht weiter unterstützt. Die SPNEGO-Webauthentifizierung wird jetzt genutzt, um SPNEGO-Filter dynamisch neu zu laden und den Rückgriff auf die Methode der Anwendungsanmeldung zu ermöglichen.
  6. RMI/IIOP-Sicherheit (CSIv2):

    Die RMI/IIOP-Sicherheitsattribute beziehen sich auf die Eigenschaften des Protokolls CSIv2 (Common Secure Interoperability Version 2). Wenn Sie diese Attribute auf Domänenebene konfigurieren, wird für Ihren Komfort die RMI/IIOP-Sicherheitskonfiguration auf globaler Ebene kopiert.

    Sie können die Attribute ändern, die auf der Domänenebene einen anderen Wert haben sollen. Die Einstellungen der Transportschicht für die eingehende CSIv2-Kommunikation sollten auf globaler Ebene und Domänenebene übereinstimmen. Unterscheiden sich diese Einstellungen, werden die Attribute der Domänenebene auf alle Anwendungen des Prozesses angewendet.

    Wenn ein Prozess mit einem anderen Prozess in einem anderen Realm kommuniziert, werden die LTPA-Authentifizierung und die Weitergabetoken nur dann an den Downstream-Server weitergegeben, wenn dieser Server in der Liste der anerkannten abgehenden Realms enthalten ist. Hierzu kann der Link Anerkannte Authentifizierungsrealms - abgehend – in der Anzeige Abgehende CSIv2-Kommunikation oder der Befehl addTrustedRealms verwendet werden. Weitere Informationen finden Sie im Artikel Realmübergreifende Kommunikation.

  7. JAAS (Java Authentication and Authorization Service):

    Auf der Domänenebene können Sie die Anwendungsanmeldungen mit dem JAAS, die Systemanmeldungen mit dem JAAS und die JAAS-Aliasnamen für J2C-Authentifizierungsdaten konfigurieren. Standardmäßig haben alle Anwendungen des Systems Zugriff auf die JAAS-Anmeldungen, die auf globaler Ebene konfiguriert sind. Die Sicherheitslaufzeit prüft zunächst, ob es JAAS-Anmeldungen auf Domänenebene gibt. Werden keine solchen gefunden, überprüft die Laufzeit die globale Sicherheitskonfiguration auf JAAS-Anmeldungen. Konfigurieren Sie diese JAAS-Anmeldungen nur auf Domänenebene, wenn Sie eine Anmeldung angeben müssen, die exklusiv von den Anwendungen in der Sicherheitsdomäne verwendet wird.

    Für JAAS- und angepasste Eigenschaften gilt, dass sie nach der Anpassung der globalen Attribute für die Domäne weiterhin von Benutzeranwendungen verwendet werden können.

  8. Java Authentication SPI (JASPI)

    Gibt die Konfigurationseinstellungen für einen JASPI-Authentifizierungsprovider (Java Authentication SPI) und zugeordnete Authentifizierungsmodule an, die auf Domänenebene angewendet werden sollen.

    Wählen Sie Provider aus, um einen JASPI-Authentifizierungsprovider zu erstellen bzw. zu bearbeiten.

    Anmerkung: Der JASPI-Authentifizierungsprovider kann mit auf Domänenebene konfigurierten Providern aktiviert werden. Standardmäßig haben alle Anwendungen des Systems Zugriff auf die JASPI-Provider, die auf globaler Ebene konfiguriert sind. Die Sicherheitslaufzeit prüft zunächst, ob es JASPI-Anmeldungen auf Domänenebene gibt. Werden keine solchen gefunden, überprüft die Laufzeit die globale Sicherheitskonfiguration auf JAAS-Anmeldungen. Konfigurieren Sie JASPI-Authentifizierungsprovider in einer Domäne nur, wenn der Provider ausschließlich von den Anwendungen in dieser Sicherheitsdomäne verwendet werden soll.
  9. Attribute des Authentifizierungsverfahrens:

    Gibt die verschiedenen Cacheeinstellungen an, die auf Domänenebene angewendet werden müssen.

    1. Einstellungen des Authentifizierungscache: Hiermit werden die Einstellungen des Authentifizierungscache angegeben. Die Konfiguration in dieser Anzeige wird nur auf diese Domäne angewendet.
    2. LTPA-Zeitlimit: Sie können auf Domänenebene einen anderen LTPA-Zeitlimitwert konfigurieren. Das Standardzeitlimit wird auf globaler Ebene definiert und liegt bei 120 Minuten. Wenn das LTPA-Zeitlimit auf Domänenebene festgelegt wird, wird jedes in der Sicherheitsdomäne beim Zugriff auf Benutzeranwendungen erstellte Token mit dieser Verfallszeit erstellt.
    3. Realmqualifizierte Benutzernamen verwenden: Wenn diese Option aktiviert ist, werden von Methoden wie getUserPrincipal() zurückgegebene Benutzernamen mit dem Sicherheitsrealm (Benutzerregistry) qualifiziert, der von Anwendungen in der Sicherheitsdomäne verwendet wird.
  10. Berechtigungsprovider:

    Auf Domänenebene können Sie einen externen JACC-Provider (Java Authorization Contract for Containers) eines Fremdanbieters konfigurieren. Der JACC-Provider von Tivoli Access Manager kann nur auf globaler Ebene konfiguriert werden. Sicherheitsdomänen können diesen Provider dennoch verwenden, wenn Sie den Berechtigungsprovider nicht durch einen anderen JACC-Provider außer Kraft setzen.

    Die JACC-Attribute, wie z. B. das Richtlinienobjekt, basieren auf der JVM-Version. Dies impliziert, dass es nur ein einziges JACC-Richtlinienobjekt in einem JVM-Prozess geben kann. Wenn Sie jedoch mehrere JACC-Provider konfiguriert haben, muss der Deployment-Manager-Prozess alle diese Provider in derselben JVM verarbeiten, weil er die Berechtigungsrichtlinie von Anwendungen an den jeweilig gültigen Provider weitergeben muss.

    Falls Ihr JACC-Provider in der Lage ist, die Berechtigungsrichtlinie an mehrere Provider weiterzugeben, können Sie ihn auf globaler Ebene konfigurieren. In diesem Fall wird bei der Installation einer Anwendung dieser JACC-Provider im Deployment-Manager-Prozess aufgerufen, und er ist dafür verantwortlich, die Informationen jr nach Anwendungsnamen, der über die Kontext-ID übergeben wird, an den entsprechenden JACC-Provider weiterzugeben.

    Eine andere Methode, dies zu erreichen, ist die Definition der angepassten Eigenschaft jcom.ibm.websphere.security.allowMultipleJaccProviders=true auf globaler Sicherheitsebene. Wenn diese Eigenschaft definiert ist, gibt WebSphere Application Server die Informationen zu den Berechtigungsrichtlinien an den JACC-Provider weiter, der der Domäne zugeordnet ist, die dem Zielserver entspricht, in dem die Anwendung installiert ist. Diese Eigenschaft wird nur im Deployment-Manager-Prozess verwendet, da die verwalteten Server keine Unterstützung für mehrere JACC-Provider bieten.

    [z/OS]Zusätzlich können Sie die folgenden SAF-Berechtigungsoptionen auf der Ebene der Sicherheitsdomäne konfigurieren:
    • Nicht authentifizierte Benutzer-ID
    • Mapper für SAF-Profile
    • SAF-Delegierung aktivieren/inaktivieren
    • APPL-Profil verwenden (bzw. nicht verwenden), um den Zugriff auf WebSphere Application Server einzuschränken
    • Berechtigungsfehlernachrichten unterdrücken (bzw. nicht unterdrücken)
    • Strategie für SMF-Prüfsätze
    • Präfix für SAF-Profile

    [z/OS]CBIND-Prüfungen werden als Verwaltungsoperationen eingestuft, und deshalb wird der auf globaler Ebene definierte Wert für das SAF-Profilpräfix verwendet, wenn der Name der zu prüfenden CBIND-Ressource bestimmt wird. Beispiel: CB.BIND.<Clustername oder SAF-Profilpräfix>.

    [z/OS]Weitere Informationen zu den SAF-Berechtigungsoptionen enthält der Artikel z/OS-SAF-Berechtigung.

  11. Angepasste Eigenschaften:

    Legen Sie auf der Domänenebene angepasste Eigenschaften fest, die entweder neue Eigenschaften sind oder sich von den auf globaler Ebene festgelegten Eigenschaften unterscheiden. Standardmäßig können alle Anwendungen in der Zelle auf die angepassten Eigenschaften der globalen Sicherheitskonfiguration zugreifen. Der Code der Sicherheitslaufzeit prüft zunächst, ob es angepasste Eigenschaften auf Domänenebene gibt. Werden keine solchen gefunden, versucht die Laufzeit, die Eigenschaften aus der globalen Sicherheitskonfiguration abzurufen.

    Für JAAS- und angepasste Eigenschaften gilt, dass sie nach der Anpassung der globalen Attribute für die Domäne weiterhin von Benutzeranwendungen verwendet werden können.

Programmiermodell für Client- und Anwendungssicherheit bei Verwendung von Sicherheitsdomänen

Wenn ein Ein Java-Client oder eine Anwendung, die als Client agiert, auf eine EJB zugreift, wird normalerweise zunächst eine Namenssuche ausgeführt. Die Namensressource, die sowohl von den Verwaltungsanwendungen als auch von den Benutzeranwendungen verwendet wird, wird als Verwaltungsressource betrachtet. Sie wird durch die Konfigurationsdaten der globalen Sicherheit geschützt. In einer Installation mit mehreren Domänen, in der die globale Sicherheit einen Realm (die Benutzerregistry) verwendet und eine Domäne einen anderen Realm, muss der Java-Client sich gegenüber zwei verschiedenen Realms authentifizieren. Die erste Authentifizierung ist für den Realm in der Konfiguration der globalen Sicherheit erforderlich, damit die Benennungsoperation erfolgreich ist, und die zweite Authentifizierung ist für den Zugriff auf die EJB erforderlich, die einen anderen Realm verwendet.

Die Rolle CosNamingRead schützt alle Leseoperationen für Namen. Diese Rolle ist normalerweise dem Sondersubjekt Everyone zugeordnet. Dies bedeutet, dass jeder Benutzer, ob gültig oder nicht, den Namespace finden darf. Wenn mehrere Domänen definiert sind und der Rolle CosNamingRead das Sondersubjekt Everyone zugeordnet ist, werden Sie vom Code der Sicherheitslaufzeit auf der Clientseite nicht zur Anmeldung aufgefordert. Stattdessen verwendet der Code das Subjekt UNAUTHENTICATED, um die Benennungsoperation aufzurufen. Nachdem die Benennungsoperation abgeschlossen ist, wird der Client beim Versuch, auf die EJB zuzugreifen, in einer Anmeldeanzeige darauf hingewiesen, dass der Realm derzeit von der EJB-Anwendung verwendet wird (d. h., der Realm wird in der Domäne verwendet). Der Client gibt anschließend die erforderlichen Benutzerberechtigungsnachweise für den Realm an, mit denen er anschließend auf die EJB zugreifen kann. Diese Logik gilt für alle Varianten der Anmeldequelle, einschließlich properties und stdin, nicht nur für die Einstellung prompt.

Wenn das Sondersubjekt Everyone aus der Rolle CosNamingRead entfernt wird, erhalten Sie zwei Eingabeaufforderungen. Bei Verwendung der Anmeldequelle properties können Sie die Kommentarzeichen der Eigenschaft com.ibm.CORBA.loginRealm in der Datei $WAS_HOME/profiles/$ProfileName/properties/sas.client.props entfernen und die geeigneten Realms unter Verwendung des Trennzeichens “|” hinzufügen. Außerdem müssen Sie die zugehörigen Benutzer und Kennwörter in den Eigenschaften com.ibm.CORBA.loginUserid und com.ibm.CORBA.loginPassword eingeben. Bei Verwendung der programmgesteuerten Anmeldung im Java-Clientcode müssen Sie sich zweimal mit unterschiedlichen Benutzerberechtigungen authentifizieren: einmal vor einer Namenssuche für die EJB (der Benutzer sollte sich im globalen Realm befinden) und danach einmal vor Aufruf einer Methode in der EJB (der Benutzer sollte sich im Realm der EJB-Domäne befinden).

[z/OS]Die im z/OS-Sicherheitsserver definierte Rolle "CosNamingRead " wird nicht referenziert, wenn festgestellt wird, ob Leseoperationen für die Benennung in einer Umgebung mit mehreren Sicherheitsdomänen geschützt sind, selbst wenn die SAF-Berechtigung aktiviert ist. Stattdessen werden die Einstellungen in der Datei admin-authz.xml verwendet. Alternativ können Sie die angepasste Eigenschaft com.ibm.security.multiDomain.setNamingReadUnprotected verwenden, um zu steuern, ob Leseoperationen für die Benennung geschützt werden. Diese Eigenschaft überschreibt alle Zuordnungen zur Rolle "CosNamingRead", unabhängig vom verwendeten Berechtigungsprovider.

Im Allgemeinen muss ein Java-Client für die Authentifizierung bei mehreren unterschiedlichen Realms die Berechtigungsinformationen für alle diese Realms bereitstellen. Wenn die Anmeldequelle prompt oder stdin ist, wird er mehrere Male zur Anmeldung aufgefordert, für jeden Realm einmal. Wenn die Anmeldequelle properties ist, werden die geeigneten Eigenschaften in der Datei sas.client.props (oder einer zugehörigen Datei) für die Authentifizierung bei unterschiedlichen Realms verwendet.

In bestimmten Szenarien ruft ein Client einen Realm möglicherweise mehrfach auf. Beispielsweise kann der Java-Client eine Ressource in realm1 aufrufen, gefolgt vom Zugriff auf eine Ressource über realm2, und kann anschließend zurückkehren, um erneut auf eine Ressource in realm1 zuzugreifen. In diesem Fall erhält der Client drei Anmeldeaufforderungen: zunächst für realm1, dann für realm2 und schließlich erneut für realm1.

Standardmäßig wird das Subjekt, das für die Anmeldung an einem Realm verwendet wird, vom Code auf der Clientseite nicht zwischengespeichert. Wenn in diesem Szenario der Client das Subjekt auf Realmbasis zwischenspeichern soll, setzen Sie die Eigenschaft com.ibm.CSI.isRealmSubjectLookupEnabled in der Datei sas.client.props auf true. Wenn die Eigenschaft com.ibm.CSI.isRealmSubjectLookupEnabled festgelegt ist, wird das Subjekt auf der Basis des Realmnamens vom Clientcode zwischengespeichert. Beim nächsten Mal, wenn sich der Java-Client für diesen Realm authentifizieren muss, wird das Subjekt aus dem Cache abgerufen, und der Client wird nicht zur Authentifizierung aufgefordert. Wenn die Eigenschaft com.ibm.CSI.isRealmSubjectLookupEnabled festgelegt ist, wird außerdem dasselbe Subjekt, das beim ersten Mal protokolliert wurde, für nachfolgende Anmeldungen verwendet. Wenn die Subjektinformationen geändert werden müssen, sollte diese Eigenschaft nicht festgelegt werden.

Wenn der Client eine programmgesteuerte Anmeldung ausführt, kann er den Realm zusammen mit der Benutzer-ID und dem Kennwort, die für die Authentifizierung benötigt werden, übergeben. Wenn die Eigenschaft com.ibm.CORBA.validateBasicAuth auf in der Datei sas.client.props auf true (Standardwert) gesetzt ist, wird in diesem Fall die Registry für die Anmeldung verwendet, die mit dem Realmnamen übereinstimmt. Der Realm muss in dem Prozess, in dem die Authentifizierung stattfindet, unterstützt werden.

Bei Verwendung der WSLogin-JAAS-Konfigurationen muss auch die Option use_realm_callback in der Datei wsjaas_client.config im Verzeichnis $WAS_HOME/profiles/$ProfileName/properties für den Realmnamen, der an den Callback-Handler übergeben werden soll, festgelegt werden. Wenn ein für den Namensserver ein anderer Provider-URL angegeben werden soll, legen Sie die Option use_appcontext_callback fest und übergeben Sie die Provider-URL-Eigenschaften in einer HashMap an WSLogin.

Wenn der Realmname nicht bekannt ist, verwenden Sie <default> als Realmnamen. Die Authentifizierung wird gegenüber dem Anwendungsrealm ausgeführt. Wenn der Naming-Read-Operation nicht das Sondersubjekt Everyone zugeordnet ist, müssen Sie den Realm angeben, der von den Verwaltungsanwendungen verwendet wird (die in der Konfiguration der globalen Sicherheit verwendete Registry) sowie die geeigneten Benutzer- und Kennwortinformationen in dieser Registry, damit die Suchoperation erfolgreich ist.

Wenn die Suchoperation erfolgreich war, führen Sie eine weitere programmgesteuerte Anmeldung aus, indem Sie den Anwendungsrealm (oder <default>) sowie die Benutzer- und Kennwortinformationen für den passenden Benutzer für die von der Anwendung verwendete Registry angeben. Dies ist ähnlich wie bei Verwendung der Anmeldequelle prompt. Sie müssen sich zweimal authentifizieren: einmal für die von der Konfiguration der globalen Sicherheit verwendete Registry (für die Namenssuchoperation) und dann erneut für die von der Anwendung verwendete Registry, um auf die EJB zuzugreifen.

Wenn die Eigenschaft com.ibm.CORBA.validateBasicAuth in der Datei $WAS_HOME/profiles/$ProfileName/properties/sas.client.props auf false gesetzt ist, kann die programmgesteuerte Anmeldung <default> als Realmnamen für die Such- und für die EJB-Operationen verwenden. Die tatsächliche Authentifizierung findet nur dann statt, wenn auf der Serverseite auf die Ressource zugegriffen wird. In diesem Fall wird der Realm auf der Basis der Ressource, auf die zugegriffen wird, ermittelt.

Die neue Unterstützung von Sicherheitsdomänen, die seit WebSphere Application Version 7.0 bereitgestellt wird, bewirkt keine Änderung am aktuellen Programmiermodell für die Anwendungssicherheit. Sie bietet allerdings, wie nachfolgend aufgeführt, eine höhere Flexibilität und eine umfassendere Funktionalität:

  • Benutzeranwendungen können das Benutzerregistry-Objekt weiterhin über die Namenssuche nach “UserRegistry” finden. Für das von Verwaltungsanwendungen verwendete Registry-Objekt kann eine Namenssuche nach “AdminUserRegistry” ausgeführt werden.
  • Die Verwendung der JAAS-Anmeldekonfiguration durch die Anwendung wird durch die Konfiguration mehrerer Domänen nicht geändert. Wenn eine Anwendung jedoch die auf Domänenebene angegebene JAAS-Konfiguration verwenden muss, müssen der Administrator und der Implementierer der Anwendung sicherstellen, dass diese Domäne mit den für die Anwendung erforderlichen JAAS-Konfigurationen konfiguriert ist.
  • Wenn eine Anwendung mit anderen Anwendungen über unterschiedliche Realms kommunizieren muss, muss für eingehende und für abgehende Kommunikationen eine Vertrauensbeziehung aufgebaut werden, wenn LTPA-Token verwendet werden. Weitere Informationen finden Sie im Artikel Realmübergreifende Kommunikation.
  • Wenn die programmgesteuerte Anmeldung in den Anwendungen verwendet wird und Sie sich an dem von der Anwendung verwendeten Realm anmelden möchten, verwenden Sie <default> als Realmnamen oder geben Sie den von der Anwendung verwendeten Realmnamen an. Wenn Sie sich am globalen Realm anmelden müssen, geben Sie den Namen des globalen Realms an. Wenn Sie einen anderen Realm angeben, wird nur ein Subjekt für Basisauthentifizierung erstellt. Wenn die Anforderung tatsächlich an den Server gesendet wird, auf dem sich der betreffende Realm befindet, wird der Benutzer authentifiziert, wenn sich der Realm auf dem Server befindet. Wenn sich der Realm nicht auf dem Server befindet, scheitert die Anmeldung.

Anwendungsimplementierung in Konfigurationen mit mehreren Domänen

Wenn eine Anwendung in einer Konfiguration mit mehreren Domänen implementiert wird, sollten alle Module in der Anwendung in den Servern oder Clustern implementiert werden, die zu derselben Sicherheitsdomäne gehören. Abhängig von den in diesen Sicherheitsdomänen konfigurierten Sicherheitsattributen, kann andernfalls ein inkonsistentes Verhalten die Folge sein. Wenn die Domänen beispielsweise unterschiedliche Benutzerregistrys enthalten, können unterschiedliche Benutzer- und Gruppeninformationen vorhanden sein, sodass es beim Zugriff auf diese Module zu einem inkonsistenten Verhalten kommt. Ein anderes Beispiel ist die Verwendung unterschiedlicher JAAS-Daten in den Sicherheitsdomänen. Die JAAS-Konfigurationen sind nicht von allen Modulen in der Anwendung aus zugänglich. Der Code der Sicherheitslaufzeit und die Befehlstasks gehen davon aus, dass der Anwendung eine Domäne zugeordnet wird, wenn Attribute wie Benutzerregistry, JAAS-Anmeldekonfigurationen, J2C-Authentifizierungsdaten und Berechtigung verwendet werden.

Normalerweise scheitert die Anwendungsimplementierung, wenn eine Anwendung in mehreren Domänen implementiert wird. Da dies in früheren Releases von WebSphere Application Server, in denen nur wenige Attribute auf Serverebene unterstützt wurden, aber möglich war, prüft das Implementierungstool zunächst, ob Attribute vorhanden sind, die in der Domäne konfiguriert sind. Wenn die Attribute in der Domäne mit den Attributen übereinstimmen, die in früheren Releases unterstützt wurden, fordert die Administrationskonsole eine Bestätigung an, um sich zu vergewissern, dass die Anwendungsmodule tatsächlich in mehreren Sicherheitsdomänen implementiert werden sollen. Sofern es nicht unerlässlich ist, die Anwendung in unterschiedlichen Domänen zu implementieren, sollten Sie die Implementierung stoppen und Server und Cluster in derselben Sicherheitsdomäne auswählen.

Realmübergreifende Kommunikation

Wenn Anwendungen über das Protokoll RMI/IIOP kommunizieren und LTPA als Authentifizierungsverfahren verwendet wird, wird das LTPA-Token zwischen den beteiligten Servern übergeben. Das LTPA-Token enthält die für den Realm qualifizierte eindeutige ID, "uniqueId" (auch unter der Bezeichnung accessId, d. h. Zugriffs-ID, bekannt), des Benutzers, der sich an der Front-End-Anwendung anmeldet. Wenn dieses Token vom Downstream-Server empfangen wird, versucht der Server das Token zu entschlüsseln. Wenn die LTPA-Schlüssel von zwei Servern gemeinsam genutzt werden, ist die Entschlüsselung erfolgreich und die accessId des Benutzers wird aus dem Token abgerufen. Der Realm in der accessId wird mit dem aktuellen, von der Anwendung verwendeten Realm abgeglichen. Wenn die Realms übereinstimmen, ist die Validierung des LTPA-Tokens erfolgreich und die Berechtigung wird fortgesetzt. Wenn die Realms nicht übereinstimmen, scheitert die Validierung, weil der Benutzer aus dem fremden Realm im aktuellen Realm der Anwendung nicht validiert werden kann. Wenn bei Verwendung des Protokolls RMI/IIOP und des LTPA-Authentifizierungsverfahrens keine Kommunikation zwischen Anwendungen vorgesehen ist, müssen Sie keine weiteren Schritte unternehmen.

Wenn aber RMI/IIOP und LTPA-Token verwendet werden und eine realmübergreifende Kommunikation stattfinden soll, müssen Sie zunächst sowohl für eingehende als auch für abgehende Kommunikation eine Vertrauensbeziehung zwischen den beteiligten Realms aufbauen.

Für den Realm des Servers, der die Anforderung stellt, müssen die Realms festgelegt sein, denen er vertrauen und an die er das Token folglich senden kann. Diese Realms werden als "outboundTrustedRealms" (anerkannter abgehender Realm) bezeichnet. Der Realm des Servers, der die Anforderung empfängt, muss den Realms vertrauen, von denen er LTPA-Token empfangen kann. Diese Realms werden als "inboundTrustedRealms" (anerkannter eingehender Realm) bezeichnet.

Anerkannte abgehende Realms können mit dem Befehl "addTrustedRealms" mit der Einstellung outbound für die Option "communicationType" definiert werden. Sie können auch mit der Administrationskonsole durch Anklicken der Option Anerkannte Authentifizierungsrealms - abgehend in der Anzeige Abgehende CSIv2-Kommunikation definiert werden.

Anerkannte eingehende Realms können mit dem Befehl "addTrustedRealms" mit der Einstellung inbound für die Option "communicationType" definiert werden. Sie können außerdem mit der Administrationskonsole definiert werden.

Die Abbildung unten zeigt die Kommunikation zwischen Anwendungen, die bei Verwendung von RMI/IIOP unterschiedliche Benutzerrealms (Registrys) verwenden. In diesem Beispiel ist die Anwendung app1 (z. B. ein servlet) für die Verwendung der Benutzerregistry realm1 konfiguriert. Die Anwendung app2 (z. B. eine EJB) ist für die Verwendung der Benutzerregistry realm2 konfiguriert. Der Benutzer (user1) meldet sich zunächst bei dem Servlet in app1 an und versucht dann, auf eine EJB in app2 zuzugreifen. Folgendes muss festgelegt sein:

  • In Domain1, sollte realm1 realm2 für die abgehende Kommunikation vertrauen.
  • In Domain2 sollte realm2 realm1 für die eingehende Kommunikation vertrauen.
  • Die accessId für user1 sollte in der Berechtigungstabelle für app2 konfiguriert sein.

Wenn das LTPA-Token, das die accessId von user1 enthält, von app2 empfangen wird, wird das Token entschlüsselt. Beide Server nutzen dieselben LTPA-Schlüssel gemeinsam. Mit dem LTPA-Token wird sichergestellt, dass der fremde Realm ein vertrauenswürdiger Realm ist. Anschließend wird die Berechtigung mit der accessId von user1 ausgeführt. Wenn die Weitergabe von Sicherheitsattributen nicht inaktiviert ist, werden die Gruppeninformationen von user1 auch an app2 weitergegeben. Die Gruppen können zur Berechtigungsprüfung verwendet werden, wenn die Berechtigungstabelle die Gruppeninformationen enthält. Sie können den Rollen ein Sondersubjekt mit dem Namen AllAuthenticatedInTrustedRealms zuordnen, anstatt der Berechtigungstabelle einzelne Benutzer und Gruppen hinzuzufügen.

Wenn die Anwendungen im vorherigen Beispiel in unterschiedlichen Zellen implementiert sind, gehen Sie wie folgt vor:

  • Verwenden Sie dieselben gemeinsamen LTPA-Schlüssel in den Zellen.
  • Aktualisieren Sie mithilfe des Dienstprogramms wsadmin die Berechtigungstabelle für app2 mit den accessIds der fremden Benutzer und Gruppen. Die Administrationskonsole hat keinen Zugriff auf Realms, die sich außerhalb des Geltungsbereichs der Zelle befinden.
Abbildung 4. Realmübergreifende Kommunikation in einer Umgebung mit mehreren RealmsWenn die Anwendungen im vorherigen Beispiel in unterschiedlichen Zellen implementiert sind, müssen Sie Folgendes tun: LTPA-Schlüssel für die Zellen gemeinsam nutzen und die Berechtigungstabelle für app2 mit den Zugriffs-IDs fremder Benutzer und Gruppen über das Dienstprogramm wsadmin aktualisieren. Die Administrationskonsole hat keinen Zugriff auf die Realms außerhalb des Geltungsbereichs der Zelle.

Wenn zwischen den Realms eine Vertrauensbeziehung hergestellt wurde, prüft der Server nach dem Empfang des LTPA-Tokens und der Entschlüsselung des Tokens, ob der fremde Realm in seiner Liste mit eingehenden anerkannten Realms enthalten ist. Wenn der Realm anerkannt wird, ist die Authentifizierung erfolgreich. Da es sich jedoch um einen fremden Realm handelt, wird die Benutzerregistry nicht nach Informationen zum Benutzer durchsucht. Stattdessen werden die im LTPA-Token enthaltenen Informationen verwendet, um den Benutzer zu berechtigen.

Die einzige Information, die das LTPA-Token enthält, ist die eindeutige ID des Benutzers. Diese eindeutige ID des Benutzers sollte in der Berechtigungstabelle für diese Anwendung enthalten sein. Ist sie darin enthalten, ist die Berechtigung erfolgreich. Wenn die Weitergabe von Attributen aktiviert ist, werden jedoch zusätzliche Berechtigungsattribute (Gruppen, zu denen dieser Benutzer gehört) für den Benutzer von dem Ursprungsserver an den Empfangsserver gesendet. Anhand dieser zusätzlichen Attribute wird die Zugriffsentscheidung gefällt. Wenn Gruppeninformationen in den Weitergabetoken vorhanden sind, werden sie bei der Berechtigungsentscheidung berücksichtigt.

Wie bereits erwähnt, sollten die Informationen zu den Benutzern oder Gruppen aus den anerkannten Realms in der Berechtigungstabelle der empfangenden Anwendung enthalten sein. Insbesondere sollte die Zugriffs-ID (accessId) der Benutzer und Gruppen in der Bindungsdatei der Anwendung enthalten sein. Dies muss der Fall sein, wenn die Anwendung implementiert wird. Wenn eine Anwendung in einer Domäne implementiert wird, können Sie die Zugriffs-IDs (accessIds) der Benutzer und Gruppen aus jedem anerkannten Realm mithilfe der Administrationskonsole zu der Berechtigungstabelle hinzufügen.

Sie haben außerdem die Möglichkeit, den Rollen ein Sondersubjekt mit dem Namen AllAuthenticatedInTrustedRealms zuzuordnen, anstatt einzelne Benutzer und Gruppen hinzuzufügen. Dies ist ähnlich wie das Sondersubjekt AllAuthenticated, das derzeit unterstützt wird. Der Unterschied liegt darin, dass sich das Sondersubjekt AllAuthenticated auf Benutzer in demselben Realm wie die Anwendung bezieht, während das Sondersubjekt AllAuthenticatedInTrustedRealms für alle Benutzer in den anerkannten Realms und in dem Realm der Anwendung gilt.

Sie können die accessId mit dem Installationsscript "$AdminApp" zuordnen. Weil die accessId ein eindeutiges Format verwendet, sollten Sie die Befehlstask listRegistryUsers mit der Einstellung true für displayAccessIds verwenden. Wenn in diesem Feld ein ungültiger Name oder ein ungültiges Format eingegeben wird, scheitert die Berechtigung.

Die Benutzer- und Gruppeninformationen aus den anerkannten Realms werden von dem Deployment Manager abgerufen, da dieser Zugriff auf alle Benutzerregistry-Konfigurationen in allen Domänen hat. In bestimmten Fällen ist es jedoch nicht möglich, die Benutzer- und Gruppeninformationen abzurufen.

Wenn z. B. ein auf einem externen Knoten befindlicher Server localOS als Registry für seine Domäne verwendet, kann der Deployment Manager die Benutzer- und Gruppeninformationen nicht abrufen, wenn er nicht in derselben Betriebssysteminstallation ausgeführt wird. Diese Informationen sollten vom externen Betriebssystem abgerufen werden. Dies kann durch direkten Aufruf der Registry in dem dieser Domäne zugeordneten Server erfolgen. Dazu müssen die der Domäne zugeordneten Server gestartet sein. Außerdem muss die Eigenschaft com.ibm.websphere.allowRegistryLookupOnProcess in den angepassten allgemeinen Sicherheitseigenschaften auf true gesetzt werden. Wenn diese Eigenschaft festgelegt ist, durchsucht der Deployment Manager einen der Server, die der Sicherheitsdomäne zugeordnet sind, und ruft die Benutzer- und Gruppeninformationen direkt aus diesem Server ab. Dazu kann eine MBean in einem der Server aufgerufen werden.

Wenn die MBean in einem der Server, die die Domäne verwenden, nicht aufgerufen werden kann, ruft die Administrationskonsole eine Anzeige auf, in der Sie die Benutzer- und accessId-Informationen für jeden Benutzer und für jede Gruppe manuell eingeben können. In diesem Feld muss unbedingt das richtige accessId-Format eingegeben werden. Das accessId-Format für den Benutzer lautet wie folgt: user:realmName/userUniqueId. Der "realmName" ist der Name des Realms, in dem sich der Benutzer befindet, und die "userUniqueId" ist die eindeutige ID (uniqueId), die den Benutzer darstellt, abhängig von der verwendeten Registry.

Beispielsweise ist die uniqueUserId für LDAP für die Windows-Registry localOS der DN (Distinguished Name, definierter Name) und für den Benutzer die SID. Für UNIX-Plattformen ist es die UID. Für angepasste Registrys ist dies abhängig von der Implementierung.

Das accessId-Format für Gruppen lautet ähnlich: "group:realmName/groupUniqueId". Wie zuvor angegeben, müssen Sie die Befehle "listRegistryUsers" und "listRegistryGroups" mit der Einstellung true für die Option "displayAccessIds" ausführen, um das richtige Format für die gewünschte Domäne oder den gewünschten Realm zu erhalten.

Nachdem Benutzer und Gruppen aus den anerkannten Realms oder das Sondersubjekt "AllAuthenticatedInTrustedRealms" zur Berechtigungstabelle der Anwendung hinzugefügt wurde, kann die Anwendung Anforderungen von anderen Anwendungen, die einen ihrer anerkannten Realms verwenden, akzeptieren. Die Validierung des LTPA-Tokens auf dem empfangenden Server prüft zuerst, ob der Realm anerkannt (vertrauenswürdig) ist. Die Berechtigungsengine prüft anschließend, ob der externe Benutzer und/oder die Gruppen oder das Sondersubjekt AllAuthenticatedInTrustedRealms Zugriff auf die Rollen erhalten, die für den Zugriff auf die Ressource erforderlich sind. Ist dies der Fall, wird der Zugriff gewährt.

Die realmübergreifende Kommunikation ist nur gültig bei Verwendung der WebSphere-Berechtigung. Wenn Sie andere Berechtigungsengine verwenden, einschließlich SAF for z/OS, können Sie eine realmübergreifende Berechtigung erreichen, wenn Sie angepasste Anmeldemodule implementieren, die externe Benutzer den Benutzern in ihrem eigenen Repository zuordnen.

Knoten mit Sicherheitsdomänen einbinden

Wenn eine Sicherheitsdomäne in der Basisversion erstellt und in eine Zelle eingebunden wird, dann wird die in der Basisversion konfigurierte Sicherheitsdomäne auch für den betreffenden Server in der Zelle konfiguriert. Der Server kann vor und nach der Einbindung dieselbe Domänensicherheitskonfiguration verwenden. Wenn ein Basisserver in eine Zelle eingebunden werden soll, sollte die der Sicherheitsdomäne zugeordnete Ressource der Geltungsbereich des Servers und nicht der Geltungsbereich der Zelle sein.

Wenn der Basisserver sich bei einem Prozess des Verwaltungsagenten registrieren muss, verwenden Sie den Geltungsbereich der Zelle als Ressource, wenn alle Server im Basisprofil diese Sicherheitsdomäne verwenden sollen.

Wenn eine Sicherheitsdomäne in der Basisversion bei der Einbindung bereits auf Zellenebene existiert, kann der Befehl addNode nicht erfolgreich ausgeführt werden. Sie können die Option –excludesecuritydomains verwenden, um die Sicherheitsdomäne von der Einbindung auszuschließen.

Wenn der eingebundene Knoten aus einer Zelle entfernt wird, sollten die Ressourcen in dem betreffenden Knoten aus den Sicherheitsdomänen entfernt werden. Wenn den Sicherheitsdomänen Cluster zugeordnet sind, die mehrere Knoten umfassen, werden die Knoten nicht entfernt. Ressourcen können immer aus den Sicherheitsdomänen oder aus anderen Domänen entfernt werden, die nicht von Scripting-Befehlen oder von der Administrationskonsole verwendet werden.

Sicherheitsdomänen in einer heterogenen Umgebung

Nachdem alle Knoten auf die neueste Version migriert wurden, sollten Sicherheitsdomänen erstellt werden. Dies gilt insbesondere dann, wenn es erforderlich ist, einer Zelle eine Domäne zuzuordnen. Wenn Sie aber Sicherheitsdomänen in einer heterogenen Umgebung erstellen möchten, beachten Sie folgende Hinweise:

  • Wenn eine zellenweite Domäne in einer Installation mit heterogenen Versionen erstellt wird, dann wird automatisch eine Domäne mit dem Namen PassThroughToGlobalSecurity erstellt. Alle heterogenen Cluster werden beim Erstellen der zellenweiten Domäne dieser automatisch erstellten Domäne zugeordnet. Diese Domäne mit dem Namen PassThroughToGlobalSecurity ist eine spezielle Domäne, in dem sinn, dass ihr keine Attribute hinzugefügt sondern nur Ressourcen zugeordnet werden können.

    Alle Ressourcen, die der Domäne PassThroughToGlobalSecurity zugeordnet werden, verwenden die Konfigurationsdaten der globalen Sicherheit. Wenn ein Knoten in einer Installation mit heterogenen Versionen auf die neueste Version migriert wird, werden die Server und Cluster in diesen Knoten dieser Domäne hinzugefügt. Die Anwendungen in allen Servern und Clustern in diesen Knoten verwenden nicht die zellenweite Domäne, sondern sie verwenden vor und nach der Migration die Konfiguration der globalen Sicherheit.

    Wenn einer dieser Server die zellenweite Domäne verwenden muss, müssen die betreffenden Ressourcen aus der Domäne PassThroughToGlobalSecurity entfernt werden. Neue Server und Cluster, die in dem migrierten Knoten erstellt werden, verwenden die zellenweite Domäne anstelle der Domäne PassThroughToGlobalSecurity. Das Ergebnis ist eine Kombination von Servern und Clustern, von denen einige die Konfiguration der globalen Sicherheit verwenden und andere die zellenweite Domäne.

  • Nachdem eine zellenweite Domäne erstellt wurde, wird das Hinzufügen von Cluster-Membern der alten Version zu einem Cluster mit WebSphere Application Server Version 9.0 eingeschränkt, weil es dadurch zu einem heterogenen Cluster würde. Diese Einschränkung gilt auch für den Fall, dass einem Cluster mit WebSphere Application Server Version 9.0 eine Domäne zugeordnet und ihm anschließend ein Cluster-Member mit einer früheren Version hinzugefügt wird. Diese Einschränkung ist erforderlich, um zu vermeiden, dass eine Sicherheitsdomäne einem heterogenen Cluster zugeordnet wird.
  • Falls möglich, sollten Sie eine zellenweite Domäne erstellen, nachdem alle Knoten migriert wurden. In diesem Fall gilt die zellenweite Domäne für die gesamte Zelle und nicht nur für Teile der Zelle. Folglich ist es nicht mehr erforderlich, die Domäne PassThroughToGlobalSecurity zu erstellen, und das Szenario mit heterogenem Cluster mit Sicherheitsdomänen wird überflüssig.

Sicherheitsdomänen ändern

Verwenden sie die Administrationskonsole oder Scripting-Befehle, um Sicherheitsdomänen zu ändern. Eine vollständige Liste der Verwaltungstasks und Scripting-Befehle finden Sie am Ende dieses Artikels unter den zugehörigen Tasks.

Nachdem eine Sicherheitsdomäne erstellt und einer Menge von Geltungsbereichen zugeordnet wurde, müssen die Server, die dieser neuen Domäne zugeordnet sind, erneut gestartet werden. Nach dem Neustart verwenden die Anwendungen in den Geltungsbereichen, die der neuen Domäne zugeordnet sind, die in der Domäne definierten Sicherheitsattribute.

Änderungen an den Domänenattributen erfordern den Neustart aller ihnen zugeordneten Geltungsbereiche. Werden neue Geltungsbereiche hinzugefügt, müssen diese ebenfalls erneut gestartet werden. Änderungen an der Domänenkonfiguration, die die Sicherheitsattribute oder die Geltungsbereiche betreffen, haben Auswirkungen auf die Anwendungen, die die Domänenkonfiguration verwenden.

Bevor Sie eine vorhandene Domäne ändern, bedenken Sie folgende mögliche Auswirkungen. Wenn z. B. eine in einer Domäne konfigurierte Benutzerregistry entfernt wird und die Server erneut gestartet werden, wird die Benutzerregistry der zellenweiten Domäne (falls definiert) oder die Konfiguration der globalen Sicherheit verwendet. Dies kann Auswirkungen auf die Authentifizierung und die Berechtigung haben. Die Benutzer und Gruppen, die einer Anwendung zugeordnet sind, sind in der neuen Registry möglicherweise nicht mehr gültig. Ein weiteres Beispiel, das in diesem Zusammenhang betrachtet werden sollte, ist der Fall, in dem JAAS-Konfigurationen aus einer Domäne entfernt werden. Anwendungen, die die JAAS-Konfigurationen benötigen, können diese nicht mehr verwenden. Jedesmal, wenn eine Sicherheitskonfiguration geändert wird, kann dies Auswirkungen auf Ihre Anwendungen haben. Daher sollten alle Änderungen an der Sicherheitskonfiguration mit größtmöglicher Sorgfalt vorgenommen werden.

[z/OS]

Für heterogene Umgebungen erforderliche Tolerierungs-PTFs

Tolerierungs-PTFs sind für Umgebungen mit heterogenen Releases erforderlich, in denen IIOP-Clients mit früheren Versionen von WebSphere Application Server for z/OS mit mit einem Anwendungsserver von WebSphere Application Server Version 9.0 for z/OS zusammenarbeiten, auf dem mehrere Sicherheitsdomänen definiert sind.

Der IIOP-Client mit einer Version vor Version 9.0 benötigt eine Aktualisierung seines Verarbeitungscodes für IIOP-Lokalisierungen, damit er in den Sicherheitsdomänen eines Anwendungsservers der Version 9.0 IIOP-Lokalisierungen ausführen kann.

Die Tolerierungs-PTFs für alle betroffenen Service-Releases sind weiter unten in diesem Abschnitt aufgelistet. Ein IIOP-Client mit einer Version vor Version 9.0 muss sich auf dem vorgegebenen oder einem höheren Service-Level befinden, damit er mit einem Anwendungsserver der Version 9.0 zusammenarbeiten kann, der mehrere Sicherheitsdomänen enthält.

WebSphere Application Server for z/OS 5.1:  W510246
WebSphere Application Server for z/OS v6.0: 602.29
WebSphere Application Server for z/OS v6.1: 610.17

Diese Anforderung gilt nur für IIOP-Clients mit WebSphere for z/OS, die Anforderungen für einen Anwendungsserver mit WebSphere for z/OS aufrufen, für den mehrere Sicherheitsdomänen konfiguriert und aktiviert sind.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_sec_multiple_domains
Dateiname:csec_sec_multiple_domains.html