WSPasswordCallback defines a set of integers which correspond to usage instructions for the CallbackHandler. In WSS4J 1.5.x they were often used in an inconsistent or ad hoc manner, leading to confusion for users. The following integers have been deprecated in WSS4J 1.6 and are no longer used internally by WSS4J:
- WSPasswordCallback.KEY_NAME
- WSPasswordCallback.USERNAME_TOKEN_UNKNOWN
- WSPasswordCallback.ENCRYPTED_KEY_TOKEN
- WSPasswordCallback.DECRYPT - DECRYPT usage is used when the calling code needs a password to get the private key of this identifier (alias) from a keystore. This is only used for the inbound case of decrypting a session (symmetric) key, and not for the case of getting a private key to sign the message. The CallbackHandler must set the password via the setPassword(String) method.
- WSPasswordCallback.USERNAME_TOKEN - USERNAME_TOKEN usage is used to obtain a password for either creating a Username Token, or for validating it. It is also used for the case of deriving a key from a Username Token. The CallbackHandler must set the password via the setPassword(String) method.
- WSPasswordCallback.SIGNATURE - SIGNATURE usage is used on the outbound side only, to get a password to get the private key of this identifier (alias) from a keystore. The CallbackHandler must set the password via the setPassword(String) method.
- WSPasswordCallback.SECURITY_CONTEXT_TOKEN - SECURITY_CONTEXT_TOKEN usage is for the case of when we want the CallbackHandler to supply the key associated with a SecurityContextToken. The CallbackHandler must set the key via the setKey(byte[]) method.
- WSPasswordCallback.CUSTOM_TOKEN - CUSTOM_TOKEN usage is used for the case that we want the CallbackHandler to supply a token as a DOM Element. For example, this is used for the case of a reference to a SAML Assertion or Security Context Token that is not in the message. The CallbackHandler must set the token via the setCustomToken(Element) method.
- WSPasswordCallback.SECRET_KEY - SECRET_KEY usage is used for the case that we want to obtain a secret key for encryption or signature on the outbound side, or for decryption or verification on the inbound side. The CallbackHandler must set the key via the setKey(byte[]) method.
SECRET_KEY is a new identifier for finding secret keys. It replaces the occasionally incorrect use of CUSTOM_TOKEN, as well as KEY_NAME and ENCRYPTED_KEY_TOKEN.
Hi, thank you for this blog. I am wondering if you could help me with one question. According to http://wso2.org/library/3733 one of the deprecated tokens, USERNAME_TOKEN_UNKNOWN, is meant to be used for the validation of a token. But now it is deprecated in 1.6, yet there doesn't seem to be a replacement for it, I am just wondering what would be the correct usage constant to use for token validation? Thanks!
ReplyDeleteSee this blog post for an explanation:
ReplyDeletehttp://coheigea.blogspot.com/2011/02/usernametoken-processing-changes-in.html
Colm.
Hi,
ReplyDeleteIs there any place with a tutorial or resume about how to upgrade from wss4j 1.5 to 1.6 in an axis 1.4 environtment?
The elimination of WSDoAllSender is a pain in the back and I am unable to find any documentation about 1.6 version. In Apache WSS4J project page it only shows version 2 documentation.
Thank you very much in advance.
I don't think WSS4J 1.6.x is compatible with Axis 1.4. Best place to ask is on the Axis users list.
DeleteColm.
This comment has been removed by the author.
DeleteThank you.
DeleteActually, my problem is that I do need to sign a SOAP message, and I'm able to do it, but the server who receives the request needs the
ds:KeyInfo
ds:X509Data
ds:X509Certificate
tag structure.
I thought that wss4j 1.6 version does that. Or may be the 1.5 version also does that and I don't know how.
Thank you.
This comment has been removed by the author.
ReplyDelete