Java-EE-Connector-Sicherheit

Die Java™-EE-Connector-Architektur (Java 2 Platform, Enterprise Edition) definiert eine Standardarchitektur für die Verbindung von J2EE mit heterogenen unternehmensweiten Informationssystemen (EIS, Enterprise Information Systems). Beispiele für ein EIS sind ERP-Systeme, Mainframe Transaction Processing (TP) und Datenbanksysteme.

Die Connector-Architektur ermöglicht es einem EIS-Anbieter, einen Standardressourcenadapter für sein EIS anzubieten. Ein Ressourcenadapter ist ein Software-Treiber auf Systemebene, den eine Java-Anwendung für die Verbindung zu einem unternehmensweiten Informationssystem nutzt. Der Ressourcenadapter integriert sich in einen Anwendungsserver und bietet Konnektivität zwischen EIS, Anwendungsserver und Unternehmensanwendung. Der Zugriff auf Informationen im EIS unterliegt normalerweise einer Zugriffskontrolle, um unbefugte Zugriffe zu verhindern. J2EE-Anwendungen müssen sich für das EIS authentifizieren, um eine Verbindung öffnen zu können.

Die Java-2-Connector-Sicherheitsarchitektur erweitert das End-to-End-Sicherheitsmodell für J2EE-basierte Anwendungen in der Weise, dass EIS-Umgebungen (Enterprise Information Systems) in dieses Modell eingeschlossen werden. Ein Anwendungsserver und ein EIS arbeiten zusammen, um die ordnungsgemäße Authentifizierung eines Ressourcen-Principals zu gewährleisten, wodurch eine Verbindung zu einem darunterliegenden EIS aufgebaut wird. Die Connector-Architektur erkennt die folgenden allgemein unterstützten Authentifizierungsverfahren an, obwohl auch andere Verfahren definiert werden können:
  • BasicPassword: Einfaches, auf Benutzer und Kennwort basierendes Authentifizierungsverfahren, das spezifisch für ein EIS ist.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Kerbv5: Auf Kerberos Version 5 basierendes Authentifizierungsverfahren.

Die Anwendungen definieren in den resource-ref-Elementen des Implementierungsdeskriptors, ob eine anwendungsgesteuerte Anmeldung oder eine containergesteuerte Anmeldung verwendet werden soll. Jedes resource-ref-Element beschreibt eine einzelne Referenzbindung der Verbindungsfactory. Das Element "res-auth" in einem resource-ref-Element, dessen Wert entweder Application oder Container lautet, zeigt an, ob die Anmeldung vom Code der Enterprise-Bean ausgeführt werden soll oder ob sich WebSphere Application Server unter Verwendung der Principal-Zuordnungskonfiguration bei einem Ressourcenmanager anmelden soll. Das Element "resource-ref" wird gewöhnlich während der Anwendungsassemblierung mit einem Assembliertool definiert. Das Element resource-ref kann jedoch während der Implementierung definiert bzw. erneut definiert werden.

Anwendungsgesteuerte Anmeldung

Damit Sie auf ein EIS-System zugreifen können, müssen Anwendungen eine Verbindungsfactory über den JNDI-Namespace lokalisieren und die Methode "getConnection" für dieses Verbindungsfactoryobjekt aufrufen. Für die Methode "getConnection" müssen Sie möglicherweise eine Benutzer-ID und ein Kennwort als Argumente angeben. Eine J2EE-Anwendung kann eine Benutzer-ID und ein Kennwort an die Methode "getConnection" übergeben, die diese Angaben daraufhin au den Ressourcenadapter übermittelt. Die Angabe einer Benutzer-ID und eines Kennworts im Anwendungscode kann allerdings die Sicherheit beeinträchtigen.

Benutzer-ID und Kennwort sind, falls Sie im Java-Quellcode codiert sind, für die Entwickler und Tester im Unternehmen zugänglich. Außerdem sind die Benutzer-ID und das Kennwort für die Benutzer sichtbar, wenn sie die Java-Klasse dekompilieren.

Benutzer-ID und Kennwort können nicht geändert werden, sofern nicht zuerst eine Codeänderung erfolgt. Alternativ dazu könnte der Anwendungscode Gruppen von Benutzer-IDs und Kennwörtern aus dem permanenten Speicher oder aus einem externen Service abrufen. Diese Vorgehensweise setzt voraus, dass die IT-Administratoren für die Konfiguration und Verwaltung von Benutzer-ID und Kennwort das anwendungsspezifischen Verfahren verwenden.

Für den Zugriff auf diese Authentifizierungsdaten unterstützt der Anwendungsserver einen komponentengesteuerten Authentifizierungsalias, der in einer Ressource angegeben wird. Diese Authentifizierungsdaten sind in allen Referenzen auf die Ressource enthalten. Klicken Sie auf Ressourcen > Ressourcenadapter > J2C-Verbindungsfactorys > Konfigurationsname. Wählen Sie die Option "Komponentengesteuerten Authentifizierungsalias verwenden" aus.

Wenn Sie res-auth=Application verwenden, werden die Authentifizierungsdaten den folgenden Elementen in der folgenden Reihenfolge entnommen:
  1. Benutzer-ID und Kennwort, die an die Methode "getConnection" übergeben werden
  2. Komponentengesteuerter Authentifizierungsalias in der Verbindungsfactory oder Datenquelle
  3. Angepasste Eigenschaften "Benutzername" und "Kennwort" in der Datenquelle

Die Eigenschaften "Benutzername" und "Kennwort" können ursprünglich in der RAR-Datei definiert werden.

[AIX Solaris HP-UX Linux Windows][z/OS]Diese Eigenschaften können auch in der Administrationskonsole oder mit wsadmin-Scripting in den angepassten Eigenschaften definiert werden.

[IBM i]Verwenden Sie keine angepassten Eigenschaften, da dies den Benutzern ermöglicht, eine Verbindung zu den Ressourcen herzustellen.

Containergesteuerte Anmeldung

Die Benutzer-ID und das Kennwort für das Ziel-EIS können vom Anwendungsserver bereitgestellt werden. Das Produkt unterstützt die Funktionalität für eine containergesteuerte Anmeldung. Der Anwendungsserver sucht die geeigneten Authentifizierungsdaten für das Ziel-EIS, sodass der Client eine Verbindung zu diesem System herstellen kann. Der Anwendungscode muss im Aufruf von getConnection keine Benutzer-ID und kein Kennwort angeben, wenn er für die containergesteuerte Anmeldung konfiguriert ist. Außerdem müssen die Authentifizierungsdaten nicht in allen Referenzen auf eine Ressource enthalten sein. WebSphere Application Server verwendet ein JAAS-Plug-in-Authentifizierungsverfahren, um eine vorkonfigurierte JAAS-Anmeldekonfiguration und das Anmeldemodul zu verwenden, damit die Sicherheitsidentität und der Identitätsnachweis eines Clients im aktiven Thread einer vorkonfigurierten Benutzer-ID und einem vorkonfigurierten Kennwort zugeordnet werden.

Im Lieferumfang des Produkts ist ein Anmeldemodul (LoginModul) mit einer N:1-Zuordnung des Identitätsnachweises vorhanden, das eine Clientidentität im aktiven Thread einer vorkonfigurierten Benutzer-ID und einem vorkonfigurierten Kennwort für ein angegebenes Ziel-EIS zuordnet. Das Standardzuordnungsmodul ist ein spezielles JAAS-Anmeldemodul, das ein Kennwort (PasswordCredential) zurückgibt, das von dem konfigurierten J2C-Authentifizierungsdateneintrag (Java 2 Connector) konfiguriert wurde. Das LoginModule-Modul für die Standardzuordnung führt eine Tabellensuche, aber nicht die tatsächliche Authentifizierung durch. Benutzer-ID und Kennwort sind zusammen mit einem Alias in der Liste der J2C-Authentifizierungsdaten gespeichert.

Die Liste der J2C-Authentifizierungsdaten finden Sie in der Anzeige "Globale Sicherheit" unter Java Authentication and Authorization ServiceJ2C-Authentifizierungsdaten. Die Standardzuordnungsfunktion für Principal und Identitätsnachweis wird durch die JAAS-Anmeldekonfiguration DefaultPrincipalMapping der Anwendung definiert.

In der Administrationskonsole geänderte J2C-Authentifizierungsdaten werden wirksam, wenn die Änderungen im Repository gespeichert sind und ein Verbindungstest durchgeführt wurde. Auch mit wsadmin-Scripting geänderte J2C-Authentifizierungsdaten werden erst gültig, wenn die Anwendungen für einen bestimmten Anwendungsserverprozess gestartet bzw. erneut gestartet werden. Die Änderung von J2C-Authentifizierungsdaten wird durch Aufruf der Methode "updateAuthDataCfg" der MBean "SecurityAdmin" in Kraft gesetzt. Setzen Sie den Parameter "HashMap" auf null, damit die MBean "Securityadmin" die J2C-Authentifizierungsdaten mit den aktuellen Werten aus dem Repository aktualisieren kann.

Ändern Sie die Anmeldekonfiguration "DefaultPrincipalMapping" nicht, weil das Produkt dieser häufig verwendeten Standardzuordnungskonfiguration Leistungserweiterungen hinzugefügt hat. Die Änderung der Konfiguration "DefaultPrincipalMapping", die Änderung des LoginModule-Standardmoduls oder das Anordnen eines angepassten LoginModule-Moduls im Konfigurationsstack wird vom Produkt nicht unterstützt.

[z/OS]Sind auf der z/OS-Plattform keine Benutzer-ID und kein Kennwort bzw. keine entsprechenden Standardangaben zu einem Aliasnamen vorhanden, sucht die Laufzeitumgebung von WebSphere Application Server nach einer SAF-Benutzer-ID (SAF = System Authorization Facility) im Subjekt.

Für die meisten Systeme genügt die Standardmethode mit einer N:1-Zuordnung. Das Produkt unterstützt jedoch angepasste Konfigurationen für Principal- und Identitätsnachweiszuordnungen. Der JAAS-Konfiguration für Anwendungsanmeldung können angepasste Zuordnungsmodule hinzugefügt werden, indem eine neue JAAS-Anmeldekonfiguration mit einem eindeutigen Namen erstellt wird. Beispielsweise kann ein angepasstes Zuordnungsmodul eine Eins-zu-eins-Zuordnung oder Kerberos-Funktionalität bereitstellen.

Gesicherte Verbindungen bieten ebenfalls eine Eins-zu-eins-Zuordnung und unterstützen gleichzeitig die Weitergabe der Clientidentität. Durch Verwendung des gesicherten DB2-Kontextobjekts nutzen gesicherte Verbindungen außerdem das Verbindungs-Pooling, um Leistungseinbußen, die durch das Schließen und erneute Öffnen von Verbindungen unter einer anderen Identität entstehen, zu reduzieren. Die Verwendung gesicherter Verbindungen erhöht außerdem die Sicherheit Ihrer DB2-Datenbank, da es nicht mehr erforderlich ist, alle Berechtigungen einem einzelnen Benutzer zuzuordnen. Die Verbindung wird von einem Benutzer hergestellt, dessen Berechtigungsnachweise für das Herstellen der Verbindung vom DB2-Server anerkannt sind. Derselbe Benutzer wird dann auch für die Zusicherung der Identität der anderen Benutzer, die über die Anwendung auf den DB2-Server zugreifen, anerkannt. Eine neue Zuordnungskonfiguration mit dem Namen "TrustedConnectionMapping" implementiert gesicherte Verbindungen.

Außerdem können Sie mithilfe der Administrationskonsole von WebSphere Application Server die Referenzen der Verbindungsfactory des Ressourcenmanagers an eine der konfigurierten Ressourcenfactorys binden. Wenn das Element "res-auth" im Implementierungsdeskriptor Ihrer Anwendung den Wert Container hat, müssen Sie die Zuordnungskonfiguration angeben. Zum Angeben der Zuordnungskonfiguration verwenden Sie den Link "Ressourcenreferenzen" unter "Referenzen" in der Anzeige Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen > Anwendungsname. Weitere Anweisungen finden Sie im Artikel "Referenzen Ressourcenreferenzen zuordnen".

J2C-Zuordnungsmodule und -Zuordnungseigenschaften

Zuordnungsmodule sind spezielle JAAS-Anmeldemodule, die die Zuordnung von Principals und Identitätsnachweisen unterstützen. Sie können angepasste Zuordnungsmodule über die Administrationskonsole definieren und konfigurieren.

Außerdem können Sie mittels Anmeldeoptionen in jeder JAAS-Anmeldekonfiguration Kontextdaten definieren und an die Zuordnungsmodule übergeben. Im Produkt können Sie darüber hinaus mithilfe von Zuordnungseigenschaften in jeder Referenzbindung der Verbindungsfactory Kontextdaten definieren.

Die Anmeldeoptionen, die für jede JAAS-Anmeldekonfiguration definiert sind, werden von allen Ressourcen, die dieselbe JAAS-Anmeldekonfiguration und dieselben Zuordnungsmodule verwenden, gemeinsam genutzt. Die Zuordnungseigenschaften, die für jede Referenzbindung der Verbindungsfactory definiert sind, werden ausschließlich von der betreffenden Ressourcenreferenz verwendet.

Stellen Sie sich ein Einsatzszenario vor, in dem ein externer Zuordnungsservice verwendet wird.

Sie können beispielsweise den Service Global Sign-On (GSO) von Tivoli Access Manager verwenden. Lokalisieren Sie mit dem GSO-Service von Tivoli Access Manager die Authentifizierungsdaten für beide Back-End-Server.

Zwei EIS-Server sind vorhanden: DB2 und MQ. Die Authentifizierungsdaten für DB2 unterscheiden sich allerdings von den Authentifizierungsdaten für MQ. Verwenden Sie die Anmeldeoption in einer zugeordneten JAAS-Anmeldekonfiguration, um die Parameter anzugeben, die für eine Verbindung zum Tivoli Access Manager-GSO-Service erforderlich sind. Verwenden Sie die Zuordnungseigenschaften in einer Referenzbindung der Verbindungsfactory, um festzulegen, für welchen EIS-Server die Benutzer-ID und das Kennwort erforderlich sind.

Ausführlichere Informationen zum Entwickeln eines Zuordnungsmoduls finden Sie im Artikel "Zuordnungsmodule für J2C-Principals".

Anmerkung:
  • Die Zuordnungskonfiguration auf der Ebene der Verbindungsfactory wurde auf die Ebene der Verbindungsfactoryreferenz des Ressourcenmanagers verschoben. Die Zuordnungsanmeldemodule, die mit JAAS-Callback-Typen der WebSphere Application Server Version 5 entwickelt wurden, können von der Verbindungsfactoryreferenz des Ressourcenmanagers verwendet werden, aber sie können keine angepassten Zuordnungseigenschaften verwenden.
  • Referenzbindungen der Verbindungsfactory unterstützen Zuordnungseigenschaften und übermitteln diese Eigenschaften mit dem neuen Callback "WSMappingPropertiesCallback" an die Zuordnungsanmeldemodule. Darüber hinaus sind der Callback "WSMappingPropertiesCallback" und der neue Callback "WSManagedConnectionFactoryCallback" im Paket "com.ibm.wsspi" definiert. Verwenden Sie die neuen Anmeldemodule für die Zuordnung für die neuen Callback-Typen.

Sichere Nachrichtenzustellung mit Sicherheitskontext für eingehende Nachrichten

Sicherheitsinformationen für den Anwendungsserver können von einem EIS-Ressourcenadapter mittels Sicherheitskontext für eingehende Nachrichten bereitgestellt werden. Bei Verwendung des Sicherheitskontexts für eingehende Nachrichten kann der Arbeitsmanager unter einer konfigurierten Identität Aktionen einer Work-Instanz ausführen. Zu diesen Aktionen gehören die Zustellung von Nachrichten an Java-EE-Nachrichtenendpunkte, die als Message-driven Beans (MDB) unter einer Identität verarbeitet werden, die in einer Sicherheitsdomäne des Anwendungsservers konfiguriert ist.

Achtung: Der Sicherheitskontext für eingehende Nachrichten wird nur für Ressourcenadapter unterstützt, die mit JCA 1.6 konform sind. Das Produkt stellt derzeit keinen integrierten Ressourcenadapter mit Unterstützung für einen Sicherheitskontext für eingehende Nachrichten bereit. Wenn Sie den eingehenden SecurityContext zum Sichern der Nachrichtenzustellung verwenden möchten benötigen Sie einen Ressourcenadapter, der Java-EE-Messaging und den Sicherheitskontext für eingehende Nachrichten unterstützt.

Die sichere Nachrichtenzustellung an einen Nachrichtenendpunkt erfordert, dass die globale Sicherheit aktiviert ist. Außerdem muss in dem Anwendungsserver, der die Anwendung mit der Nachrichtenendpunkt-MDB bereitstellt, die Anwendungssicherheit aktiviert sein. Weitere Informationen zur globalen Sicherheit enthält der Artikel "Einstellungen für globale Sicherheit".

Die Sicherheitsrichtlinie des Anwendungsimplementierungsdeskriptors muss mit Rollen konfiguriert sein, die Benutzer-IDs in dem Anwendungsrealm zugeordnet sind, der die Benutzerregistry der Sicherheitsdomäne bildet, in der sich die Anwendung befindet. Mit dieser Sicherheitskonfiguration wird die EJB-Sicherheit aktiviert und der Zugriff bestimmter Benutzer-IDs im Anwendungsrealm auf MDB-Methoden autorisiert. Einen weitergehenden Überblick über die Sicherheit gibt der Artikel "Sicherheit".

Die sichere Nachrichtenzustellung erfordert außerdem, dass der Ressourcenadapter Implementierungen für die Schnittstellen WorkContextProvider und SecurityContext definiert. Für die Zustellung einer sicheren Nachricht übergibt der Ressourcenadapter zunächst eine Work-Instanz, die eine SecurityContext-Implementierung bereitstellt. Mit dieser Implementierung legt der Arbeitsmanager dann das Ausführungssubjekt für diese Work-Instanz fest.

Während der Einrichtung eines Ausführungssubjekts kann ein SecurityContext Implementierungen von JASPIC-Callbacks (Java Authentication Service Provider Interface for Containers) bereitstellen, die der Arbeitsmanager verwendet, um Caller- und Gruppenidentitäten (CallerPrincipalCallback, GroupPrincipalCallback) zu bestimmen und um Caller-Identität und -Kennwort (PasswordValidationCallback) zu authentifizieren. Wenn die Caller-ID im Anwendungsrealm enthalten ist, sichert der Arbeitsmanager diese ID zu, indem er eine WSSubject-Instanz mit dem Caller-Principal, allen Gruppenprincipals und allen privaten Berechtigungsnachweisen konstruiert.

Alternativ kann der Sicherheitskontext ein Ausführungssubjekt bereitstellen, das eine Instanz der von einem anderen Anmelde- oder Authentifizierungsmodul erstellten WSSubject-Instanz ist. Der Arbeitsmanager akzeptiert diese WSSubject-Instanz nur, wenn sich der Caller-Principal im Anwendungsrealm oder in einem anerkannten Realm befindet. Weitere Informationen zu Realms finden Sie im Artikel "Eingehende anerkannte Realms für mehrere Sicherheitsdomänen konfigurieren".

Der Arbeitsmanager weist eine Work-Instanz zurück, wenn er keine WSSubject-Instanz festlegen kann. Andernfalls sendet er die Instanz unter der zugesicherten oder akzeptierten WSSubject-Instanz über einen verwalteten Thread. Falls der Sicherheitskontext keine Caller-ID bereitstellt, wird die Work-Instanz unter einer WSSubject-Instanz mit dem nicht authentifizierten Caller-Principal gesendet.

Beim Senden kann eine Work-Instanz versuchen, Nachrichten an die MDB der gesicherten Anwendung zuzustellen. Alle Nachrichten werden unter der für die Work-Instanz festgelegten WSSubject-Instanz zugestellt. Der EJB-Sicherheits-Collaborator gewährt immer dann den Zugriff auf die Methode onMessage der MDB, wenn der Caller-Principal der WSSubject-Instanz einer im Anwendungsimplementierungsdeskriptor deklarierten Rolle zugeordnet ist. Andernfalls verweigert der Collaborator den Zugriff, sodass die Nachricht nicht zugestellt werden kann. Während der Zustellung kann die MDB die EJB-Kontextmethoden isCallerInRole und getCallerPrincipal nutzen, um zusätzliche Zugriffsentscheidungen zu fällen. Außerdem könnte die MDB auf andere Entitäten in der Sicherheitsdomäne zugreifen, für die der Caller-Principal autorisiert ist.


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_j2csecurity
Dateiname:csec_j2csecurity.html