[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wss4j-dev
Subject:    [jira] Closed: (WSS-194) Support overriding KeyStore alias for
From:       "Aleksander Adamowski (JIRA)" <jira () apache ! org>
Date:       2009-06-19 11:17:08
Message-ID: 1118532175.1245410228266.JavaMail.jira () brutus
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/WSS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Aleksander Adamowski closed WSS-194.
------------------------------------

    Resolution: Fixed

OK, I've tested the 1.5.8-SNAPSHOT and all works fine. Closing.

> 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.7
> Reporter: Aleksander Adamowski
> Assignee: Colm O hEigeartaigh
> Fix For: 1.5.8, 1.6
> 
> Attachments: wss4j-signature_keystore_alias.patch, \
> wss4j-signature_keystore_alias2.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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]