Support overriding KeyStore alias for signature so that it can be different
than user name used for UsernameToken
-----------------------------------------------------------------------------------------------------------------
Key: WSS-194
URL: https://issues.apache.org/jira/browse/WSS-194
Project: WSS4J
Issue Type: New Feature
Components: WSS4J Handlers
Affects Versions: 1.5.8
Reporter: Aleksander Adamowski
Assignee: Ruchith Udayanga Fernando
Attachments: wss4j-signature_keystore_alias.patch
Currently, when signing a message, the KeyStore alias lookup is performed using
the user name from userInfo (which is set in SignatureAction and comes from
request data).
This way, the alias in the KeyStore cannot be different from the user name used
for UsernameToken authentication.
Some usage scenarios cannot make such an assumption.
E.g. a common configuration is to prompt the user for the username and
password, but the KeyStore is distributed with the client application and
contains a static entry with a static password for the signing keypair and
certificate, and will be used by multiple users (the WS signature comes from
the client application, not an individual user). The KeyStore, and signing
certificate alias and password is part of application's configuration.
The password for UsernameToken can be differentiated using a proper password
callback handler (since the callback it receives specifies in the "usage"
property what is the password needed for - e.g.
WSPasswordCallback.USERNAME_TOKEN or WSPasswordCallback.SIGNATURE).
A user found a workaround for this problem for Apache Axis:
http://www.nabble.com/Signature-Alias-vs.-Username-Token-User-td21334511.html
However, there's no simple method for differentiating the user name used by the
Signature and UsernameToken actions if WSS4J is not used from Axis, but e.g.
CXF.
I've implemented a simple solution by introducing a new handler configuration
property - SIG_KEYSTORE_ALIAS - which allows to override the KeyStore alias for
the Signature action.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
