Authentifizierungsprotokoll für EJB-Sicherheit
Server in WebSphere
Application Server Version 9.0 unterstützen nur das Authentifizierungsprotokoll CSIv2. SAS wird nur zwischen
Servern der Version 6.0.x und früheren Versionen unterstützt, die in eine
Zelle der Version 9.0 eingebunden sind.
Die Option für die Wahl zwischen SAS, CSIv2 und beiden Protokollen ist nur in der Administrationskonsole
verfügbar, wenn ein Server der Version 6.0.x oder eines früheren Release in eine Zelle
der Version 9.0 eingebunden ist.
z/SAS wird nur zwischen
Servern der Version 6.0.x und früheren Versionen unterstützt, die in eine
Zelle der Version 9.0 eingebunden sind.
Die Option zur Auswahl von z/SAS und/oder CSIv2 ist in der Administrationskonsole nur verfügbar, wenn ein älteres Release (Version
6.0.x oder früher) in eine Zelle der Version 6.1 eingebunden wurde.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
Der Aufruf von EJB-Methoden (Enterprise Java™Beans) in einer sicheren Umgebung von WebSphere Application Server setzt voraus, dass ein Authentifizierungsprotokoll die Sicherheitsstufe und den Authentifizierungstyp für die Verarbeitung jeder Anforderung zwischen einem bestimmten Client und dem Server bestimmt. Das Authentifizierungsprotokoll muss während eines Methodenaufrufs die Authentifizierungsbestimmungen des Servers (bestimmt durch die IOR (Interoperable Object Reference) des Objekts) mit denen des Clients (bestimmt durch die Clientkonfiguration) in Verbindung bringen und eine Authentifizierungsrichtlinie speziell für dieses Client- und Server-Paar anbieten.
- Welche Art von Verbindung ist zu diesem Server möglich -- SSL oder TCP/IP?
- Wenn SSL gewählt wird: Wie stark ist die Verschlüsselung der Daten?
- Wenn SSL gewählt wird: Soll der Client über Clientzertifikate authentifiziert werden?
- Soll der Client über Benutzer-ID und Kennwort authentifiziert werden? Sind bereits Berechtigungsnachweise vorhanden?
- Soll die Identität des Clients gegenüber Downstream-Servern zugesichert werden?
- In Anbetracht der Konfiguration von Client und Server: Soll eine sichere Anforderung stattfinden?
Sie können beide Protokolle (SAS und CSIv2) so konfigurieren, dass sie parallel ausführbar sind.
Wenn ein Server beide Protokolle unterstützt, exportiert er IORs mit
gekennzeichneten Komponenten, die die Konfiguration für
SAS und CSIv2 beschreiben. Unterstützt ein Client beide Protokolle, liest er die gekennzeichneten Komponenten für
CSIv2 und SAS.
Werden beide Protokoll sowohl von Client als auch von unterstützt,
wird CSIv2 verwendet. Wenn der Server jedoch
SAS unterstützt (beispielsweise weil er ein früheres
Release von WebSphere Application Server hat) und der Client beide Protokolle unterstützt, wählt der Client
SAS für die Anforderung aus, weil dieses Protokoll von Server und Client unterstützt wird.
Sie können beide Protokolle (z/SAS und CSIv2) so konfigurieren, dass sie parallel ausführbar sind.
Wenn ein Server beide Protokolle unterstützt, exportiert er IORs mit
gekennzeichneten Komponenten, die die Konfiguration für
z/SAS und CSIv2 beschreiben. Unterstützt ein Client beide Protokolle,
liest er die gekennzeichneten Komponenten für CSIv2 und
z/SAS. Werden beide Protokoll sowohl von Client als auch von unterstützt,
wird CSIv2 verwendet. Wenn der Server jedoch
z/SAS unterstützt (beispielsweise weil er ein früheres
Release von WebSphere Application Server hat) und der Client beide Protokolle unterstützt, wählt der Client
z/SAS für die Anforderung aus, weil dieses Protokoll von Server und Client unterstützt wird.
CSIv2 ist auf dem Client aktiviert, wenn die
Java-Eigenschaft "com.ibm.CORBA.ConfigURL" vorhanden ist. Wenn die Eigenschaft nicht angegeben oder die
angegebene Eigenschaft nicht vorhanden ist, ist CSIv2 nicht aktiviert.
Definieren Sie das Protokoll auf Clientseite mit der
Eigenschaft com.ibm.CSI.protocol, und konfigurieren Sie es auf Serverseite
mit der Administrationskonsole.
Nähere Einzelheiten hierzu finden Sie in den Artikeln über die Eigenschaften von SAS und CSIv2.
Common Secure Interoperability Specification Version 2
Die
Spezifikation von Common Secure Interoperability, Version 2 (CSIv2) definiert den
Security Attribute Service (SAS), der die interoperable Authentifizierung,
Bevollmächtigung und Berechtigungen aktiviert. Die Protokolle CSIv2 SAS und SAS sind vollständig verschieden.
Das Protokoll CSIv2-SAS ist eine Unterkomponente von CSIv2, die SSL und die
Interoperabilität mit der EJB-Spezifikation Version 2.1 unterstützt.
Die
Spezifikation von Common Secure Interoperability, Version 2 (CSIv2) definiert den
Security Attribute Service (SAS), der die interoperable Authentifizierung und
Delegierung aktiviert. Die Protokolle CSIv2 und z/SAS sind vollständig verschieden.
CSIv2 SAS ist eine Unterkomponente von
CSIv2, die SSL und Interoperabilität unterstützt.
Security Attribute Service
Das Protokoll CSIv2 SAS ist für den Austausch seiner Protokollelemente im Servicekontext einer GIOP-Anforderung (General Inter-ORB Protocol) und der Antwortnachrichten bestimmt, die über einen verbindungsbasierten Transport übertragen werden. Das Protokoll soll in Umgebungen verwendet werden, wo Transportschichtsicherheit, wie sie über SSL (Secure Sockets Layer) oder TLS (Transport Layer Security) verfügbar ist, zum Nachrichtenschutz (d. h. Integrität und/oder Vertraulichkeit) und zur Server-zu-Clientauthentifizierung verwendet wird. Das Protokoll bietet Funktionalität für Clientauthentifizierung, Bevollmächtigung und Berechtigung, die dazu eingesetzt werden kann, entsprechende Defizite in darunterliegenden Transporten zu beheben. Das Protokoll CSIv2 SAS erleichtert die Interoperabilität, indem es als Protokoll höherer Stufe dient, unter dem sichere Transporte zusammengefasst werden können.
Verbindungs- und Anforderungs-Interceptor
Die von WebSphere Application Server verwendeten Authentifizierungsprotokolle sind Add-on-IIOP-Services (IIOP = Interoperable Inter-ORB Protocol). IIOP ist ein Anforderungs-/Antwort-Übertragungsprotokoll, das zum Senden von Nachrichten zwischen zwei ORBs (Object Request Brokers) verwendet wird. Für jede Anforderung von einem Client-ORB an einen Server-ORB gibt es eine zugeordnete Antwort vom Server-ORB zurück zum Client-ORB. Vor dem Austausch von Anforderungen muss über das TCP/IP-Transportprotokoll (SSL ist eine sichere Version von TCP/IP) eine Verbindung zwischen Client-ORB und Server-ORB aufgebaut werden. Der Client-ORB ruft den Clientverbindungs-Interceptor des Authentifizierungsprotokolls auf. Dieser wird zum Lesen der markierten Komponenten in der IOR des Objekts verwendet, das sich auf dem Server befindet. Wie zuvor erwähnt, wird hier die Authentifizierungsrichtlinie für die Anforderung aufgebaut. In Anbetracht der Authentifizierungsrichtlinie (Zusammenbringen von Client- und Serverkonfiguration) wird die benötigte Stärke der Verbindung an den ORB zurückgeliefert. Der ORB erstellt die geeignete Verbindung, üblicherweise über SSL.
Wenn die Verbindung aufgebaut ist, ruft der Client-ORB den Clientanforderungs-Interceptor des Authentifizierungsprotokolls auf, der dazu verwendet wird, Sicherheitsinformationen zu senden, die von dem abweichen, was durch das Transportprotokoll aufgebaut wurde. Dazu gehören Benutzer-ID- und Kennworttoken (authentifiziert vom Server), ein für das Authentifizierungsverfahren spezifisches Token (bestätigt vom Server), oder ein Token für die Zusicherung der Identität. Zusicherung der Identität ist eine Möglichkeit für einen Server, einen anderen Server anzuerkennen, ohne den anfordernden Client erneut authentifizieren oder erneut bestätigen zu müssen. Allerdings ist auf Seiten des Servers eine gewisse Arbeit erforderlich, damit der Upstream-Server anerkannt wird. Diese zusätzlichen Sicherheitsinformationen werden mit der Nachricht in einem Servicekontext gesendet. Ein Servicekontext hat eine registrierte Kennung, damit der Server-ORB identifizieren kann, welches Protokoll die Informationen sendet.
Die
Tatsache, dass ein Servicekontext eine eindeutige ID enthält, bietet
WebSphere Application Server
eine weitere Möglichkeit, die Protokolle
SAS und CSIv2 gleichzeitig zu unterstützen, weil beide Protokolle
unterschiedliche Servicekontext-IDs haben. Nachdem der Clientanforderungs-Interceptor den Servicekontext zur Nachricht hinzugefügt hat, wird die Nachrichtan den Server-ORB gesendet.
Die
Tatsache, dass ein Servicekontext eine eindeutige ID enthält, bietet
WebSphere Application Server
eine weitere Möglichkeit, die Protokolle
z/SAS und CSIv2 gleichzeitig zu unterstützen, weil beide Protokolle
unterschiedliche Servicekontext-IDs haben. Nachdem der Clientanforderungs-Interceptor den Servicekontext zur Nachricht hinzugefügt hat, wird die Nachrichtan den Server-ORB gesendet.
Wenn
die Nachricht vom Server-ORB empfangen wird, ruft der ORB den Server-Anforderungs-Interceptor des Authentifizierungsprotokolls auf. Dieser
Interceptor sucht nach der Servicekontext-ID, die dem Protokoll bekannt ist.
Unterstützt ein Server SAS und CSIv2, werden zwei unterschiedliche
Serveranforderungs-Interceptor aufgerufen. Die beiden Interceptor suchen nach unterschiedlichen Servicekontext-IDs.
Wenn
die Nachricht vom Server-ORB empfangen wird, ruft der ORB den Server-Anforderungs-Interceptor des Authentifizierungsprotokolls auf. Dieser
Interceptor sucht nach der Servicekontext-ID, die dem Protokoll bekannt ist.
Unterstützt ein Server z/SAS und CSIv2, werden zwei unterschiedliche
Serveranforderungs-Interceptor aufgerufen. Die beiden Interceptor suchen nach unterschiedlichen Servicekontext-IDs.
Jedoch wird nur jeweils einer von ihnen einen Servicekontext für eine bestimmte Anforderung finden. Wenn der Interceptor für die Serveranforderung einen Servicekontext findet, liest er die darin enthaltenen Informationen. Es wird eine Methode für den Sicherheitsserver aufgerufen, um die Identität des Clients zu authentifizieren oder zu bestätigen. Der Sicherheitsserver weist die Information entweder zurück oder gibt einen Berechtigungsnachweis zurück. Ein Berechtigungsnachweis enthält zusätzliche Informationen über den Client, die aus der Benutzerregistrierungsdatenbank abgerufen wurden, damit die Berechtigungsfunktion die richtige Entscheidung treffen kann. Berechtigung ist der Prozess, bei dem ermittelt wird, ob der Benutzer die Anforderung aufrufen können soll. Dies erfolgt auf Basis der Rolle, die für die Methode gilt, sowie auf Basis der Rolle des Benutzers.
Wenn der Interceptor für CSIv2-Serveranforderungen keinen Servicekontext findet, sucht er in der Transportverbindung, ob eine Verkettung von Clientzertifikaten gesendet wird. Dies erfolgt, wenn zwischen Client und Server eine SSL-Clientauthentifizierung konfiguriert wurde.
Wird eine Clientzertifizierungskette gefunden,
wird der definierte Name (DN) aus dem Zertifikat extrahiert und für die Zuordnung
einer ID in der Benutzerregistry verwendet. Wenn LDAP als Benutzerregistrierungsdatenbank verwendet wird, legen die in der Konfiguration zur LDAP-Registrierungsdatenbank definierten Suchfilter fest, wie das Zertifikat einem Eintrag in der Registrierungsdatenbank zugeordnet wird. Beim Authentifizierungsverfahren LocalOS wird das erste Attribut des definierten Namens
(DN) der Benutzer-ID der Registry zugeordnet.
Dieses Attribut ist normalerweise der allgemeine Name.
Wenn LDAP als Benutzerregistrierungsdatenbank verwendet wird, legen die in der Konfiguration zur LDAP-Registrierungsdatenbank definierten Suchfilter fest, wie das Zertifikat einem Eintrag in der Registrierungsdatenbank zugeordnet wird. Bei der Benutzerregistry LocalOS wird das Zertifikat einer SAF-Benutzer-ID (System Authorization Facility) zugeordnet.
Sie können die Benutzer-ID anschließend unter Verwendung des Aussteller- oder
Subjektnamens mit der SAF-Funktion für Zertifikatzuordnung zuordnen.
Wenn das Zertifikat sich nicht zuordnen lässt, wird kein Berechtigungsnachweis erstellt und die Anforderung zurückgewiesen. Wenn ungültige Sicherheitsinformationen präsentiert werden, wird die Methodenanforderung zurückgewiesen und eine Ausnahme NO_PERMISSION mit der Antwort zurückgesendet. Werden jedoch keine Sicherheitsinformationen präsentiert, so wird ein nicht authentifizierter Berechtigungsnachweis für die Anforderung erstellt, und die Engine für die Berechtigung bestimmt, ob die Methode aufgerufen wird. Damit eine EJB-Methode (Enterprise JavaBeans) mit einem nicht authentifizierten Berechtigungsnachweis aufgeufen werden kann, dürfen entweder keine Sicherheitsrollen für die Methode definiert sein, oder es muss eine Sonderrolle "Everyone" (Jeder) für die Methode definiert sein.
Wenn der Methodenaufruf im EJB-Container beendet ist, wird der Interceptor für Serveranforderungen erneut aufgerufen, um die serverseitige Authentifizierung zu beenden. Es wird ein neuer Antwortservicekontext erstellt, um den Interceptor für Clientanforderungen über den Ausgang zu informieren. Dieser Prozess wird gewöhnlich verwendet, um die Anforderung statusabhängig zu machen. Wenn eine kontextsensitive Anforderung abgesetzt wird, müssen nur bei der ersten Anforderung zwischen Client und Server Sicherheitsinformationen gesendet werden. Bei allen darauffolgenden Methodenanforderungen muss nur eine eindeutige Kontext-ID gesendet werden, damit der Server den Berechtigungsnachweis suchen kann, der in einer Sitzungstabelle gespeichert ist. Die Kontext-ID ist innerhalb der Verbindung zwischen einem Client und einem Server eindeutig.
Schließlich endet der Methodenanforderungszyklus, indem der Interceptor für Clientanforderungen eine Antwort vom Server mit einem Antwort-Servicekontext erhält, der Informationen liefert, mit denen die clientseitige kontextsensitive Kontext-ID bestätigt und erneut verwendet werden kann.
Stateful-Clients werden mit der
Eigenschaft "com.ibm.CSI.performStateful (true/false)" angegeben.
Stateful-Server werden über die Administrationskonsole
konfiguriert.
Client und Server
unterstützen Stateful- und Stateless-Sitzungen. Dieses Verhalten ist nicht
konfigurierbar.

Authentifizierungsrichtlinie für jede Anforderung
Die Authentifizierungsrichtlinie einer gegebenen Anforderung bestimmt den Sicherheitsschutz zwischen einem Client und einem Server. Eine Konfiguration des Authentifizierungsprotokolls für Client oder Server kann erforderliche, unterstützte und nicht unterstützte Eigenschaften beschreiben. Wenn ein Client eine Eigenschaft benötigt, kann er nur mit Servern kommunizieren, die diese Eigenschaft entweder erfordern oder unterstützen. Wenn ein Server eine Eigenschaft benötigt, kann er nur mit Clients kommunizieren, die diese Eigenschaft entweder erfordern oder unterstützen. Wenn ein Client eine Eigenschaft unterstützt, kommuniziert er mit Servern, die diese Eigenschaft unterstützen oder erfordern, aber auch mit Servern, die diese Eigenschaft nicht unterstützen. Wenn ein Server eine Eigenschaft unterstützt, kommuniziert, er mit Clients, die diese Eigenschaft unterstützen oder erfordern, aber auch mit Clients, die diese Eigenschaft nicht unterstützen.
Wenn z. B. ein Client die Authentifizierung über Clientzertifikate unterstützen soll, ist eine Konfigurationseinstellung erforderlich, die bewirkt, dass ein selbstsigniertes Zertifikat generiert oder ein Zertifikat von einer Zertifizierungsstelle (CA) abgerufen wird. Einige Clients müssen diese Aktionen möglicherweise nicht ausführen. Deshalb können Sie dieses Feature als nicht unterstützt konfigurieren. Aufgrund dieser Entscheidung kann ein solcher Client nicht mit einem sicheren Server kommunizieren, der eine Authentifizierung durch Clientzertifikate erfordert. Stattdessen kann sich der Client für die Verwendung von Benutzer-ID und Kennwort für die Authentifizierung beim Server entscheiden.
Die Unterstützung dieser Eigenschaft ist die verbreitetste Art der Eigenschaftskonfiguration. Dies ist auch zur Laufzeit am erfolgreichsten, da diese Methode weniger einschränkend ist als die Anforderung einer Eigenschaft. Wenn das Wissen über die Konfiguration von sicheren Servern in Ihrer Domäne vorhanden ist, können Sie die richtige Kombination für den Client wählen, damit erfolgreiche Methodenaufrufe gewährleistet sind und trotzdem ein Höchstmaß an Sicherheit vorhanden ist. Wenn Sie wissen, dass alle Ihre Server sowohl die Authentifizierung über Clientzertifikat als auch über Benutzer-ID und Kennwort unterstützen, können Sie für den Client die eine Methode auswählen und die andere nicht. Wenn sowohl Benutzer-ID und Kennwort als auch Clientzertifikat auf Client und Server unterstützt werden, werden beide Methoden ausgeführt, wobei am Server Benutzer-ID und Kennwort Vorrang haben. Diese Aktion basiert auf den Bestimmungen der CSIv2-Spezifikation.