Assuming you are signing the UsernameToken, you'd want a nonce in the
username token to thwart replay attacks.
Note that the WSS4J runtime does not support nonce caching or
detection or replayed requests, so you'd have to implement this,
yourself.
Obviously, you'd also need to sign and encrypt the message (and
response, likely) in order to get the same cryptographic level of
protection as you'd otherwise get from SSL. I can't think of a case
where you'd want to sign and encrypt the token, only, and not the
message, but I haven't given it much thought, either.
In general, though, if you're using a transport protocol that supports
SSL (e.g., HTTP), you're better off using it, because you'd then
benefit from the symmetric key negotiated in the SSL handshake (hence
getting far better performance). Also, if you're bothering to use a
private key and cert on the client side to sign the message, you can
get an added level of protection by using client authentication,
through the SSL protocol. And if you're doing that, the motivation
for using a username and password diminishes. (Though if you do use a
username and password, even with SSL client authentication, you'll
likely still want to use a nonce to thwart replay; it entirely depends
on your trust model, at the server side.)
Had to review some of this with the Iona security folks (Colm, Donal
Arundel, Eamonn Dwyer); thanks to them for setting me straight on this.
-Fred
On Jul 3, 2008, at 8:36 AM, Glen Mazza wrote:
Thanks, here's another question. If I'm using the UsernameToken
profile, and
I sign and encrypt the message, is it recommended to also use SSL on
the
transport layer, or would that be redundant? I would guess the
answer is to
use SSL but *not* basic authentication, because the BA part is more
or less
the same as provided by the username token information.
Glen
Robert Wierschke-2 wrote:
Hi,
when you additionally sign the SOAP message the recipient can be
sure that
the message was not altered in transit. This cannot be achieved
with just
adding a UsernameToken.
regards
robert
2008/6/23 Glen Mazza <[EMAIL PROTECTED]>:
Hello, I have an architectural question about using UsernameTokens
(which
I'm
trying to do with CXF, which of course uses WSS4J behind the
scenes). If
we
are using the UsernameToken profile, I can see why we need to
encrypt the
message with the server's public key (for confidentiality), but am
unsure
if
we need to also sign the message with the client's private key.
Is it
redundant with UsernameToken profile to also sign the SOAP
request? My
first guess, is that by definition, one is using Usernames and
Passwords
for
authentication, and hence would not need signing of the message as
well,
but
am unsure here.
Thanks,
Glen
--
View this message in context:
http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
Sent from the WSS4J mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18258267.html
Sent from the WSS4J mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
