Weitergabe von Web-Services-Security-Token

Web Services Security ist in der Lage, Sicherheitstoken im Sicherheitsheader einer SOAP-Nachricht zu senden. Diese Sicherheitstoken können dazu verwendet werden, Nachrichtenabschnitte zu signieren, zu verifizieren, zu verschlüsseln oder zu entschlüsseln. Sicherheitstoken können auch als eigenständige Sicherheitstoken gesendet und als Caller für die Anforderungskonsumenten konfiguriert werden. Die Weitergabe von Web-Services-Security-Token wird verwendet, um diese eigenständigen Sicherheitstoken in einem Element "wsse:BinarySecurityToken" im Sicherheitsheader der SOAP-Nachricht zu senden.

Web Services Security unterstützt die folgenden integrierten Tokentypen:
  • Benutzernamenstoken
  • X.509-Token
  • LTPA-Token (Lightweight Third-Party Authentication)

Sie können Web Services Security für die Verwendung angepasster Sicherheitstoken konfigurieren. Web Services Security verwendet dasselbe Format für die Tokenweitergabe wie das Feature für die Weitergabe von Sicherheitsattributen. Web Services Security kann alle integrierten Sicherheitstokentypen und darüber hinaus angepasste Tokentypen weitergeben, solange diese vom Feature für die Weitergabe von Sicherheitsattributen serialisiert werden können.

Wenn Sie ein Weitergabetoken in eine Tokengenerator oder Tokenkonsumenten konfigurieren, verwenden Sie die folgenden Werte für den Tokentyp-URI und den lokalen Namen:
  • Tokentyp-URI: http://www.ibm.com/websphere/appserver/tokentype
  • Lokaler Name für Tokentyp: LTPA_PROPAGATION

Wenn ein Weitergabetoken generiert wird, erfasst Web Services Security alle serialisierbaren Sicherheitstoken im RunAs-Subject-Objekt für den aktuellen Thread und serialisiert die Sicherheitstoken in einem Token "wsse:BinarySecurityToken". Um ein RunAs-Subject-Objekt und die Berechtigungsnachweise zu haben, die im aktuellen Thread erforderlich sind, muss die JAAS-Anmeldung im aktuellen Thread stattfinden, damit ein Weitergabetoken erstellt werden kann.

Unter normalen Umständen wird die JAAS-Anmeldung (Java Authentication and Authorization Service) für einen Service-Provider erreicht, indem ein definierter Caller-Abschnitt für das eingehende Token in die WS-Security-Konfiguration eingeschlossen wird. Für einen Web-Service-Client wird die JAAS-Anmeldung erreicht, indem die HTTP-Basisauthentifizierung konfiguriert wird.

Es gibt zwei gängige Verwendungszwecke für ein Weitergabetoken:
  • Ein Client in einem gesicherten Service gibt die serialisierbaren Sicherheitstoken und Berechtigungsnachweise aus dem RunAs-Subject-Objekt an einen nachgeschalteten Server weiter.
  • Ein serverbasierter Client, der im Web-Container durch HTTP-Basisauthentifizierung gesichert ist, kann ein Weitergabetoken verwenden.

    Für einen serverbasierten Client ist der mit Weitergabetoken verbundene Aufwand nicht erforderlich, da nur die Identität und nicht der vollständige Satz an Berechtigungsnachweisen erforderlich ist. Wenn die Clientanwendung jedoch Änderungen an dem Subject-Objekt vornimmt, nachdem sie vom Web-Container aufgerufen wurde, kann die Verwendung eines Weitergabetoken angemessen sein. Ist nur ein Identitätstoken erforderlich, kann ein herkömmliches LTPA-Token ausreichend sein. Sie können dieses LTPA-Token aus dem RunAs-Subject-Objekt generieren, das von der JAAS-Anmeldung erstellt wird.

Wichtig: Damit der Empfänger des LTPA-Weitergabetokens die Berechtigungsnachweise, die ihm im Weitergabetoken gesendet werden, ordnungsgemäß nutzt, müssen Sie einen Caller-Abschnitt für das Token in der WS-Security-Konfiguration auf der Empfängerseite konfigurieren und definieren.

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=cwbs_securitytokenpropagationwbs
Dateiname:cwbs_securitytokenpropagationwbs.html