Java-EE-Connector-Sicherheit

Die Java™ 2-Plattform, Enterprise Edition ( Java EE ) Connector-Architektur definiert eine Standardarchitektur für den Anschluss J2EE zu heterogenen Unternehmensinformationssystemen (EIS). 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 Softwaretreiber auf Systemebene, der von einer Java-Anwendung zur Verbindung mit einem EIS verwendet wird. 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: Kerberos Auf Version 5 basierender Authentifizierungsmechanismus

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

Um auf ein EIS-System zuzugreifen, suchen Anwendungen eine Verbindungsfabrik aus dem Java Naming and Directory Interface (JNDI)-Namespace und rufen die getConnection Methode für dieses Verbindungsfabrikobjekt. 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.

Die Benutzer-ID und das Kennwort stehen Entwicklern und Testern in der Organisation zur Verfügung, sofern sie im Java-Quellcode codiert sind. Darüber hinaus sind die Benutzer-ID und das Kennwort für 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 Ressourcen > Ressourcenadapter >J2C Verbindungsfabriken > 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 mithilfe von wsadmin-Scripting aus 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. Der verwendet einen Java-Authentifizierungs- und Autorisierungsdienst ( JAAS) steckbarer Authentifizierungsmechanismus zur Verwendung eines vorkonfigurierten JAAS Login-Konfiguration und LoginModule um eine Client-Sicherheitsidentität und Anmeldeinformationen im laufenden Thread einer vorkonfigurierten Benutzer-ID und einem vorkonfigurierten Kennwort zuzuordnen.

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 Standardmappingmodul ist ein Spezialmodul JAAS LoginModule Modul, das ein PasswordCredential Anmeldeinformationen, die vom konfigurierten Java-2-Connector angegeben werden ( J2C) Authentifizierungsdateneingabe. 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.

DerJ2C Die Liste der Authentifizierungsdaten befindet sich im Fenster Globale Sicherheit der Java-Authentifizierung und Autorisierungsservice >J2C 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]Auf der z/OS® Plattform, wenn eine Benutzer-ID und ein Passwort nicht vorhanden sind oder durch einen Alias voreingestellt sind, WebSphere® Application Server Die Laufzeit sucht im Betreff nach einer System Authorization Facility (SAF)-Benutzer-ID.

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. Darüber hinaus durch die Nutzung der DB2® Vertrauenswürdiges Kontextobjekt: Vertrauenswürdige Verbindungen können die Vorteile des Verbindungspoolings nutzen, um die Leistungseinbußen zu verringern, die durch das Schließen und erneute Öffnen von Verbindungen mit einer anderen Identität entstehen. Die Verwendung vertrauenswürdiger Verbindungen erhöht auch die Sicherheit Ihrer DB2 Datenbank, da die Notwendigkeit entfällt, alle Berechtigungen einem einzelnen Benutzer zuzuweisen. Die Verbindung wird von einem Benutzer hergestellt, dessen Anmeldeinformationen vom DB2 Server, um die Verbindung zu öffnen, und derselbe Benutzer wird dann auch als vertrauenswürdig eingestuft, um die Identität der anderen Benutzer zu bestätigen, die auf die DB2 Server von der Anwendung. Eine neue Zuordnungskonfiguration mit dem Namen "TrustedConnectionMapping" implementiert gesicherte Verbindungen.

Sie können auch die WebSphere Application Server Verwaltungskonsole, um die Verbindungsfactory-Referenzen des Ressourcenmanagers an eine der konfigurierten Ressourcenfactorys zu binden. Wenn das Element "res-auth" im Implementierungsdeskriptor Ihrer Anwendung den Wert Container hat, müssen Sie die Zuordnungskonfiguration angeben. Um die Zuordnungskonfiguration anzugeben, verwenden Sie den Link Ressourcenreferenzen unter Referenzen auf der Anwendungen > Anwendungstypen >WebSphere geschäftliche Anwendungen > Anwendungsname-Panel . 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 Global Sign-On-Dienst (GSO) von Tivoli® Access Manager verwenden. Verwenden Sie Tivoli Access Manager GSO, um Authentifizierungsdaten für beide Back-End-Server zu suchen.

Sie haben zwei EIS-Server: DB2 Und MQ. Die Authentifizierungsdaten für DB2 unterscheidet sich von dem für MQ, Jedoch. Verwenden der Anmeldeoption in einer Zuordnung JAAS Anmeldekonfiguration, um die Parameter anzugeben, die zum Herstellen einer Verbindung mit dem Tivoli Access Manager GSO-Dienst 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".

Hinweis:
  • Die Zuordnungskonfiguration auf der Ebene der Verbindungsfactory wurde auf die Ebene der Verbindungsfactoryreferenz des Ressourcenmanagers verschoben. Die Mapping-Login-Module, die mit WebSphere Application Server Version 5 JAAS Rückruftypen können von der Verbindungsfactory-Referenz des Ressourcenmanagers verwendet werden, die Zuordnungsanmeldemodule können die Funktion für benutzerdefinierte Zuordnungseigenschaften jedoch nicht nutzen.
  • 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 Maßnahmen gehört 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.

Aufmerksamkeit: Der Sicherheits-Inflow-Kontext wird nur für JCA unterstützt. 1.6-compliant Ressourcenadapter. Das Produkt stellt derzeit keinen integrierten Ressourcenadapter mit Unterstützung für einen Sicherheitskontext für eingehende Nachrichten bereit. Verwenden von Inbound SecurityContext Zur Sicherung der Nachrichtenübermittlung ist ein Ressourcenadapter erforderlich, der Java EE Messaging- und Sicherheits-Inflow-Kontext.

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.

Bei der Festlegung des Ausführungsgegenstands SecurityContext kann Implementierungen von JASPIC-Callbacks (Java Authentication Service Provider Interface for Containers) bereitstellen, die der Work Manager verwendet, um Anrufer- und Gruppenidentitäten zu ermitteln ( CallerPrincipalCallback, GroupPrincipalCallback) und zur Authentifizierung der Anruferidentität und des Kennworts ( PasswordValidationCallback). 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.