Sicherheit
Die folgenden Informationen liefern eine Übersicht über die Sicherheit in WebSphere Application Server.
- Authentifizierung
- Steuerung des Zugriffs auf Ressourcen
- Datenintegrität
- Vertraulichkeit
- Datenschutz
- Sichere Interoperabilität
- Database 2 (DB2)
- CICS
Information Management System (IMS)
- MQ Series
- Lotus Domino
- IBM Directory
Jeden SAF-kompatiblen (System Authorization Facility) Sicherheitsserver, einschließlich IBM z/OS Security Server Resource Access Control Facility (RACF)
- Sichere Reverse-Proxy-Server wie WebSEAL
Identifikationsverwaltung:
Für
WebSphere Application Server
Version 7.x und frühere Releases:
Zur Verwendung der SAF-Sicherheitsfunktionen müssen sich
Benutzer mit einer z/OS-basierten Benutzer-ID identifizieren. Mit Principalzuordnungsmodulen können Sie Ihrer plattformbasierten Benutzer-ID
(in diesem Fall einer RACF-Benutzer-ID) eine J2EE-Identität zuordnen.
Aus der LDAP-Benutzer-ID muss eine Principalzuordnung zur
RACF-Benutzer-ID erstellt werden, damit die SAF-EJBROLE-Prüfungen
durchgeführt werden können.
Folglich muss ein Anmeldemodul für die Zuordnung verfügbar sein, um eine z/OS-Benutzer-ID vom konfigurierten Benutzer in der LDAP-Registry abzuleiten.
(Zur Verfolgung dieser Änderungen kann die SMF-Überwachung (mit SAF) verwendet werden.)
Neuerungen für WebSphere Application Server Version 8.0
und höher:
![[z/OS]](../images/ngzos.gif)
- Verwendung des JAAS-Zuordnungsmoduls für die Zuordnung der J2EE-Identität zu einer SAF-Identität.
- Verwendung des Features für die Zuordnung verteilter Identitäten, das eine bestimmte Version von SAF voraussetzt. In WebSphere sollten keine JAAS-Zuordungsmodule konfiguriert werden. In diesem Fall identifizieren sich Benutzer selbst mit ihrer verteilten Benutzer-ID, z. B. der Benutzeridentität in der LDAP-Registry. Die Zuordnung wird vom Administrator der z/OS-Sicherheit mithilfe von RACMAP-SAF-Profilen vorgenommen. Diese Option erweitert die SMF-Prüfung, indem die Protokollierung der verteilten Benutzeridentität und der SAF-Identität im Prüfdatensatz zugelassen wird. Weitere Informationen finden Sie unter "Zuordnung verteilter Identitäten mit SAF".
Auf der Basis von Industriestandards
IBM WebSphere Application Server bietet ein vereinheitlichtes, auf Richtlinien und Berechtigungen basierendes Modell für die Sicherung von Webressourcen, Web-Service-Endpunkten und Enterprise-JavaBeans gemäß den J2EE-Spezifikationen. WebSphere Application Server entspricht der Spezifikation Java EE 6 und hat die Tests auf Kompatibilität mit J2EE bestanden.
- Das Java-2-Sicherheitsmodell bietet eine auf Richtlinien und Berechtigungen basierende, genau unterteilte Zugriffssteuerung für Systemressourcen.
- Zusätzlich zum Sicherheitsprotokoll SAS
(Secure Authentication Services) das Sicherheitsprotokoll CSIv2 (Common Secure Interoperability Version 2). Beide Protokolle werden auch in vorherigen Releases von WebSphere Application Server unterstützt. CSIv2 ist ein wichtiger Bestandteil der
J2EE 1.4-Spezifikation und ist von wesentlicher
Bedeutung für die Interoperabilität zwischen Anwendungsservern verschiedener Hersteller und mit CORBA-Services
des Unternehmens.
Wichtig: SAS wird nur zwischen Servern der Version 6.0.x und Servern früherer Versionen unterstützt, die in eine Zelle der Version 6.1 eingebunden sind.
- Programmiermodell Java Authentication and Authorization Service (JAAS) für Java-Anwendungen, Servlets und Enterprise-Beans.
- J2EE-Connector-Architektur zur Integration von Ressourcenadaptern, die den Zugriff auf unternehmensweite Informationssysteme unterstützt.
Die Standardsicherheitsmodelle und -schnittstellen, die eine Übertragung über sichere Sockets, Nachrichtenverschlüsselung und Datenverschlüsselung unterstützen, sind Java Secure Socket Extension (JSSE) und Java Cryptographic Extension (JCE).
Paradigma der offenen Architektur
Ein Anwendungsserver ist ein integraler Bestandteil der mehrschichtigen Struktur der Enterprise-Datenverarbeitung. IBM WebSphere Application Server übernimmt das Paradigma der Offenen Architektur und bietet viele Ansatzpunkte zum Integrieren von Unternehmenssoftwarekomponenten. Die Integrationspunkte basieren wo immer möglich auf J2EE-Standardspezifikationen.
Der dunkelblau schattierte Hintergrund kennzeichnet die Grenze zwischen WebSphere Application ServerVersion 9.0 und anderen Komponenten von Geschäftsanwendungen.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Das Authentifizierungsverfahren
LTPA ist für die Sicherheit aller Plattformen bestimmt. Downstream-Server können das Sicherheitstoken validieren. Auch die Einrichtung von Trust-Association-Beziehungen mit sicheren Reverse-Proxy-Servern und Single Sign-On (SSO) wird unterstützt (später mehr Informationen dazu). Neben der Kombination von LTPA und LDAP
oder
einer angepassten Benutzerregistry-Schnittstelle unterstützt Version 6.x und höher LTPA mit einer
Benutzerregistry-Schnittstelle vom Typ "LocalOS" (Lokales Betriebssystem). Die neue
Konfiguration ist bei einem Einzelknoten mit mehreren Anwendungsserver besonders nützlich. Sie kann in einer verteilten Umgebung verwendet werden,
wenn die Implementierung der
Benutzerregistry des lokalen Betriebssystems eine zentrale Registry ist, z. B. Windows
Domain Controller, oder auf mehreren Knoten in konsistentem Zustand gehalten werden kann.
WebSphere Application Server unterstützt die J2EE-Connector-Architektur und containergesteuerte Authentifizierung. Das Produkt
stellt ein Standardzuordnungsmodul nach dem Prinzip J2C-Principal/Berechtigungsnachweis (Java 2 Connector) bereit, das jede authentifizierte
Benutzerberechtigung einer Kennwortberechtigung für die angegebene EIS-Sicherheitsdomäne (Enterprise Information Systems) zuordnet.
Das Zuordnungsmodul ist ein spezielles JAAS-Anmeldemodul, das gemäß den Java-2-Connector- und JAAS-Spezifikationen entworfen wurde. Es können auch noch andere Zuordnungsanmeldemodule
als Plug-in verwendet werden.
![[z/OS]](../images/ngzos.gif)
Benutzerregistrys und Zugriffssteuerung
Informationen zu Benutzern und Gruppen sind in einer Benutzerregistry gespeichert. In WebSphere Application Server authentifiziert eine Benutzerregistry einen Benutzer und ruft Informationen zu Benutzern und Gruppen ab, um sicherheitsrelevante Funktionen wie Authentifizierung und Berechtigung auszuführen.
- LocalOS (SAF-basiert)
- LDAP
- Eingebundene Repositorys
Zusätzlich zu den Registrys der Typen "Lokales Betriebssystem" (LocalOS), "LDAP" und "Eingebundene Repository" stellt WebSphere Application Server ein Plug-in für die Unterstützung beliebiger Registrys über das Feature "Angepasste Registry" (auch angepasste Benutzerregistry) bereit.
Wenn die LocalOS-Registry-Implementierung von WebSphere Application Server ausgewählt ist, können Sie die Funktionen des z/OS-Sicherheitsservers, wie z. B. Resource Access Control Facility (RACF), mit Security Access Facility (SAF) direkt in die WebSphere-Umgebung integrieren. Wenn Sie eine andere Registry als die des lokalen Betriebssystems konfigurieren, können Sie die Funktionen von z/OS Security Server mit zwei Optionen verwenden. Sie können ein JAAS-Plug-in-Zuordnungsmodul (gefolgt von einem von WebSphere Application Server for z/OS bereitgestellten JAAS-Anmeldemodul) in den entsprechenden Systemanmeldekonfigurationen verwenden. In WebSphere Application Server Version 8.5 können Sie alternativ das Feature für verteilte Identitätszuordnung verwenden.
Nähere Informationen hierzu finden Sie im Artikel Registry oder Repository auswählen.
WebSphere Application Server-Konfigurationen: Mit WebSphere Application ServerVersion 9.0 for z/OS können Sie vorhandene Anwendungen, die keine z/OS-Anwendungen sind, mit z/OS-spezifischen Funktionen wie System Authorization Facility (SAF) und RACF integrieren. Damit können Sie Registrys für WebSphere Application Server for z/OS und andere Plattformen vereinheitlichen. Beispiel:
Application-Server-Konfiguration | Registry-Typ | Berechtigungsmethode | Vorteil |
---|---|---|---|
WebSphere Application Server | LDAP | WebSphere-Bindungen und externe Sicherheitsprovider wie Tivoli Access Manager (TAM) | Gemeinsam genutzte Registrys (auf einer heterogenen Plattform) |
WebSphere Application Server for z/OS | RACF | WebSphere-Bindungen und RACF EJBROLEs | Zentraler Zugriff und Überwachungsmöglichkeit (auch für Server der Version 4.0) |
Heterogene Umgebung von WebSphere Application Server | LDAP oder Angepasst | WebSphere-Bindungen, externe Sicherheitsprovider und RACF EJBROLEs | Gemeinsam genutzte Registrys, zentraler Zugriff und Überwachungsmöglichkeit |
- Konfiguration einer Netzregistry in WebSphere Application Server
- Konfiguration einer Netzregistry in
WebSphere Application Server for z/OS:
- Netzregistry von WebSphere Application Server mit
z/OS-Sicherheitserweiterungen
Authentifizierungsverfahren
- LTPA (Lightweight Third Party Authentication)
LTPA generiert ein Sicherheitstoken für authentifizierte Benutzer, das in nachfolgenden Aufrufen, die an diesen oder andere Server in einer SSO-Domäne (Single Sign-On) abgesetzt werden, für diesen authentifizierten Benutzer verwendet werden kann.
- Kerberos
Die Sicherheitsunterstützung für Kerberos als Authentifizierungsverfahren ist in diesem Release von WebSphere Application Server neu hinzugekommen. Kerberos ist ein ausgereiftes, flexibles, offenes und sehr sicheres Netzauthentifizierungsprotokoll. Kerberos umfasst Funktionen für Authentifizierung, gegenseitige Authentifizierung, Integrität und Vertraulichkeit von Nachrichten sowie Delegierungsfeatures.
- Simple WebSphere Authentication
Mechanism (SWAM)SWAM ist einfach zu konfigurieren und gut geeignet für eine Umgebung mit einem einzelnen Anwendungsserver, erfordert aber für jede Anforderung eine Benutzer-ID und ein Kennwort.Anmerkung: SWAM wurde einem früheren Release von WebSphere Application Server als veraltet gekennzeichnet und wird in einem der künftigen Releases entfernt.
IIOP-Authentifizierungsprotokolle
IIOP-Authentifizierungsprotokolle beziehen sich auf die Verfahren, die für die Authentifizierung von Anforderungen eines Java-Clients bei WebSphere Application Server for z/OS oder zwischen J2EE-Anwendungsservern verwendet werden. Common Secure Interoperability Version 2 (CSIv2) ist in WebSphere Application Server for z/OS Version 6.x oder höher implementiert und wird als das strategische Protokoll betrachtet.
![[z/OS]](../images/ngzos.gif)
Sicherheit für WebSphere Application Server for z/OS Connector
WebSphere Application Server unterstützt die J2EE-Connector-Architektur und containergesteuerte Authentifizierung. Es stellt ein Standardzuordnungsmodul nach dem Prinzip J2C-Principal/Berechtigungsnachweis bereit, das jede authentifizierte Benutzerberechtigung einer Kennwortberechtigung für die angegebene EIS-Sicherheitsdomäne (Enterprise Information Systems) zuordnet. z/OS-spezifische Connector werden ebenfalls unterstützt, wenn das EIS-System sich in derselben Sicherheitsdomäne wie WebSphere Application Server befindet. In diesem Fall sind keine Kennwörter erforderlich, weil die für J2EE-Anforderungen verwendeten authentifizierten Berechtigungen als EIS-Berechtigungen verwendet werden können.
Web Services Security
In WebSphere Application Server können Sie Web-Services auf der Basis der OASIS-Spezifikation (Organization for the Advancement of Structured Information Standards) Web Services Security Version 1.1 sichern. Diese Standards legen fest, wie Nachrichten zu schützen sind, die in einer Web-Service-Umgebung ausgetauscht werden. Die Spezifikation definiert die Kernfunktionen für die Gewährleistung der Nachrichtenintegrität und -vertraulichkeit und stellt Mechanismen für Zuordnung sicherheitsbezogener Bestätigungen zu einer Nachricht bereit.
Trust-Associations
- IBM Tivoli Access Manager for e-business
- WebSEAL
- Caching Proxy
Weitergabe von Sicherheitsattributen
- einer Unternehmensbenutzerregistry, die statische Attribute abfragt,
- einem angepassten Anmeldemodul, das statische und dynamische Attribute abfragen kann.
Interoperabilitätsmodus mit SSO
In WebSphere Application Server lässt dieser Interoperabilitätsmodus SSO-Verbindungen (Single Sign-on) zwischen WebSphere Application Server Version 6.1.x oder höher zu, um die Interaktion mit früheren Versionen des Anwendungsservers zu gewährleisten. Wenn Sie diese Option auswählen, fügt WebSphere Application Server das veraltete LtpaToken in die Antwort ein, damit die Antwort an andere Server gesendet werden kann, die nur diesen Tokentyp verarbeiten können. Diese Option ist nur gültig, wenn die Option für die Weitergabe von Sicherheitsattributen für eingehende Webanforderungen aktiviert ist. Weitere Informationen zu Single Sign-on finden Sie im Artikel SSO für die Minimierung von Webbenutzerauthentifizierungen implementieren.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
Sicherheit für J2EE-Ressourcen durch Web-Container und EJB-Container
Jeder Container bietet zwei Arten von Sicherheit: deklarative und programmgesteuerte Sicherheit. In der deklarativen Sicherheit wird die Sicherheitsstruktur einer Anwendung, einschließlich Datenintegrität und Datenvertraulichkeit, Authentifizierungsvoraussetzungen, Sicherheitsrolle und Zugriffssteuerung, in einem anwendungsfremden Format ausgedrückt. Auf der J2EE-Plattform wird der Deklarationsschutz in erster Linie durch den Implementierungsdeskriptor gewährleistet. WebSphere Application Server erfüllt die J2EE-Sicherheitsrichtlinie. Dazu gehört unter anderem, dass Informationen aus dem Implementierungsdeskriptor abgerufen und von Implementierungsbeauftragten und Administratoren in Form von XML-Deskriptordateien angegeben werden. In der Laufzeit verwendet der Container die in den XML-Deskriptordateien definierte Sicherheitsrichtlinie, um Vorgaben für Daten und die Zugriffssteuerung durchzusetzen. Wenn die deklarative Sicherheit allein nicht genügt, um das Sicherheitsmodell einer Anwendung auszudrücken, kann die programmgesteuerte Sicherheit vom Anwendungscode für Zugriffsentscheidungen verwendet werden. Die API für programmgesteuerte Sicherheit umfasst zwei Methoden der EJB-Schnittstelle "EJBContext" (isCallerInRole, getCallerPrincipal) und drei Methoden der Servletschnittstelle "HttpServletrequest" (isUserInRole, getUserPrincipal, getRemoteUser).
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Java-2-Sicherheit
WebSphere Application Server unterstützt das Java-2-Sicherheitsmodell. Systemcodes wie das Verwaltungssubsystem, der Web-Container und der EJB-Container werden in der Sicherheitsdomäne von WebSphere Application Server ausgeführt und erhalten in der derzeitigen Implementierung die Berechtigung "AllPermission", die ihnen ermöglicht, auf alle Systemressourcen zuzugreifen. Anwendungscode, der in der Sicherheitsdomäne der Anwendung ausgeführt wird und dem standardmäßig die Berechtigungen erteilt werden, die in den J2EE-Spezifikationen deklariert sind, kann nur auf eine eingeschränkte Gruppe von Systemressourcen zugreifen. Die Laufzeitklassen von WebSphere Application Server werden vom Klassenlader von WebSphere Application Server geschützt und bleiben dem Anwendungscode verborgen.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Sicherheit mit Java 2 Platform Enterprise Edition Connector
WebSphere Application Server unterstützt die J2EE-Connector-Architektur und containergesteuerte Authentifizierung. Es stellt ein Standardzuordnungsmodul nach dem Prinzip J2C-Principal/Berechtigungsnachweis bereit, das jede authentifizierte Benutzerberechtigung einer Kennwortberechtigung für die angegebene EIS-Sicherheitsdomäne (Enterprise Information Systems) zuordnet.
z/OS-spezifische Connector werden ebenfalls unterstützt, wenn das EIS-System sich in derselben Sicherheitsdomäne wie WebSphere Application Server befindet. In diesem Fall sind keine Kennwörter erforderlich, weil
die für J2EE-Anforderungen verwendeten authentifizierten Berechtigungen als EIS-Berechtigungen verwendet werden
können.
Weitere Informationen hierzu finden
Sie im Artikel Threadidentität für Verbindungen.
Alle Prozesse des Anwendungsservers verwenden standardmäßig eine gemeinsame Sicherheitskonfiguration, die in einem XML-Dokument für die Sicherheit auf Zellenebene definiert ist. Die Sicherheitskonfiguration legt fest, ob die Sicherheit von WebSphere Application Server aktiviert wird und ob die Java-2-Sicherheit aktiviert wird. Außerdem bestimmt sie die Konfiguration des Authentifizierungsverfahrens, der Benutzerregistry, des Sicherheitsprotokolls, die JAAS-Anmeldekonfiguration und die SSL-Konfiguration (Secure Sockets Layer). Anwendungen können individuelle Sicherheitsbestimmungen haben. Jeder Anwendungsserverprozess kann eine Sicherheitskonfiguration auf Serverebene erstellen, die seine eigenen Sicherheitsanforderungen berücksichtigt, oder einer WebSphere-Sicherheitsdomäne zugeordnet werden. Nicht alle Sicherheitskonfigurationen können auf Anwendungsserverebene geändert werden. Die folgenden Sicherheitskonfigurationen können auf Anwendungsserverebene geändert werden: Anwendungssicherheit aktivieren oder nicht, Java-2-Sicherheit aktivieren oder nicht, Sicherheitsprotokollkonfiguration. WebSphere-Sicherheitsdomänen lassen eine stärkere Kontrolle der Sicherheitskonfiguration zu und können einzelnen Servern zugeordnet werden. Weitere Informationen finden Sie im Artikel "Mehrere Sicherheitsdomänen".
Weitere allgemeine Informationen finden Sie im Artikel Sicherheitsstatus mit Unterstützung
für Thread-IDs.
Die Sicherheitskonfiguration des Verwaltungssubsystems wird immer durch das Sicherheitsdokument auf Zellenebene bestimmt. Die Sicherheitskonfigurationen von Web-Container und EJB-Container werden über ein Dokument für Sicherheit auf Serverebene bestimmt, das Vorrang vor dem Dokument für Sicherheit auf Zellenebene hat.
Die Sicherheitskonfigurationen auf Zellenebene und Anwendungsserverebene werden mit der webbasierten Administrationskonsole oder mit der entsprechenden Scripting-Anwendung verwaltet.
![[z/OS]](../images/ngzos.gif)
Websicherheit
- HTTP-Basisauthentifizierung
- HTTPS-Clientauthentifizierung
- formularbasierte Anmeldung
- SPNEGO-Token (Simple and Protected GSS-API Negotiation)
In
WebSphere Application Server unterstützt die Benutzerregistry des lokalen Betriebssystems
die Zuordnungsfunktion nicht.
Wenn als Authentifizierungsverfahren LTPA
konfiguriert und SSO aktiviert ist,
erhält ein authentifizierter Client ein Sicherheitsscookie, das den
Benutzer in der angegebenen Sicherheitsdomäne identifiziert.
Durch die empfohlene Verwendung von Secure Sockets Layer (SSL) können Sie verhindern, dass das Sicherheitsscookie oder die Basisauthentifizierungsdaten abgefangen und wiedergegeben werden. Wenn eine Trust-Association konfiguriert ist, kann WebSphere Application Server die Identität eines authentifizierten Benutzers auf Basis der Vertrauensbeziehung mit dem sicheren Reverse-Proxy-Server einem Sicherheitsberechtigungsnachweis zuordnen.
- Der Collaborator für die Websicherheit setzt die rollenbasierte Zugriffssteuerung über eine Zugriffsmanagerimplementierung um. Ein Access Manager stützt sich beim Gewähren von Berechtigungen auf die Sicherheitsrichtlinie aus dem Implementierungsdeskriptor. Ein authentifizierter Benutzer-Principal darf auf das angeforderte Servlet oder die angeforderte JSP-Datei zugreifen, wenn er zu einer der erforderlichen Sicherheitsrollen gehört. Servlets und JSP-Dateien können die HttpServletRequest-Methoden isUserInRole, getUserPrincipal und getRemoteUser verwenden. Die Administrationskonsole verwendet beispielsweise die Methode isUserInRole, um festzustellen, welche Verwaltungsfunktionen einem Benutzer-Principal bereitzustellen sind.
- Der Collaborator für die EJB-Sicherheit setzt die rollenbasierte Zugriffssteuerung über eine Zugriffsmanagerimplementierung um. Ein Access Manager stützt sich beim Gewähren von Berechtigungen auf die Sicherheitsrichtlinie aus dem Implementierungsdeskriptor. Ein authentifizierter Benutzer-Principal darf auf die angeforderte EJB-Methode zugreifen, wenn er zu einer der erforderlichen Rollen gehört. EJB-Code darf die EJBContext-Methoden isCallerInRole und getCallerPrincipal verwenden. Der EJB-Code kann auch das JAAS-Programmiermodell und die Methoden WSSubject doAs und doAsPrivileged verwenden, um eine JAAS-Anmeldung durchzuführen. Der Code im Block der Methoden doAs und doAsPrivileged PrivilegedAction wird unter der Identität des Subjekts ausgeführt. Andernfalls wird die EJB-Methode je nach RunAs-Konfiguration unter der RunAs-Identität oder der Identität des aufrufenden Prozesses ausgeführt.
EJB-Sicherheit
Wenn die Sicherheit aktiviert ist, aktiviert der EJB-Container die Zugriffssteuerung für den Aufruf von EJB-Methoden. Die Authentifizierung findet unabhängig davon statt, ob für die jeweilige EJB-Methode ein Methodenrecht definiert ist.
Ein Java-Anwendungsclient kann die Authentifizierungsdaten auf verschiedene Arten bereitstellen. Mit der Datei sas.client.props kann ein Java-Client angeben, ob für die Authentifizierung eine Benutzer-ID und ein Kennwort oder aber ein SSL-Clientzertifikat verwendet werden soll. Das Clientzertifikat ist je nach Definition in der Datei sas.client.props in der Schlüsseldatei oder auf der Hardwareverschlüsselungskarte gespeichert. Die Benutzer-ID und das Kennwort können optional in der Datei sas.client.props definiert werden.
Zur Laufzeit kann der Java-Client entweder eine programmgesteuerte oder eine sogenannte Lazy-Authentifizierung durchführen.
Bei einer Lazy-Authentifizierung versucht die Sicherheitslaufzeit, die erforderlichen Authentifizierungsdaten abzurufen, wenn der Java-Client zum ersten Mal auf eine geschützte Enterprise-Bean zugreift. Je nach Konfigurationseinstellung in der Datei sas.client.props ruft die Sicherheitslaufzeit die Authentifizierungsdaten aus dieser Datei ab oder sie fordert die Daten vom Benutzer an. Alternativ kann ein Java-Client auch programmgesteuerte Anmeldung verwenden. WebSphere Application Server unterstützt das JAAS-Programmiermodell. Die JAAS-Anmeldung (Anmeldekontext) ist die empfohlene Art der Anmeldung über das Programm. Die Helper-Funktion "The login_helper request_login" ist in Version 6.x und Version 9.0 veraltet. Für die APT "login_helper" programmierte Java-Clients können in dieser Version ausgeführt werden.
Der Collaborator für die EJB-Sicherheit setzt die rollenbasierte Zugriffssteuerung über eine Zugriffsmanagerimplementierung um.
Ein Access Manager stützt sich beim Gewähren von Berechtigungen auf die Sicherheitsrichtlinie aus dem Implementierungsdeskriptor. Ein authentifizierter Benutzer-Principal darf auf die angeforderte EJB-Methode zugreifen, wenn er zu einer der erforderlichen Rollen gehört. EJB-Code darf die EJBContext-Methoden isCallerInRole und getCallerPrincipal verwenden. Der EJB-Code kann auch das JAAS-Programmiermodell und die WSSubject-Methoden doAs und doAsPrivileged verwenden, um eine JAAS-Anmeldung durchzuführen. Der Code im PrivilegedAction-Block der Methoden doAs und doAsPrivileged wird unter der Identität des Subjekts ausgeführt. Andernfalls wird die EJB-Methode je nach RunAs-Konfiguration unter der RunAs-Identität oder der Identität des aufrufenden Prozesses ausgeführt. Die J2EE-RunAs-Spezifikation erfolgt auf Enterprise-Bean-Ebene. Wenn die RunAs-Identität angegeben ist, gilt diese für alle Bean-Methoden. Die IBM RunAs-Erweiterung auf Methodenebene, die in Version 4.0 eingeführt wurde, wird in dieser Version weiterhin unterstützt.
![[z/OS]](../images/ngzos.gif)
Federal Information Processing Standards
Unter Federal Information Processing Standards (FIPS) fallen Standards und Richtlinien, die vom National Institute of Standards and Technology (NIST) für Behördensysteme aufgestellt werden. FIPS werden entwickelt, wenn dringende behördliche Anforderungen für Standards, wie z. B. Sicherheit und Interoperabilität, bestehen, aber keine geeigneten Industriestandards oder -lösungen vorhanden sind.
WebSphere Application Server umfasst Verschlüsselungsmodule, darunter Java Secure Socket Extension (JSSE) und Java Cryptography Extension (JCE), die gemäß FIPS 140-2 zertifiziert sind.
Nähere Informationen hierzu finden Sie im Artikel FIPS-JSSE-Dateien konfigurieren.
- AES (FIPS 197)
- TripleDES (FIPS 46-3)
- Algorithmus SHA1 Message Digest (FIPS 180-1)
- Algorithmen für digitale Signatur nach DSA und RSA (FIPS 186-2)
- ANSI X 9.31 (FIPS 186-2)
- IBM Random Number Generator
Das Verschlüsselungsmodul IBMJCEFIPS enthält die FIPS-konformen Algorithmen, die eine Untergruppe der in den IBM JCE-Modulen enthaltenen Algorithmen sind.