Weitergabe von Sicherheitsattributen

Mit der Weitergabe von Sicherheitsattributen kann WebSphere Application Server Sicherheitsattribute (authentifizierte Subject-Inhalte und Informationen zum Sicherheitskontext) von einem Server auf einen anderen der Konfiguration übertragen. WebSphere Application Server kann diese Sicherheitsattribute von einer Unternehmensbenutzerregistry, die statische Attribute abfragt, oder einem angepassten Anmeldemodul, das statische oder dynamische Attribute abfragen kann, abrufen. Dynamische Sicherheitsattribute, die prinzipiell kundenspezifisch sind, können die für die Verbindung verwendete Authentifizierungsstärke enthalten, die Identität des aufrufenden Programms, die Position des aufrufenden Programms, die IP-Adresse des aufrufenden Programms usw.

Die Funktion "Weitergabe von Sicherheitsattributen" bietet Weitergabeservices mit Java-Serialisierung für alle im Subject enthaltenen Objekte. Java-Code muss diese Objekte jedoch serialisieren und entserialisieren können. Die Programmiersprache Java gibt die Regeln vor, nach denen ein Objekt mit Java-Code serialisiert werden kann. Da bei der Verwendung verschiedener Softwareversionen und -plattformen Fehler auftreten können, bietet WebSphere Application Server auch ein Token-Framework, das eine angepasste Serialisierung ermöglicht. Das Token-Framework hat weitere Vorzüge, einschließlich der Fähigkeit, die Eindeutigkeit des Tokens zu identifizieren. Diese Eindeutigkeit kommt in der Art und Weise der Zwischenspeicherung sowie im Zweck des Tokens zum Ausdruck. Das Token-Framework definiert vier Markierungstokenschnittstellen, die der WAS-Laufzeit ermöglichen, festzulegen, wie das Token weitergegeben wird.

Wichtig: Alle in diesem Framework verwendeten angepassten Token werden von WebSphere Application Server nicht für die Berechtigung oder Authentifizierung verwendet. Das Framework bietet die Möglichkeit, WebSphere Application Server zu informieren, dass diese Token auf eine bestimmte Weise weitergegeben werden sollen. WebSphere Application Server handhabt die Details der Weitergabe, jedoch nicht die Serialisierung oder Entserialisierung angepasster Token. Die Serialisierung und Entserialisierung dieser angepassten Token wird von der Implementierung durchgeführt und von einem angepassten Anmeldemodul gehandhabt.

In WebSphere Application Server Version 6.0 und höher kann ein angepasster JACC-Provider (Java Authorization Contract for Container) konfiguriert werden, der die Zugriffssteuerung für Java EE-Anwendungen (Java Platform, Enterprise Edition) durchführt. Ein angepasster JACC-Provider kann bei seinen Zugriffsentscheidungen die angepassten Sicherheitsattribute im JAAS-Subject des Aufrufenden untersuchen.

Wenn eine Anforderung authentifiziert wird, bestimmt das Anmeldemodul, ob es sich bei dieser Anforderung um eine Erstanmeldung oder eine auf der Weitergabe von Attributen basierenden Anmeldung handelt. Bei einer Erstanmeldung werden die Benutzerdaten, normalerweise eine Benutzer-ID und ein Kennwort, authentifiziert. Anschließend werden die APIs für die ferne Benutzerregistry aufgerufen, um sichere Attribute zu lokalisieren, die Benutzerzugriffsrechte darstellen. Bei einer auf der Weitergabe von Attributen basierenden Anmeldung werden die Benutzerdaten, normalerweise ein LTPA-Token (Lightweight Third Party Authentication) validiert. Anschließend wird eine Serie von Token - angepasste Objekte und Token-Framework-Objekte, die WebSphere Application Server bekannt sind, entserialisiert.

Die folgenden Markierungstoken werden im Framework eingeführt:
Berechtigungstoken
Das Berechtigungstoken enthält die meisten der auf Berechtigungen bezogenen, weitergeleiteten Sicherheitsattribute. Das Standardberechtigungstoken wird von der Berechtigungsengine von WebSphere Application Server verwendet, um Java EE-Berechtigungsentscheidungen zu treffen. Service-Provider können angepasste Implementierungen von Berechtigungstoken verwenden, um ihre Daten in einem anderen Token zu isolieren, angepasste Serialisierungen und Entserialisierungen durchzuführen und zur richtigen Zeit angepasste Berechtigungsentscheidungen mit den Daten in ihrem Token zu treffen. Informationen zur Verwendung und Implementierung dieses Tokentyps finden Sie in den Artikeln Standardweitergabetoken für die Weitergabe von Sicherheitsattributen verwenden und Angepasstes Weitergabetoken für die Weitergabe von Sicherheitsattributen implementieren.
SSO-Token (Single Signon)
Ein angepasstes SSO-Token, das zum Subject hinzugefügt wird, wird automatisch als HTTP-Cookie der Antwort hinzugefügt und enthält die Attribute, die an Web-Browser zurückgesendet werden. Die Tokenschnittstellenmethode "getName" definiert zusammen mit der Methode "getVersion" den Cookienamen. WebSphere Application Server definiert ein Standard-SSO-Token (SingleSignonToken) mit dem Namen "LtpaToken" und Version 2. Der Name des hinzugefügten Cookies lautet "LtpaToken2". Fügen Sie keine sensiblen, vertraulichen oder unverschlüsselten Daten zum Antwortcookie hinzu.

Außerdem wird empfohlen, das bei jedem Einsatz von Cookies das SSL-Protokoll (Secure Sockets Layer) zu verwenden, um die Anforderung zu schützen. Mit einem SSO-Token müssen sich Webbenutzer nur einmal authentifizieren, wenn Sie auf Webressourcen mehrerer Instanzen von WebSphere Application Server zugreifen. Ein angepasstes SSO-Token erweitert diese Funktionalität, indem es angepasste Verarbeitung zum SSO-Szenario hinzufügt. Weitere Informationen zu SSO-Token finden Sie im Artikel SSO für die Minimierung von Webbenutzerauthentifizierungen implementieren. Informationen zur Verwendung und Implementierung dieses Tokentyps finden Sie in den Artikeln Standard-SSO-Token mit Standard- oder angepasster Token-Factory für die Weitergabe von Sicherheitsattributen verwenden und Angepasstes SSO-Token für die Weitergabe von Sicherheitsattributen implementieren.

Token für Weitergabe
Das Token für Weitergabe ist dem authentifizierten Benutzer nicht zugeordnet, d. h., es ist nicht im Subject gespeichert. Stattdessen wird das Token für Weitergabe im Thread gespeichert und folgt dem Aufruf. Wenn eine Anforderung an einen anderen Server gesendet wird, werden die Weitergabetoken in diesem Thread zusammen mit der Anforderung gesendet. Die Token werden vom Zielserver ausgeführt. Die im Thread gespeicherten Attribute werden unabhängig von den Java EE-RunAs-Benutzeroptionen weitergegeben.

Das Standardtoken für Weitergabe überwacht und protokolliert alle Benutzer- und Hostschalter. Sie können mit den WSSecurityHelper-APIs weitere Informationen zum Standardtoken für Weitergabe hinzufügen. Zum Abrufen und Setzen angepasster Implementierungen eines Tokens für Weitergabe können Sie die Klasse "WSSecurityPropagationHelper" verwenden. Informationen zur Verwendung und Implementierung dieses Tokentyps finden Sie in den Artikeln Standardweitergabetoken für die Weitergabe von Sicherheitsattributen verwenden und Angepasstes Weitergabetoken für die Weitergabe von Sicherheitsattributen implementieren.

Authentifizierungstoken
Das Token für Authentifizierung wird an Downstream-Server übergeben und enthält die Benutzer-ID. Dieser Tokentyp übernimmt dieselbe Funktion wie das LTPA-Token in früheren Versionen. Obwohl dieser Tokentyp normalerweise für interne WAS-Zwecke verwendet wird, können Sie das Token zum Subject hinzufügen. Das Token wird mit der Methode "getBytes" der Tokenschnittstelle weitergegeben.

Ein angepasstes Authentifizierungstoken wird nur für den Service-Provider verwendet, der es zum Subject hinzufügt. WebSphere Application Server verwendet das Token nicht für die Authentifizierung, da bereits ein Standardtoken für Authentifizierung vorhanden ist, das für die Authentifizierung von WebSphere Application Server verwendet wird. Dieser Tokentyp steht dem Service-Provider zur Verfügung, um den Zweck der providerspezifischen Daten festzulegen und damit das Token providerspezifische Authentifizierungsaufgaben ausführen kann. Informationen zur Verwendung und Implementierung dieses Tokentyps finden Sie in den Artikeln Standardauthentifizierungstoken und Angepasstes Authentifizierungstoken für die Weitergabe von Sicherheitsattributen implementieren.

Kerberos-Authentifizierungstoken
Das Kerberos-Authentifizierungstoken enthält Kerberos-Berechtigungsnachweise, wie z. B. den Namen des Kerberos-Principals, GSSCredential- und Kerberos-Delegierungsberechtigungsnachweise. Dieses Token wird an den nachgeschalteten Server weitergegeben. Obwohl dieser Tokentyp gewöhnlich für interne Zwecke in WebSphere Application Server verwendet wird, können Sie die Methode "getGSSCredential" verwenden, um den GSSCredential-Berechtigungsnachweis zu extrahieren, falls das Token diesen Berechtigungsnachweis enthält. Anschließend können ihn in das Subject kopieren und für Ihre Anwendung verwenden. Dieses Token wird erstellt, wenn Sie sich über SPNEGO-Web- oder Kerberos-Authentifizierung bei WebSphere Application Server authentifizieren.

Horizontale Weitergabe versus Downstream-Weitergabe

Unter WebSphere Application Server sind sowohl die horizontale Weitergabe, die SSO für Webanforderungen verwendet, als auch die Downstream-Weitergabe, die RMI/IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol) verwendet, für den Zugriff auf Enterprise-Beans verfügbar.

Horizontale Weitergabe

Bei der horizontalen Weitergabe werden die Sicherheitsattribute zwischen Front-End-Servern weitergeleitet. Die serialisierten Sicherheitsattribute, die dem Subject-Inhalt und den Weitergabetoken entsprechen, können statische und dynamische Attribute enthalten. Dass SSO-Token (Single Sign-On) speichert zusätzliche systemspezifische Informationen, die für die horizontale Weitergabe erforderlich sind. Anhand der im SSO-Token enthaltenen Informationen stellt der empfangende Server fest, wo der Ursprungsserver sich befindet und wie die Kommunikation mit diesem Server erfolgen muss. Außerdem enthält das SSO-Token auch den Schlüssel zum Lokalisieren der serialisierten Attribute. Um die horizontale Weitergabe zu aktivieren, müssen Sie das SSO-Token und die Funktionen für die Weitergabe von eingehenden Sicherheitsattributen über das Web konfigurieren. Sie können beide Funktionen in der Administrationskonsole aktivieren.

Wenn Front-End-Server konfiguriert werden und sich in derselben DRS-Replikationsdomäne (Data Replication Service) befinden, gibt der Anwendungsserver die serialisierten Daten automatisch an alle Server in derselben Domäne weiter. In Abbildung 1 wird Anwendung 1 in Server 1 und Server 2 implementiert und beide Server sind Member derselben DRS-Replikationsdomäne. Wenn eine Anforderung von Anwendung 1 in Server 1 stammt und zu Anwendung 1 in Server 2 umgeleitet wird, werden die ursprünglichen Anmeldeattribute ohne zusätzliche ferne Anforderungen in Server 2 lokalisiert.

Wenn die Anforderung jedoch von Anwendung 1 in Server 1 oder Server 2 stammt, jedoch zu Anwendung 2 in Server 1 oder Server 2 umgeleitet wird, werden die serialisierten Daten nicht im DRS-Cache lokalisiert, da die Server nicht in derselben Replikationsdomäne konfiguriert werden. Daraufhin wird eine ferne JMX-Anforderung (Java Management Extensions) an den Ursprungsserver, auf dem Anwendung 1 sich befindet, zurückgesendet, um die serialisierten Daten abzurufen, damit die ursprünglichen Anmeldedaten für die Anwendung verfügbar sind. Durch das Abrufen der serialisierten Daten mit einem einzelnen, zurück an den Ursprungsserver gerichteten JMX-Aufruf können Sie folgende Vorteile nutzen:
  • Sie erhalten die Funktion zum Abrufen der Anmeldedaten vom Ursprungsserver.
  • Sie müssen keine Fernaufrufe von Benutzerregistrys durchführen, da der Anwendungsserver das Subject aus den serialisierten Daten erneut generieren kann. Ohne diese Funktion führt der Anwendungsserver möglicherweise fünf bis sechs separate Fernaufrufe durch.
Abbildung 1. Horizontale WeitergabeHorizontale Weitergabe

Auswirkung auf die Leistung bei horizontaler Weitergabe

Die Auswirkungen des DRS- bzw. JMX-Fernaufrufs auf die Leistung hängen von Ihrer Umgebung ab. Der DRS- bzw. JMX-Fernaufruf wird zum Abrufen der ursprünglichen Anmeldeattribute verwendet. Durch die horizontale Weitergabe wird die Anzahl der Fernaufrufe der Benutzerregistry in den Fällen, in denen die Aufrufe die größten Leistungsprobleme für eine Anwendung verursachen, stark verringert. Die Entserialisierung dieser Objekte kann ebenfalls Leistungseinbußen verursachen, diese Einbußen sind aber wahrscheinlich geringer als diejenigen, die durch Fernaufrufe der Benutzerregistry zu erwarten sind. Es wird empfohlen, dass Sie Ihre Umgebung mit aktivierter und inaktivierter horizontaler Weitergabe testen. In den Fällen, in denen Sie die horizontale Weitergabe verwenden müssen, um ursprüngliche Anmeldeattribute beizubehalten, müssen Sie testen, ob DRS oder JMX eine bessere Leistung in Ihrer Umgebung bereitstellt. Normalerweise wird empfohlen, DRS zwecks Leistung und Failover zu konfigurieren. Da DRS alle Server in derselben Replikationsdomäne darüber informiert, ob auf die Server zugegriffen wird, treten möglicherweise Leistungseinbußen auf, wenn zu viele Server sich in derselben Replikationsdomäne befinden. In diesem Fall müssen Sie entweder die Anzahl der Server in der Replikationsdomäne verringern oder die Server in einer DRS-Replikationsdomäne nicht konfigurieren. Die zuletzt genannte Vorgehensweise bewirkt, dass ein JMX-Fernaufruf die Attribute, falls erforderlich, abruft, was insgesamt möglicherweise der schnellere Weg ist.

Sicherheitscache (WSSecureMap)

In Abbildung 1 ist der Sicherheitscache (WSSecureMap) der dynamische Cache, der für die Weitergabe von Sicherheitsattributen verwendet wird. Der Cache WSSecureMap speichert Sicherheitsattribute, die verwendet werden, um die Benutzerberechtigungsnachweise neu zu erstellen. Er wächst mit der Anzahl der Benutzer, die sich anmelden. Die Lebensdauer von WSSecureMap entspricht standardmäßig dem LTPA-Token-Zeitlimit. Dies bedeutet, dass die WSSecureMap-Cacheeinträge freigegeben werden, wenn sich Benutzer abmelden. Das Verwendungsmuster für WSSecureMap ist regelgerecht.

Die Größe des WSSecureMap-Cache wird in der Administrationskonsole festgelegt (Sicherheit > Globale Sicherheit > Angepasste Eigenschaften > Neu). Mit den Einstellungen für com.ibm.ws.security.WSSecureMapInitAtStartup und com.ibm.ws.security.WSSecureMapSize definieren Sie, wie der Cache verwendet wird.

Downstream-Weitergabe

Bei der Downstream-Weitergabe wird ein Subject auf dem Front-End-Web-Server generiert. Dazu wird eine Anmeldung durchgeführt, die entweder auf einer Benutzerregistry oder auf der Weitergabe von Attributen basiert. WebSphere Application Server gibt die Sicherheitsdaten für Enterprise-Bean-Aufrufe in einem Downstream-Prozess weiter, wenn die eingehende und die abgehende RMI-Weitergabe (Remote Method Invocation) aktiviert ist.

Vorteile der Weitergabe von Sicherheitsattributen

Die Funktion von WebSphere Application Server für die Weitergabe von Sicherheitsattributen hat die folgenden Vorzüge:

  • Ermöglicht WebSphere Application Server, die Sicherheitsattributdaten für die Authentifizierung und Berechtigung zu verwenden. Wenn Sie Sicherheitsattribute weitergeben, ist es möglicherweise nicht mehr erforderlich, während eines Aufrufs bei jedem fernen Hop die Benutzerregistry aufzurufen. Frühere Versionen von WebSphere Application Server haben nur denselben Benutzernamen des authentifizierten Benutzers weitergegeben, jedoch andere Sicherheitsattributdaten ignoriert, die mit Fernaufrufen von Benutzerregistrys in einem Downstream-Prozess erneut generiert werden mussten. Die Vorzüge dieser neuen Funktion werden im folgenden Beispiel deutlich:

    In Vorgänger-Releases konnten Sie einen Reverse Proxy Server (RPSS), z. B. WebSEAL, verwenden, um den Benutzer zu authentifizieren, Gruppendaten und andere Sicherheitsattribute zu sammeln. Wie zuvor erläutert, hat WebSphere Application Server die Identität des authentifizierten Benutzers akzeptiert, die zusätzlichen Sicherheitsattributdaten jedoch ignoriert. Zum Erstellen des JAAS-Subjects (Java Authentication and Authorization Service), das die benötigten WSCredential- und WSPrincipal-Objekte enthält, führt WebSphere Application Server 5 bis 6 Aufrufe der Benutzerregistry durch. Das WSCredential-Objekt enthält verschiedene Sicherheitsinformationen, die für die Berechtigung einer Java EE-Ressource erforderlich sind. Das WSPrincipal-Objekt enthält den Realmnamen und den Benutzer, der den Principal für das Subject enthält.

    Im aktuellen Release von Application Server können vom Reverse Proxy abgerufene Daten von WebSphere Application Server verwendet und in einem Downstream-Prozess ohne zusätzliche Aufrufe der Benutzerregistry an andere Serverressourcen weitergegeben werden. Das Speichern der Sicherheitsattributdaten bietet Ihnen die Möglichkeit, Serverressourcen durch entsprechende Berechtigungs- und Trustentscheidungen wirksam zu schützen. Benutzerschalter, die aufgrund von Java EE-RunAs-Konfigurationen ausgeführt werden, führen nicht dazu, dass der Anwendungsserver die Daten zum ursprünglichen aufrufenden Prozess (Caller) verliert. Diese Daten sind im PropagationToken, das sich im aktuellen Thread befindet, gespeichert.

  • Ermöglicht anderen Anbietern, angepasste Token zu integrieren. Die Tokenschnittstelle enthält eine getBytes()-Methode, die der Tokenimplementierung erlaubt, angepasste Serialisierungs- und/oder Verschlüsselungsmethoden zu definieren.
  • Ermöglicht die Verwendung mehrerer Token desselben Typs in einem von verschiedenen Providern erstellten Subject. WebSphere Application Server kann verschiedene Token für denselben Zweck bearbeiten. Beispielsweise kann das Subject verschiedene Berechtigungstoken enthalten und jedes Token kann spezifische Berechtigungsattribute besitzen, die von verschiedenen Providern generiert werden.
  • Ermöglicht in den Fällen, in denen dynamische Attribute den Kontext einer Benutzer-ID ändern können, für jeden Tokentyp, der verwendet wird, um eine eindeutigere Subject-ID als lediglich den Benutzernamen zu formulieren, die Verwendung einer eindeutigen ID. Der Tokentyp besitzt eine Methode "getUniqueId()", die verwendet wird, um eine eindeutige Zeichenfolge für die Zwischenspeicherung zurückzugeben. Möglicherweise müssen Sie eine Positions-ID weitergeben, um die Position, an der der Benutzer sich am System angemeldet hat, anzuzeigen. Diese Positions-ID kann während der ursprünglichen Anmeldung mit einem Reverse-Proxy-Server oder einer WEB_INBOUND-Anmeldekonfiguration generiert und vor der Serialisierung dem Subject hinzugefügt werden. Andere Attribute können ebenfalls dem Subject hinzugefügt werden und eine eindeutige ID verwenden. Alle eindeutigen IDs müssen hinsichtlich der Eindeutigkeit des gesamten Subject berücksichtigt werden. WebSphere Application Server kann angeben, was an der Information im Subject eindeutig ist. Dadurch kann festgelegt werden, wie später der Zugriff auf das Subject erfolgen soll.

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_secattributeprop
Dateiname:csec_secattributeprop.html