Authentifizierungsprotokoll für EJB-Sicherheit

Server in WebSphere Application Server Version 9.0 unterstützen nur das Authentifizierungsprotokoll CSIv2. [AIX Solaris HP-UX Linux Windows][IBM i] 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/OS]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][IBM i]SAS ist das Authentifizierungsprotokoll, das von allen früheren Releases von WebSphere Application Server verwendet wurde, und wird deshalb für die Abwärtskompatibilität beibehalten. Die Object Management Group (OMG) hat das Authentifizierungsprotokoll CSIv2 definiert, damit die Hersteller sicher miteinander interagieren können. CSIv2 wird in WebSphere Application Server mit mehr Features als SAS implementiert und als das strategische Protokoll betrachtet.
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.
[z/OS]Die Object Management Group (OMG) hat das Authentifizierungsprotokoll CSIv2 definiert, damit die Hersteller sicher miteinander interagieren können. CSIv2 wird in WebSphere Application Server mit mehr Features als z/SAS implementiert und als das strategische Protokoll betrachtet.
Wichtig: z/SAS wird nur zwischen Servern der Version 6.0.x und früheren Versionen unterstützt, die in eine Zelle der Version 6.1 eingebunden wurden.

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.

Die Authentifizierungsrichtlinie trifft u.a: folgende Entscheidungen, die alle auf der Client- und der Serverkonfiguration basieren:
  • 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?

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

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

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

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

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

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

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

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

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

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

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

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

[AIX Solaris HP-UX Linux Windows][IBM i]Stateful-Clients werden mit der Eigenschaft "com.ibm.CSI.performStateful (true/false)" angegeben. Stateful-Server werden über die Administrationskonsole konfiguriert.

[z/OS]Client und Server unterstützen Stateful- und Stateless-Sitzungen. Dieses Verhalten ist nicht konfigurierbar.

Ablauf des AuthentifizierungsprotokollsAblauf des Authentifizierungsprotokolls

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.


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_corba
Dateiname:csec_corba.html