Globale SicherheitseinstellungenDiese Seite unterstützt Sie beim Konfigurieren der Sicherheit. Wenn Sie die Sicherheit aktivieren, werden die Sicherheitseinstellungen auf globaler Ebene aktiviert. Sie erzielen in WebSphere Application Server eine Leistungssteigerung von 10 - 20 %, wenn die Sicherheit inaktiviert ist.Deshalb sollte Sie die Sicherheit nur bei Bedarf aktivieren.
Klicken Sie, um diese Seite der Administrationskonsole anzuzeigen, auf Sicherheit > Globale Sicherheit.
Wenn Sie die Sicherheitseinrichtung zum ersten Mal konfigurieren, führen Sie die im Abschnitt "Globale Sicherheit konfigurieren" in der Dokumentation beschriebenen Schritte durch, um Fehler zu vermeiden. Wenn die Sicherheitseinrichtung konfiguriert ist, empfiehlt es sich, alle Änderungen in den Anzeigen der Registry bzw. des Authentifizierungsverfahrens zu überprüfen. Klicken Sie auf Anwenden, um die Einstellungen der Benutzer-Registry zu ändern. Es wird versucht, die Server-ID für die konfigurierte Benutzer-Registry zu authentifizieren. Wenn Sie die Einstellungen der Benutzer-Registry nach der Aktivierung der globalen Sicherheitseinrichtung überprüfen, können Sie Fehler vermeiden, wenn Sie den Server zum ersten Mal erneut starten.
Register "Konfiguration"
Diese Markierung wird in der Dokumentation zu WebSphere Application Server allgemein als globales Sicherheits-Flag bezeichnet. Bei der Aktivierung der Sicherheitseinrichtung müssen Sie auch die Konfiguration eines Authentifizierungsverfahrens festlegen und eine gültige Kombination aus Benutzer-ID und Kennwort in der ausgewählten Konfiguration der Benutzer-Registry angeben.
| Datentyp | Boolean |
| Standardwert | Inaktiviert |
Wenn die Java-2-Sicherheit aktiviert ist und eine Anwendung mehr Java-2-Sicherheitsberechtigungen benötigt, als in der Standard-Policy angegeben sind, wird die Anwendung möglicherweise erst richtig ausgeführt, wenn die erforderlichen Berechtigungen in der Datei app.policy oder was.policy der Anwendung erteilt werden. AccessControl-Ausnahmebedingungen werden von Anwendungen generiert, denen nicht alle erforderlichen Berechtigungen erteilt wurden. Wenn Sie mit der Java-2-Sicherheitseinrichtung nicht vertraut sind, lesen Sie im InfoCenter die Abschnitte zur Java-2-Sicherheitseinrichtung und zur dynamischen Policy.
Sollte der Server nach dem Aktivieren der globalen Sicherheit nicht starten, können Sie die Sicherheit inaktivieren. Wechseln Sie in das Verzeichnis $<install_root>\bin und führen Sie den Befehl wsadmin -conntype NONE aus. Geben Sie an der wsadmin>-Eingabeaufforderung den Befehl securityoff und dann exit ein, um zu einer Eingabeaufforderung zurückzukehren. Starten Sie den Server mit inaktivierter Sicherheit erneut, um mit der Administrationskonsole festzustellen, ob Einstellungen ungültig sind.
| Datentyp | Boolean |
| Standardwert | Inaktiviert |
| Bereich | Aktiviert oder inaktiviert |
| Datentyp | Boolean |
| Standardwert | Inaktiviert |
| Bereich | Aktiviert oder inaktiviert |
![[nur 5.0]](v50x.gif)
Wenn Sie in der
Konfigurationsanzeige Sicherheit > Globale Sicherheit die Option
In der Domäne qualifizierte Benutzer-IDs verwenden auswählen, gibt der Aufruf von getCallerPrincipal()
zur Laufzeit durch eine Enterprise-Bean den qualifizierten Namen zurück, dem der Realm-Name zwei Mal vorangestellt ist.
Das zurückgegebene Format ist "Realm/Realm/Benutzer". Sie können den ersten Realm-Namen aus dem zurückgegebenen Wert
entfernen, wenn Sie API-Aufrufe absetzen.
Sie Servlet-API "getUserPrincipal()" funktioniert ordnungsgemäß.
Wenn die Sicherheit von WebSphere Application Server aktiviert ist, kann das Zeitlimit des Sicherheits-Cache Einfluss auf den Durchsatz haben. Das Zeitlimit gibt an, wie oft die sicherheitsbezogenen Caches aktualisiert werden. Sicherheitsinformationen, die sich auf Beans, Rechte und Berechtigungsnachweise beziehen, werden im Cache gespeichert. Wenn das Cache-Zeitlimit abläuft, werden alle im Cache befindlichen Informationen ungültig. Werden die Informationen nach Ablauf des Zeitlimits angefordert, muss die Datenbank durchsucht werden. Manchmal muss zum Abrufen der Informationen eine LDAP-gebundene (Lightweight Directory Access Protocol) oder native Authentifizierung aufgerufen werden. Beide Aufrufe sind relativ leistungsintensiv. Prüfen Sie die Nutzungsmuster der Anwendung und die Sicherheitsanforderungen der Site, um einen für die Anwendung optimalen Kompromiss zu finden.
Wenn Sie in einem 20-minütigen Leistungstest das Cache-Zeitlimit so einstellen, dass keine Zeitlimitüberschreitung auftritt, können Sie eine Leistungsverbesserung von 40 % erzielen.
| Datentyp | Integer |
| Einheiten | Sekunden |
| Standardwert | 600 |
| Bereich | Mehr als 30 Sekunden |
WebSphere bietet Unterstützung für die Verwaltung von Policy-Dateien. Es gibt in diesem Produkt eine Reihe von Policy-Dateien, von denen einige statisch und andere dynamisch sind. Eine dynamische Policy ist eine Schablone mit Berechtigungen für einen bestimmten Ressourcentyp. In der Schablone der dynamischen Policy ist keine Codebasis oder relative Codebasis definiert. Die reale Codebasis wird aus den Konfigurations- und Laufzeitdaten dynamisch erstellt. Die Datei filter.policy enthält eine Liste der Berechtigungen, die Anwendungen gemäß der J2EE-1.3-Spezifikation nicht haben dürfen. Weitere Informationen zu Berechtigungen enthält der Abschnitt "Verwaltung mit Java-2-Sicherheits-Policy".
| Datentyp | Boolean |
| Standardwert | Inaktiviert |
| Bereich | Aktiviert oder inaktiviert |
Ein OMG-Protokoll (Object Management Group) mit dem Namen Common Secure Interoperability Version 2 (CSIv2) unterstützt eine verstärkte Interoperabilität mit Lieferanten und weitere Features. Wenn alle Server in der Sicherheitsdomäne Server der Version 5 sind, geben Sie CSI als Protokoll an. Sollten Server der Version 3.x oder der Version 4.x in der Domäne enthalten sein, geben Sie CSI und SAS an.
| Datentyp | String |
| Standardwert | BOTH |
| Bereich | CSI und SAS, CSI |
WebSphere Application Server Version 5 unterstützt die folgenden Authentifizierungsverfahren: Simple WebSphere Authentication Mechanism (SWAM) und Lightweight Third Party Authentication (LTPA).
| Datentyp | String |
| Standardwert | SWAM (WebSphere Application Server) |
| Bereich | SWAM, LTPA |
Sie können für eine der folgenden Benutzer-Registrys Einstellungen konfigurieren:
| Datentyp | String |
| Standardwert | LocalOS |
| Bereich | LocalOS, LDAP, Benutzerdefiniert |
![[Fixpack 5.0.2 und höher]](v502.gif)
Wenn die Option FIPS verwenden ausgewählt ist, verwendet die LTPA-Implementierung (Lightweight Third Party Authentication) IBMJCEFIPS. IBMJCEFIPS unterstützt die vom Federal Information Processing Standard (FIPS) anerkannten Verschlüsselungsalgorithmen für DES, Triple DES und AES. Im Gegensatz zu den LTPA-Schlüsseln ist das LTPA-Token nicht mit früheren Releases von WebSphere Application Server abwärtskompatibel.
WebSphere Application Server stellt einen von FIPS anerkannten JSSE-Provider (Java Secure Socket Extension) mit dem Namen IBMJSSEFIPS bereit. Eine von FIPS anerkannte JSSE erfordert das Protokoll Transport Layer Security (TLS), weil sie das Protokoll Secure Sockets Layer (SSL) nicht unterstützt. Wenn Sie vor der Angabe eines FIPS-JSSE-Providers und eines TLS-Protokolls die Option FIPS verwenden auswählen, erscheint oben in der Anzeige Globale Sicherheit die folgende Fehlernachricht:
Die Sicherheits-Policy ist für FIPS-konforme Verschlüsselungsalgorithmen konfiguriert. Mindestens eine SSL-Konfiguration verwendet keinen FIPS-konformen JSSE-Provider. In solchen Fällen können keine FIPS-konformen Verschlüsselungsalgorithmen verwendet werden.Sie können diesen Fehler beheben, indem Sie in der Anzeige SSL-Konfigurationsrepertoires mit einer der folgenden Tasks Ihren JSSE-Provider und das Sicherheitsprotokoll konfigurieren: