Web-Service-Clients mit einem Benutzernamenstoken authentifizieren

WebSphere Application Server Liberty unterstützt die OASIS-Spezifikation "Web Services Security UsernameToken Profile 1.1". Die Spezifikation beschreibt, wie ein Web-Service-Client ein Benutzernamenstoken (UsernameToken) zur Identifizierung des Anforderers unter Verwendung eines Benutzernamens und, optional, eines Kennworts oder Kennwortäquivalents bereitstellt, um die Identität beim Web-Service-Provider zu authentifizieren. Die WS-Security-Laufzeit (Web Services Security) in Liberty, die die Richtlinie für den Web-Service-Provider verarbeitet, kann diese Identifikationsinformationen zur Authentifizierung des Benutzers verwenden.

Die Voraussetzung eines Benutzernamenstokens wird in der Definition der Unterstützungstoken in der WS-Security-Richtlinie festgelegt. Sie können ein Benutzernamenstoken (UsernameToken) als vorausgesetztes Token in einer der Unterstützungstokenzusicherungen, einschließlich SupportingTokens, SignedSupportingTokens, SignedEndorsingSupportingTokens, SignedEncryptedSupportingTokens und EncryptedSupportingTokens, hinzufügen.

Das folgende Beispiel zeigt ein Fragment einer Richtlinie, die voraussetzt, dass ein Benutzernamenstoken mit Kennworttext im Sicherheitsheader einer SOAP-Nachricht an einen Web-Service-Provider gesendet wird:
<sp:SupportingTokens>
  <wsp:Policy>
    <sp:UsernameToken
      sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
      <wsp:Policy>
        <sp:WssUsernameToken11 />
      </wsp:Policy>
    </sp:UsernameToken>
  </wsp:Policy>
</sp:SupportingTokens>

Zusätzlich zu der Voraussetzung, dass ein Benutzername oder ein Kennwort bereitgestellt werden muss, können Sie eine Richtlinie konfigurieren, die festlegt, dass eine nonce- und created-Zeitmarke in ein Benutzernamenstoken eingeschlossen werden muss.

Das folgende Beispiel zeigt ein Fragment einer Richtlinie, die voraussetzt, dass ein Benutzernamenstoken mit Kennworttext, nonce und created-Zeitmarke im Sicherheitsheader einer SOAP-Nachricht an einen Web-Service-Provider gesendet wird:
<sp:SupportingTokens>
  <wsp:Policy>
    <sp:UsernameToken
      sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
      <wsp:Policy>
        <sp:WssUsernameToken11 />
        <sp13:Created />
        <sp13:Nonce />
      </wsp:Policy>
    </sp:UsernameToken>
  </wsp:Policy>
</sp:SupportingTokens>
Das folgende Beispiel zeigt ein Fragment einer Richtlinie, die ein Benutzernamenstoken mit Kennwortauszug (Digest) und nicht Kennworttext voraussetzt:
<sp:SupportingTokens>
  <wsp:Policy>
    <sp:UsernameToken
      sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
      <wsp:Policy>
        <sp:WssUsernameToken11 />
        <sp:HashPassword />
      </wsp:Policy>
    </sp:UsernameToken>
  </wsp:Policy>
</sp:SupportingTokens>

Die OASIS-Spezifikation "WS-Security Policy 1.3" enthält weitere Informationen zu nonce, created und verschiedenen Kennwortypen.

Benutzernamen und Kennwort in einem Web-Service-Client angeben

Das Feature "WS-Security" in Liberty stellt bei der Generierung eines Benutzernamenstokens mehrere Methoden für das Anzeigen des Benutzernamens und des Kennworts für eine Clientanwendung bereit. Sie können den Benutzernamen und das Kennwort über das Programm oder in der Datei server.xml setzen.

Ein Client kann ein Benutzernamenstoken mit Benutzernamen und Kennwort aus der Datei server.xml generieren. Die in der Datei server.xml angegebene Kombination aus Benutzername und Kennwort ist die Standardkonfiguration und kann mit dem Inhalt des Anforderungskontextes (RequestContext) für den Aufruf des Client-Web-Service überschrieben werden.

Das folgende Beispiel zeigt eine Standardkonfiguration:
<wsSecurityClient id="default"
    ws-security.username="alice"
    ws-security.callback-handler="com.acme.PasswordCallback"
</wsSecurityClient>
Um ein Benutzernamenstoken mit der über das Programm festgelegten Kombination aus Benutzername/Kennwort zu generieren, können Sie die folgenden CXF-Eigenschaften Anforderungskontext (RequestContext) für den Aufruf des Client-Web-Service festlegen:
  • ws-security.username - Benutzername
  • ws-security.password - Benutzerkennwort, falls ws-security.callback-handler nicht definiert ist
  • ws-security.callback-handler - CallbackHandler-Implementierungsklasse für das Anfordern von Kennwörtern
Das folgende Codebeispiel veranschaulicht die Angabe eines Benutzernamens und eines Kennworts im Anforderungskontext:
Map<String, Object> requestCtx = ((BindingProvider)port).getRequestContext();
requestCtx.put("ws-security.username", "bob_username");
requestCtx.put("ws-security.password", "bob_password");

Benutzernamenstoken in einem Web-Service-Provider konsumieren

Wenn ein Benutzernamenstoken empfangen wird, verwendet WS-Security automatisch die Liberty-Sicherheitsbenutzerregistry, um den Benutzernamen und das Kennwort zu validieren, falls ein Kennwort erforderlich ist. Wenn im Benutzernamenstoken der Kennworttyp PasswordDigest angegeben ist oder abgeleitete Schlüssel verwendet werden, müssen Sie die ws-security.callback-handler-Implementierung eines Kennwort-Callback-Handlers bereitstellen, indem Sie sie in der Datei server.xml konfigurieren. Dieser Callback-Handler muss gültige Kennwörter für alle erwarteten Benutzernamen zurückgeben, sodass die WS-Security-Laufzeit Auszugswerte zum Vergleich mit dem Wert in der SOAP-Nachricht berechnen kann. Nachdem der Vergleich der Auszugswerte erfolgreich abgeschlossen ist, werden der Benutzername und das Kennwort bei der Benutzerregistry überprüft.

Das folgende Beispiel zeigt eine Beispielkonfiguration für den Kennwortauszug in der Datei server.xml:
<wsSecurityProvider id="default"
    ws-security.callback-handler="com.acme.PasswordCallback"
</wsSecurityProvider>

Kennwort-Callback-Handler

Der Kennwort-Callback-Handler wird von WS-Security zum Abrufen eines Benutzerkennworts verwendet. In Liberty muss diese Klasse des Kennwort-Callback-Handlers als Liberty-Feature gepackt werden. Weitere Informationen zum Kennwort-Callback-Handler finden Sie unter Kennwort-Callback-Handler für WS-Security entwickeln.

Weitere Informationen zu Anforderungen und Einschränkungen einer Callback-Handler-Implementierung finden Sie im Artikel Schutz von Web-Services mit einem X.509-Token in dem Abschnitt, der sich mit dem Kennwort-Callback-Handler des privaten Schlüssels befasst.

Benutzernamenstoken in einer SOAP-Nachricht schützen

Wenn ein Benutzernamenstoken in einer Richtlinie angegeben wird, muss der Kennworttyp PasswordText (Kennworttext) sein. Wenn ein Kennwort mit Kennworttext gesendet wird, wird es in der Nachricht unverändert gesendet. Das folgende Beispiel zeigt ein Benutzernamenstoken mit dem Kennworttyp PasswordText:
<UsernameToken>
  <Username>myusername</Username>
  <Password
    Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
    mypassword
  </Password>
</UsernameToken>

Wenn Sie ein Benutzernamenstoken mit dem Kennworttyp PasswordText senden möchten, sollten Sie in Erwägung ziehen, die Nachricht zusätzlich zu schützen, z. B. durch Verwendung des Protokolls HTTPS oder Verschlüsselung des Tokens mit der Richtlinienzusicherung EncryptedSupportingToken. Weitere Informationen darüber, wie die Verwendung des HTTPS-Transports in der Richtlinie vorausgesetzt wird, finden Sie im Artikel Liberty: Richtlinienzusicherungen des WS-Security-HTTPS-Transports.

Ableitung des Schlüssels des Benutzernamenstokens

Die Spezifikation "Web Services Security UsernameToken Profile 1.1" hält Folgendes fest:

Das mit einem Benutzernamen verknüpfte Kennwort kann verwendet werden, um einen gemeinsam genutzten geheimen Schlüssel abzuleiten, zum Schutz der Integrität und Vertraulichkeit von Nachrichteninhalten.

Es muss berücksichtigt werden, dass Kennwörter unterschiedlichen Angriffen ausgesetzt sind, die auch alle abgeleiteten Schlüssel gefährden. Die Schlüsselableitung soll das Risiko, dass die Schlüssel angegriffen werden, so weit wie möglich verringern, letztlich hängt der Erfolg dieser Vorgehensweise aber von der Sicherheit eines Kennworts ab, das von einem Menschen im Gedächtnis behalten und auf einer Standardtastatur eingegeben werden muss.

Es sind zwei weitere Elemente erforderlich, um die Ableitung eines Schlüssels von einem Kennwort zu ermöglichen, <wsse11:Salt> und <wsse11:Iteration>. Diese Werte sind nicht geheim und müssen im Benutzernamenstoken übermittelt werden, wenn die Schlüsselableitung verwendet wird. Das Kennwort darf bei der Schlüsselableitung nicht in das Benutzernamenstoken eingeschlossen werden, da der Empfänger das Kennwort benutzen könnte, um denselben Schlüssel abzuleiten wie der Sender.

Wenn ein Benutzernamenstoken die Schlüsselableitung verwendet, müssen Sie die Implementierung von ws-security.callback-handler eines Kennwort-Callback-Handlers durch Konfiguration in der Datei server.xml bereitstellen.

Das folgende Beispiel zeigt ein Richtlinienfragment für ein Benutzernamenstoken als Schutztoken mit Schlüsselableitung:
<sp:SymmetricBinding>
  <wsp:Policy>
    <sp:ProtectionToken>
      <wsp:Policy>
        <sp:UsernameToken
          sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
          <wsp:Policy>
            <sp:WssUsernameToken10 />
            <sp:RequireDerivedKeys />
          </wsp:Policy>
        </sp:UsernameToken>
      <wsp:Policy>
    </sp:ProtectionToken>
  </wsp:Policy>
</sp:SymmetricBinding>
Das folgende Beispiel zeigt ein Benutzernamenstoken im Sicherheitsheader bei Verwendung der Schlüsselableitung:
<wsse:UsernameToken wsse:Id="...">
  <wsse:Username>...</wsse:Username>
  <wsse11:Salt>...</wsse11:Salt>
  <wsse11:Iteration>...</wsse11:Iteration>
</wsse:UsernameToken>

Symbol das den Typ des Artikels anzeigt. Konzeptartikel



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