geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: WS-Security and Geronimo KeystoreInstance
Date Wed, 18 Oct 2006 20:43:44 GMT
On 10/18/06, Vamsavardhana Reddy <> wrote:
> David,
>  Myself and Guillaume had a discussion on IRC and come up with a conclusion
> that all methods should require storePassword.  If the null is passed as
> storePassword and the keystore is not unlocked for "use" the methods will
> throw an Exception.  Otherwise the method will use the storePassword
> provided as parameter.  Keystores portlet will be supplying the
> storePassword in the method calls and others (like HTTPSConnector) will only
> be able to use the methods if the keystore is unlocked for "use".
>  Have me missed something?

If a keystore is unlocked for "use", I didn't think that should give
any user a free pass to edit the keystore.  For example, if I
configure SSL and the keystore, should you as a random application
user be able to do a GBean query to fetch the keystore manager, and
then invoke methods to, say, export the private key, or add new
different private keys and delete the current one, and stuff like
that?  I think that's bad -- I'd be against any solution like that.
It sounds like you're saying that once the keystore is unlocked
anybody has full access just by setting the password to null.

If there is any way to cleanly separate the methods needed by server
components at runtime from methods that let users inspect and
manipulate the contents of the keystore, that would be ideal.  It
worked for SSL where we could cough up a socket factory for server
callers rather than producing the actual key material, but it sounds
like this is not going to work for ServiceMix.  Maybe we can create a
similar wrapper around the calls needed by ServiceMix where our
wrapper class handles the key material and never exposes it directly
to callers, and that's what could be unlocked for "use"?


View raw message