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.
<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.
<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>
<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.
<wsSecurityClient id="default"
ws-security.username="alice"
ws-security.callback-handler="com.acme.PasswordCallback"
</wsSecurityClient>
- 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
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.
<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
<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.
<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>
<wsse:UsernameToken wsse:Id="...">
<wsse:Username>...</wsse:Username>
<wsse11:Salt>...</wsse11:Salt>
<wsse11:Iteration>...</wsse11:Iteration>
</wsse:UsernameToken>