geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <>
Subject Re: WS-Security and Geronimo KeystoreInstance
Date Wed, 18 Oct 2006 22:03:40 GMT
I came with the following interface definition:

As stated by Vamsavardhana, nearly all methods have a char[] storePassword
parameter, which MUST be non-null for editing the keystore (adding keys,
locking / unlocking, removing keys, etc ...).  Other read-only methods
use this parameter the following way:
  1) if a null parameter is provided, it means the call comes from a "service"
    (http ssl factory creation from jetty / tomcat, servicemix, etc ...).  The
    keystore must have been previously unlocked for use and the operation
    will use the stored password to access the keystore
  2) if a non-null parameter is provided, it means the caller is the "console"
     in which case, the operation will be performed using the provided

I have also rewritten the exception handling.  All exceptions now derive
from the KeystoreException, and all methods throw an exception when a
problem arise (instead of just logging it or returning null).

These would allow to clean a bit the keystore portlets which
  * do not report any error
  * mess everything if you provided a wrong password
  * some operations fail if you have not unlocked the keystore for use
     (because some operations use the internal password instead of using
      the one provided by the console).

The only problem left is for accessing the PrivateKey.
I'm not very at ease with the java security check, but I feel
that it could solve the problem better.

On 10/18/06, Vamsavardhana Reddy <> wrote:
> Aaron,
>  I forgot to add that my previous mail is applicable to "read-only" service
> methods like getKeyManager, getCertificate etc.
>  1.  Any edit methods (like add new certificate) will require a non null
> valid keystore password parameter.
>  2.  Method to retrieve privateKey will require the key-password parameter.
>  Vamsi
> On 10/19/06, Aaron Mulder <> wrote:
> > 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"?
> >
> > Thanks,
> >      Aaron
> >

Guillaume Nodet

View raw message