Sicherheit

Die folgenden Informationen liefern eine Übersicht über die Sicherheit in WebSphere Application Server.

IBM® WebSphere Application Server stellt eine Sicherheitsinfrastruktur und Sicherheitsverfahren bereit, um sensible J2EE-Ressourcen (Java™ 2 Platform Enterprise Edition) und Verwaltungsressourcen zu schützen. Das Produkt erfüllt außerdem die Sicherheitsanforderungen von Unternehmen in den folgenden Bereichen:
  • Authentifizierung
  • Steuerung des Zugriffs auf Ressourcen
  • Datenintegrität
  • Vertraulichkeit
  • Datenschutz
  • Sichere Interoperabilität
Die Sicherheit von IBM WebSphere Application Server basiert auf Industriestandards und hat eine offene Architektur, die eine sichere Konnektivität und Interoperabilität mit Enterprise Information Systems gewährleistet. Dazu gehören:
  • Database 2 (DB2)
  • CICS
  • [AIX Solaris HP-UX Linux Windows][z/OS]Information Management System (IMS)
  • MQ Series
  • Lotus Domino
  • IBM Directory
WebSphere Application Server unterstützt außerdem weitere Sicherheitsprovider wie:
  • [z/OS]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

[z/OS]Identifikationsverwaltung:

[z/OS]Für WebSphere Application Server Version 7.x und frühere Releases:

[z/OS]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.)

[z/OS]Neuerungen für WebSphere Application Server Version 8.0 und höher:

[z/OS]Sie haben jetzt zwei Optionen für die Zuordnung verteilter Identitäten:
  • 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.

Die Sicherheit von WebSphere Application Server ist eine mehrschichtige Architektur, die auf der Sicherheit der Betriebssystemplattform, der Java Virtual Machine (JVM) und der Java-2-Sicherheit basiert Dieses Sicherheitsmodelle nutzt eine umfangreiche Palette von Sicherheitstechnologien, wie z. B.
  • 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.
    [AIX Solaris HP-UX Linux Windows][IBM i][z/OS]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.

Paradigma der offenen Architektur

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][IBM i]WebSphere Application Server unterstützt Simple WebSphere Authentication Mechanism (SWAM), Lightweight Third Party Authentication (LTPA) und Kerberos als Keberos-Verfahren. Nur eine Implementierung einer Benutzerregistry kann als aktive Benutzerregistry der Sicherheitsdomäne von WebSphere Application Server konfiguriert werden. WebSphere Application Server unterstützt die folgenden Benutzerregistry-Implementierungen: Lokales Betriebssystem (LocalOS) und LDAP unter UNIX, Windows und IBM i. Außerdem unterstützt das Produkt dateibasierte und JDBC-basierte Referenzimplementierungen von Benutzerregistrys. Das Produkt unterstützt eine flexible Kombination von Authentifizierungsverfahren und Benutzerregistrys. SWAM ist einfach zu konfigurieren und eignet sich gut für eine Umgebung mit einem einzelnen Anwendungsserver. SWAM kann in einer verteilten Umgebung verwendet werden, wenn die Zusicherung der Identität aktiviert ist. Bitte beachten Sie, dass die Zusicherung der Identität nur beim Sicherheitsprotokoll CSIv2 verfügbar ist.
Anmerkung: SWAM wurde einem früheren Release von WebSphere Application Server als veraltet gekennzeichnet und wird in einem der künftigen Releases entfernt.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]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]

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.

WebSphere Application Server stellt die folgenden Benutzerregistry-Implementierungen bereit:
  • 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:

Tabelle 1. Beispielregistry-Konfigurationen für WebSphere Application Server.

Diese Tabelle enthält Beispielregistry-Konfigurationen für WebSphere Application Server.

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
Die folgenden Abbildungen veranschaulichen, was in der vorherigen Tabelle beschrieben ist.
  • Konfiguration einer Netzregistry in WebSphere Application Server Konfiguration einer Netzregistry
  • Konfiguration einer Netzregistry in WebSphere Application Server for z/OS:Konfiguration einer z/OS-Netzregistry
  • Netzregistry von WebSphere Application Server mit z/OS-Sicherheitserweiterungen Netzregistry mit z/OS-Sicherheitserweiterungen

Authentifizierungsverfahren

In WebSphere Application Server werden die folgenden Authentifizierungsverfahren unterstützt:
  • 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]

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

Trust-Association ermöglicht Ihnen, Sicherheitsserver anderer Anbieter mit der Sicherheit von IBM WebSphere Application Server zu integrieren. Insbesondere kann ein Reverse-Proxy-Server als Front-End-Authentifizierungsserver arbeiten, während WebSphere Application Server seine eigene Berechtigungsrichtlinie auf die sich ergebenden Berechtigungsnachweise anwendet, die vom Proxy-Server weitergegeben werden. Der Reverse-Proxy-Server wendet seine Authentifizierungsrichtlinie auf jede Webanforderung an, die an WebSphere Application Server verteilt wird. Die folgenden Produkte implementieren Trust Association Interceptors (TAI):
  • IBM Tivoli Access Manager for e-business
  • WebSEAL
  • Caching Proxy
Weitere Informationen zur Verwendung von Trust-Associations finden Sie im Artikel Trust-Associations.

Weitergabe von Sicherheitsattributen

Die Weitergabe von Sicherheitsattributen ermöglicht WebSphere Application Server, Sicherheitsattribute von einem Server in der Konfiguration an einen anderen weiterzugeben. Sicherheitsattribute enthalten den Inhalt des authentifizierten Subjekts und Informationen zum Sicherheitskontext. WebSphere Application Server kann diese Sicherheitsattribute von folgenden Komponenten anfordern:
  • einer Unternehmensbenutzerregistry, die statische Attribute abfragt,
  • einem angepassten Anmeldemodul, das statische und dynamische Attribute abfragen kann.
Die Funktion "Weitergabe von Sicherheitsattributen" bietet Weitergabeservices mit Java-Serialisierung für alle im Subjekt enthaltenen Objekte. Weitere Informationen zur Weitergabe von Sicherheitsattributen finden Sie im Artikel Weitergabe von Sicherheitsattributen.

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][IBM i][z/OS]

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][z/OS]

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][z/OS]

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]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.

[z/OS]Weitere Informationen hierzu finden Sie im Artikel Threadidentität für Verbindungen.

[z/OS]WebSphere-Application-Server-Prozess

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".

[z/OS]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]Anmerkung: Eine Änderung der Authentifizierungsverfahren auf Serverebene ist nicht möglich.

Websicherheit

Wenn für eine Webressource eine Sicherheitsrichtlinie definiert und die Sicherheit in IBM WebSphere Application Server aktiviert ist, übernimmt der Web-Container die Zugriffssteuerung, wenn die Ressource von einem Web-Client angefordert wird. Der Web-Container fragt Authentifizierungsdaten vom Web-Client ab, sofern der Client diese nicht entsprechend dem angegebenen Authentifizierungsverfahren bereitgestellt hat, stellt sicher, dass die Dateneinschränkungen eingehalten werden, und überprüft, ob der authentifizierte Benutzer der erforderlichen Sicherheitsrolle angehört. WebSphere Application Server unterstützt die folgenden Anmeldemethoden:
  • HTTP-Basisauthentifizierung
  • HTTPS-Clientauthentifizierung
  • formularbasierte Anmeldung
  • SPNEGO-Token (Simple and Protected GSS-API Negotiation)
Für die Zuordnung eines Clientzertifikats zu einem Sicherheitsberechtigungsnachweis von WebSphere Application Server wird die Implementierung der Benutzerregistry verwendet.

[AIX Solaris HP-UX Linux Windows][IBM i]In WebSphere Application Server unterstützt die Benutzerregistry des lokalen Betriebssystems die Zuordnungsfunktion nicht.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

Web security

Hinweise für die Verwendung eines Collaborators für die Websicherheit oder die EJB-Sicherheit:
  1. 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.
  2. 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]Anmerkung: Nach der Berechtigung wird die RunAs-Identität im weiteren Verarbeitungsverlauf verwendet. Normalerweise ist dies die Identität des Aufrufenden, aber es kann auch eine delegierte Identität sein.

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.

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]Nähere Informationen hierzu finden Sie im Artikel FIPS-JSSE-Dateien konfigurieren.

Das Modul IBMJCEFIPS unterstützt die folgenden symmetrischen Cipher Suites:
  • AES (FIPS 197)
  • TripleDES (FIPS 46-3)
  • Algorithmus SHA1 Message Digest (FIPS 180-1)
Das Modul IBMJCEFIPS unterstützt die folgenden Algorithmen:
  • 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.


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=welc_security
Dateiname:welc_security.html