Konsumententoken zum Schutz der Nachrichtenauthentizität validieren

Die Informationen zum Tokenkonsumenten werden auf Konsumentenseite verwendet, um das Sicherheitstoken einzubinden und zu validieren. Benutzernamenstoken, X509-Token und LTPA-Token werden standardmäßig für die Nachrichtenauthentizität verwendet.

Vorbereitende Schritte

Für die Tokenverarbeitung und die Plug-in-Tokenarchitektur in der Laufzeitumgebung von Web Services Security werden dieselbe Sicherheitstokenschnittstelle und das JAAS-Anmeldmodul (Java™ Authentication and Authorization Service) aus den WSS-Anwendungsprogrammierschnittstellen (Web Services Security) wiederverwendet. In der WSS-API und der WSS-SPI in der Laufzeitumgebung von Web Services Security kann dieselbe Implementierung für die Tokenerstellung und -validierung verwendet werden.

Einschränkung: Die Schnittstelle com.ibm.wsspi.wssecurity.token.TokenConsumingComponent wird für JAX-WS-Web-Services nicht verwendet. Wenn Sie JAX-RPC-Web-Services verwenden, ist diese Schnittstelle weiterhin gültig.

Beachten Sie, dass das Element "KeyName" nicht unterstützt wird, weil keine Zusicherung der KeyName-Richtlinie in der aktuellen OASIS-Entwurfsspezifikation für Web Services Security definiert ist.

Informationen zu diesem Vorgang

Der JAAS-Callback-Handler (CallbackHandler) und das JAAS-Anmeldemodul (LoginModule) sind für die Erstellung des Sicherheitstokens auf Generatorseite und die Validierung (Authentifizierung) des Sicherheitstokens auf Konsumentenseite verantwortlich.

Auf Generatorseite werden Benutzernamenstoken beispielsweise vom JAAS-Anmeldemodul erstellt und Authentifizierungdaten vom JAAS-Callback-Handler übergeben. Das JAAS-Anmeldemodul erstellt das Username-SecurityToken-Objekt und übergibt es an die Laufzeitumgebung von Web Services Security.

Anschließend wird auf Konsumentenseite das XML-Format des Benutzernamenstokens zur Validierung oder Authentifizierung an das JAAS-Anmeldemodul übergeben, und der JAAS-Callback-Handler wird verwendet, um die Authentifizierungsdaten von der Laufzeitumgebung von Web Services Security an das Anmeldemodul zu übergeben. Nach der Authentifizierung des Tokens wird ein Username-SecurityToken-Objekt erstellt und an die Laufzeitumgebung von Web Services Security übergeben.

Anmerkung: WebSphere Application Server unterstützt kein stapelbares Anmeldemodul für die WAS-Standardanmeldemodulimplementierung, womit das Hinzufügen des Anmeldemoduls vor oder nach der Implementierung des Anmeldemoduls in WebSphere Application Server gemeint ist. Wenn Sie Anmeldemodulimplementierungen stapeln möchten, müssen Sie die erforderlichen Anmeldemodule entwickeln, weil es keine Standardimplementierung gibt.
Das von WebSphere Application Server bereitgestellte Paket "com.ibm.websphere.wssecurity.wssapi.token" unterstützt die folgenden Klassen:
  • Sicherheitstoken (SecurityTokenImpl)
  • Binäre Sicherheitstoken (BinarySecurityTokenImpl)
Außerdem stellt WebSphere Application Server die folgenden vorkonfigurierten untergeordneten Schnittstellen für Sicherheitstoken bereit:
  • Abgeleitetes Schlüsseltoken
  • Sicherheitskontexttoken (SCT)
  • Benutzernamenstoken
  • LTPA-Tokenweitergabe
  • LTPA-Token
  • X509PKCS7-Token
  • X509PKIPath-Token
  • X509v3-Token
  • Token des Typs Kerberos v5

Das Benutzernamenstoken, das X.509-Token und das LTPA-Token werden standardmäßig für die Nachrichtenauthentizität verwendet. Das abgeleitete Schlüsseltoken und das X.509-Token werden standardmäßig für Signatur und Verschlüsselung verwendet.

Die WSS-API und die WSS-SPI werden nur auf dem Client unterstützt. Um den Sicherheitstokentyp auf der Konsumentenseite anzugeben, können Sie auch Richtliniensätze über die Administrationskonsole konfigurieren. Für die entsprechenden Generatorsicherheitstoken können Sie die WSS-APIs oder Richtliniensätze verwenden.

Die Standardimplementierungen für das Anmeldemodul und den Callback-Handler sind paarweise zu verwenden, d. h. es ist jeweils ein Generator- und ein Konsumentenabschnitt erforderlich. Zur Verwendung der Standardimplementierungen wählen Sie die Generator- und Konsumentensicherheitstoken in einem Paar aus. Wählen Sie z. B. system.wss.generate.x509 im Tokengenerator und system.wss.consume.x509 im Tokenkonsumenten aus, wenn das X.509-Token erforderlich ist.

Verwenden Sie zum Konfigurieren des Sicherheitstokens auf der Konsumentenseite die entsprechende vorkonfigurierte Sicherheitstokenschnittstelle aus den WSS-APIs für die Konsumentenseite, um die folgenden Schritte für die Tokenkonfiguration auszuführen:

Vorgehensweise

  1. wssFactory-Instanz generieren.
  2. wssConsumingContext-Instanz generieren.

    Die Schnittstelle "WSSConsumingContext" speichert die Komponenten für das Konsumieren der Web Services Security (WS-Security), z. B. Prüfung, Entschlüsselung, Sicherheitstoken und Zeitmarke. Wenn die Methode "validate()" aufgerufen wird, werden alle diese Komponenten validiert.

  3. Komponenten auf Konsumentenseite erstellen, z. B. WSSVerification und WSSDecryption-Objekte.
  4. JAAS-Konfiguration durch Angabe des Namens der JAAS-Anmeldekonfiguration angeben. Die JAAS-Konfiguration (Java Authentication and Authorization Service) gibt den Namen der JAAS-Konfiguration an. Die JAAS-Konfiguration legt fest, wie sich das Token auf der Konsumentenseite anmeldet. Sie dürfen keine der vordefinierten Konfigurationen für System- oder Anwendungsanmeldungen entfernen. Sie können diesen Konfigurationen jedoch Modulklassennamen hinzufügen und die Reihenfolge festlegen, in der WebSphere Application Server die einzelnen Module lädt.
  5. Klassennamen des Tokenkonsumenten angeben. Der Klassenname des Tokenkonsumenten gibt die erforderlichen Informationen für die Generierung des Sicherheitstokens an. Das Benutzernamenstoken, das X.509-Token und das LTPA-Token werden standardmäßig für die Nachrichtenauthentizität verwendet.
  6. Einstellungen für den Callback-Handler durch Angabe eines Klassennamens für den Callback-Handler und Callback-Handler-Schlüssel angeben. Dieser Klassenname ist der Name der Callback-Handler-Implementierungsklasse, die für das Plug-in für das Sicherheitstokenframework verwendet wird.
    WebSphere Application Server stellt die folgenden Standardimplementierungen für Callback-Handler auf der Konsumentenseite bereit:
    com.ibm.websphere.wssecurity.callbackhandler.PropertyCallback
    Diese Klasse ist ein Callback für die Bearbeitung von Name/Wert-Paaren in Elementen in den XMI-Dateien der WS-Security-Konfiguration (Web Services Security).
    ccom.ibm.websphere.wssecurity.callbackhandler.UNTConsumeCallbackHandler
    Diese Klasse ist ein Callback-Handler für das Benutzernamenstoken auf der Konsumentenseite. Diese Instanz wird verwendet, um das WSSConsumingContext-Objekt für die Validierung eines Benutzernamenstokens zu setzen. Sie sollten diese Implementierung nur für einen Java-EE-Anwendungsclient (Java Platform, Enterprise Edition) verwenden.
    com.ibm.websphere.wssecurity.callbackhandler.X509ConsumeCallbackHandler
    Diese Klasse ist ein Callback-Handler, mit dem Sie das X.509-Zertifikat validieren können, das als binäres in den Web-Services-Security-Header einer SOAP-Nachricht auf der Konsumentenseite eingefügt wird. Diese Instanz wird verwendet, um die WSSVerification- und WSSDecryption-Objekte zu generieren und die Objekte im WSSConsumingContext-Objekt so zu definieren, dass binäre X.509-Sicherheitstoken generiert werden. Für diesen Callback-Handler sind ein Keystore und eine Schlüsseldefinition erforderlich. Wenn Sie diese Implementierung verwenden, müssen Sie auf der Generatorseite das Kennwort, den Pfad und den Typ des Keystores angeben.
    com.ibm.websphere.wssecurity.callbackhandler.LTPAConsumeCallbackHandler
    Diese Klasse ist ein Callback-Handler für LTPA-Token (Lightweight Third Party Authentication) auf der Konsumentenseite. Diese Instanz wird verwendet, um die WSSVerification- und WSSDecryption-Objekte für die Validierung eines LTPA-Tokens zu generieren.

    Dieser Callback-Handler wird verwendet, um das LTPA-Sicherheitstoken zu validieren, das in den Web-Services-Security-Header in der SOAP-Nachricht als binäres Sicherheitstoken eingefügt wird. Wenn der Benutzername und das Kennwort jedoch angegeben sind, authentifiziert WebSphere Application Server diese beiden Angaben, um das LTPA-Sicherheitstoken anzufordern, anstatt es vom RunAs-Subjekt anzufordern. Verwenden Sie diesen Callback-Handler nur, wenn der Web-Service für den Anwendungsserver die Rolle eines Clients hat. Sie sollten diesen Callback-Handler nicht für einen Java-EE-Anwendungsclient verwenden. Wenn Sie diese Implementierung verwenden, müssen auf der Generatorseite eine Benutzer-ID und ein Kennwort für die Basisauthentifizierung angegeben worden sein.

    com.ibm.websphere.wssecurity.callbackhandler.KRBTokenConsumeCallbackHandler
    Diese Klasse ist ein Callback-Handler für das Kerberos-v5-Token auf der Konsumentenseite. Diese Instanz wird verwendet, um das WSSConsumingContext-Objekt so zu definieren, dass es Kerberos v5 AP-REQ als binäres Sicherheitstoken konsumiert. Die Instanz wird auch verwendet, um die WSSVerification- und WSSDecryption-Objekte für die Verwendung des Kerberos-Sitzungsschlüssels oder abgeleiteten Schlüssels für die Überprüfung und Entschlüsselung von SOAP-Nachrichten zu generieren.
  7. Wenn ein X.509-Token angegeben ist, werden weitere Tokeninformationen angegeben.
    Tabelle 1. Informationen zu X.509-Token. Verwenden Sie das X.509-Token, um Nachrichten zu authentifizieren.
    Tokeninformationen Beschreibung
    keyStoreRef Der Referenzname des Keystores, der für den Key-Locator verwendet wird.
    keyStorePath Der Keystore-Pfad, über den der Keystore bei Bedarf geladen wird. Es wird empfohlen, für die Angabe des Pfadnamens die Variable ${USER_INSTALL_ROOT} zu verwenden, da diese Variable auf Ihrer Maschine durch den Pfad von WebSphere Application Server ersetzt wird. Dieser Pfad ist erforderlich, wenn Sie die Callback-Handler-Implementierungen vom Typ "X.509-Token" verwenden.
    keyStorePassword Das Kennwort, das verwendet wird, um die Integrität des Keystores zu prüfen, bzw. das Keystore-Kennwort, das für das Entsperren des Keystores und für den Zugriff auf die Keystore-Datei verwendet wird. Der Keystore und seine Konfiguration werden für einige Callback-Handler-Standardimplementierungen verwendet werden, die von WebSphere Application Server bereitgestellt werden.
    keyStoreType Der Keystore-Typ des Keystores, der für den Key-Locator verwendet wird. Diese Auswahl gibt das von der Keystore-Datei verwendete Format an. Die folgenden Werte stehen zur Auswahl:
    JKS
    Geben Sie diese Option an, wenn für den Keystore das JKS-Format (Java Keystore Store) verwendet wird.
    JCEKS
    Geben Sie diese Option an, wenn die Java Cryptography Extension im SDK (Software Development Kit) konfiguriert ist. Die Standard-JCE von IBM ist in WebSphere Application Server konfiguriert. Diese Option bietet mit der 3DES-Verschlüsselung einen stärkeren Schutz für gespeicherte private Schlüssel.
    JCERACFKS
    Verwenden Sie JCERACFKS, wenn die Zertifikate in einem SAF-Schlüsselring gespeichert sind (nur z/OS).
    PKCS11KS (PKCS11)
    Geben Sie dieses Format an, wenn Ihr Keystore das Dateiformat PKCS#11 hat. Keystores mit diesem Format können RSA-Schlüssel auf Verschlüsselungshardware oder Chiffrierschlüssel enthalten, die für den Schutz Verschlüsselungshardware verwenden.
    PKCS12KS (PKCS12)
    Verwenden Sie diese Option, wenn Ihr Keystore das Dateiformat PKCS#12 hat.
    alias Der Aliasname des Schlüssels. Der Schlüsselalias wird vom Key-Locator verwendet, um den Schlüssel in der Keystore-Datei zu suchen.
    keyPassword Das Schlüsselkennwort, das für die Wiederherstellung des Schlüssels verwendet wird. Das Kennwort ist für den Zugriff auf das Schlüsselobjekt in der Keystore-Datei erforderlich.
    keyName Der Name des Schlüssels. Für digitale Signaturen wird der Schlüsselname von den Signaturdaten des Anforderungsgenerators oder Antwortkonsumenten verwendet, um den für die digitale Signatur der Nachricht verwendeten Schlüssel zu bestimmen. Für die Verschlüsselung wird der Schlüsselname verwendet, um den für die Verschlüsselung verwendeten Schlüssel zu bestimmen. Der Schlüsselname muss ein vollständig qualifizierter definierter Name (DN) sein. Beispiel: CN=Bob,O=IBM,C=US.
    trustAnchorPath Der Dateipfad, aus dem der Trust-Anchor geladen wird.
    trustAnchorType Der Typ des Trust-Anchor.
    trustAnchorPassword Das Kennwort, das verwendet wird, um die Integrität des Trust-Anchor zu prüfen, oder das Kennwort, das zum Entsperren des Keystores verwendet wird.
    certStores Eine Liste mit Zertifikatsspeichern. Ein Zertifikatssammelspeicher enthält eine Liste nicht anerkannter, temporärer Zertifikate und Zertifikatswiderruflisten (CRLs). Der Zertifikatssammelspeicher wird verwendet, um den Zertifikatspfad eingehender Sicherheitstoken im X.509-Format zu validieren.
    provider Der Sicherheitsprovider.

    Für ein X.509-Token kann Folgendes angegeben werden:

    1. Ohne Keystore.
    2. Mit Trust-Anchor. Ein Trust-Anchor enthält eine Liste der Keystore-Konfigurationen, die Trusted-Root-Zertifikate enthalten. Diese Konfigurationen werden verwendet, um den Zertifikatspfad eingehender Sicherheitstoken im X.509-Format zu validieren. Wenn Sie den Trust-Anchor oder den Zertifikatsspeicher eines anerkannten Zertifikats auswählen, müssen Sie vor dem Definieren des Zertifikatspfads den Zertifikatsspeicher konfigurieren.
    3. Mit einem für den Key-Locator verwendeten Keystore.

      Zuerst müssen Sie die Keystore-Datei erstellt haben, z. B. mit einem Dienstprogramm für Schlüssel. Der Keystore wird verwendet, um das X.509-Zertifikat abzurufen. Dieser Eintrag gibt das Kennwort an, das für den Zugriff auf die Keystore-Datei verwendet wird. Keystore-Objekte in Trust-Anchor enthalten gesicherte Stammzertifikate, die von der API CertPath verwendet werden, um die Vertrauenswürdigkeit einer Zertifizierungskette zu validieren. Die Namen von Trust-Anchor und Gruppenzertifikatsspeicher werden im Zertifikatspfad unter dem Tokenkonsumenten erstellt.

    4. Mit einem für den Key-Locator und den Trust-Anchor verwendeten Keystore.
    5. Mit einer Zuordnung, die Schlüssel/Wert-Paare enthält. Sie können beispielsweise den Namen und den URI des Wertetyps angeben. Der Wertetyp gibt den Namespace-URI für das Konsumententoken an und stellt den Tokentyp dieser Klasse dar:
      ValueType: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
      Gibt ein X.509-Zertifikatstoken an.
      ValueType: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1
      Gibt X.509-Zertifikate in einem PKI-Pfad (Public Key Infrastructure) an. Mit diesem Callback-Handler werden X.509-Zertifikate erstellt, die mit Format PkiPath codiert sind. Das Zertifikat wird als binäres Sicherheitstoken in den Web-Services-Security-Header einer SOAP-Nachricht eingefügt. Für diesen Callback-Handler ist ein Keystore erforderlich. Der Callback-Handler unterstützt keine CRL. Deshalb wird auch kein Zertifikatssammelspeicher benötigt oder verwendet. Wenn Sie diese Implementierung verwenden, müssen Sie in dieser Anzeige ein Keystore-Kennwort, einen Keystore-Pfad und -Typ angeben.
      ValueType: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#PKCS7
      Gibt eine Liste mit X.509-Zertifikaten und Zertifikatswiderruflisten in einem PKCS#7-Format an. Mit diesem Callback-Handler werden X.509-Zertifikate erstellt, die mit Format PKCS#7 codiert sind. Das Zertifikat wird als binäres Sicherheitstoken in den Web-Services-Security-Header einer SOAP-Nachricht eingefügt. Für diesen Callback-Handler ist ein Keystore erforderlich. Sie können im Zertifikatssammelspeicher eine Liste der entzogenen Zertifikate (CRL, Certificate Revocation List) angeben. Die CRL wird mit dem X.509-Zertifikat im Format PKCS#7 codiert. Wenn Sie diese Implementierung verwenden, müssen Sie Kennwort, Pfad und Typ eines Keystores angeben.

      Für einige Token stellt WebSphere Application Server einen vordefinierten lokalen Namen für den Wertetyp bereit. Wenn Sie den folgenden lokalen Namen angeben, müssen Sie keinen Wertetyp-URI angeben:

      ValueType: http://www.ibm.com/websphere/appserver/tokentype/5.0.2
      Für ein LTPA-Token können Sie LTPA als lokalen Namen für den Wertetyp verwenden. Dieser lokale Name bewirkt, dass http://www.ibm.com/websphere/appserver/tokentype/5.0.2 als Wertetyp-URI angegeben wird.
      ValueType: http://www.ibm.com/websphere/appserver/tokentype/5.0.2
      Für die LTPA-Tokenweitergabe können Sie LTPA_PROPAGATION als lokalen Namen für den Wertetyp verwenden. Dieser lokale Name bewirkt, dass http://www.ibm.com/websphere/appserver/tokentype als Wertetyp-URI angegeben wird.
  8. Wenn das Benutzernamenstoken als Klassenname für den Tokenkonsumenten angegeben wird, können die folgenden Tokeninformationen angegeben werden:
    1. Angabe eines Nonce.

      Mit dieser Option können Sie angeben, ob ein Nonce für den Tokenkonsumenten eingefügt wird. Ein "Nonce" ist eine eindeutige verschlüsselte Nummer, die in eine Nachricht eingebettet wird, um wiederholte, unbefugte Hacker-Attacken auf Benutzernamenstoken zu verhindern. Ein Nonce ist nur gültig, wenn "Benutzernamenstoken" der Typ des Tokentyps für Validierung ist, und nur für die Antwortkonsumentenbindung verfügbar.

    2. Schlüsselwort für die Zeitmarke angeben. Diese Option gibt an, ob eine Zeitmarke im Benutzernamenstoken geprüft werden soll. Die Zeitmarke ist nur gültig, wenn Benutzernamenstoken (UsernameToken) der Typ des integrierten Tokens ist.
    3. Zuordnung mit Schlüssel/Wert-Paaren angeben. Sie können beispielsweise den Namen und den URI des Wertetyps angeben. Der Wertetyp gibt den Namespace-URI für das Konsumententoken an und stellt den Tokentyp dieser Klasse dar:
      Wertetyp-URI: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken
      Gibt ein Benutzernamenstoken an.
  9. Wenn ein Kerberos-v5-Token als Tokengeneratorklasse angegeben wird, können die folgenden Tokeninformationen angegeben werden:
    Tokeninformationen Beschreibung Standardwert
    tokenValueType Typ des Kerberos-Tokenwerts im QName-Objekt gemäß Definition in der OASIS-Spezifikation "Kerberos Token Profile v1.1". http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#GSS_Kerberosv5_AP_REQ
    requireDKT Ein boolescher Wert, der angibt, ob ein abgeleiteter Schlüssel für den Nachrichtenschutz verwendet wird. false
    clabel Die Clientbezeichnung für den abgeleiteten Schlüssel. WS-SecureConversation

    Geben Sie null an, um den Standardwert zu verwenden.

    slabel Die Servicebezeichnung für den abgeleiteten Schlüssel. WS-SecureConversation

    Geben Sie null an, um den Standardwert zu verwenden.

    keylen Die Länge des abgeleiteten Schlüssels. 16

    Geben Sie null an, um den Standardwert zu verwenden.

    supportTokenRequireSHA1 Ein boolescher Wert, mit dem angegeben werden kann, dass ein SHA1-Schlüssel in nachfolgenden Anforderungsnachrichten verwendet werden soll, wenn das Kerberos-Token als unterstützendes Token verwendet wird. false

    Der SHA1-Schlüssel wird nur konsumiert, wenn das unterstützende Kerberos-Token geschützt ist. Wenn die Einstellung den Wert "true" hat, wird der SHA1-Schlüssel immer konsumiert.

    decComponent Eine Instanz von WSSDecryption. Setzen Sie decComponent und verComponent auf null, um diese Instanz als erste Komponente für Entschlüsselung oder Prüfung zu initialisieren. Verwenden Sie die initialisierte Komponente anschließend nur im Konstruktor des Callback-Handlers für die zweite Komponente.
    verComponent Eine Instanz von WSSVerfication. Setzen Sie decComponent und verComponent auf null, um diese Instanz als erste Komponente für Entschlüsselung oder Prüfung zu initialisieren. Verwenden Sie die initialisierte Komponente anschließend nur im Konstruktor des Callback-Handlers für die zweite Komponente.
    Weitere Tokenwerttypen sind in der OASIS-Spezifikation "Kerberos Token Profile v1.1" definiert. Geben Sie den Tokenwerttyp als lokalen Namen an. Es ist nicht erforderlich, den Wertetyp-URI für das Kerberos-v5-Token anzugeben.
    • http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ
    • http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ1510
    • http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#GSS_Kerberosv5_AP_REQ1510
    • http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ4120
    • http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#GSS_Kerberosv5_AP_REQ4120
  10. Wenn Secure Conversation für den Nachrichtenschutz verwendet wird, müssen die folgenden Informationen angegeben werden:
    Information Beschreibung
    EncryptionAlgorithm Die Schlüsselgröße.
    cLabel Die Clientbezeichnung, die beim Erstellen des abgeleiteten Schlüssels verwendet wird.
    sLabel Die Serverbezeichnung, die beim Erstellen des abgeleiteten Schlüssels verwendet wird.
  11. Legen Sie die Komponenten im wssConsumingContext-Objekt fest.
  12. Rufen Sie die Methode "wssConsumingContext.process()" auf.

Ergebnisse

Sie haben mit den WSS-APIs den Tokenkonsumenten konfiguriert.

Nächste Schritte

Sie müssen eine ähnliche Tokengeneratorkonfiguration konfigurieren, falls dies noch nicht geschehen ist.

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twbs_configtokenconjaxws
Dateiname:twbs_configtokenconjaxws.html