geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: WS-Security and Geronimo KeystoreInstance
Date Thu, 19 Oct 2006 15:39:22 GMT
I have raised a JIRA: http://issues.apache.org/jira/browse/GERONIMO-2504
Any objections to me committing this in ?
Well, actually, i will need help, as there is a very small patch to openejb
and I do not have karma ...

On 10/19/06, Guillaume Nodet <gnodet@gmail.com> wrote:
> I came with the following interface definition:
>   http://pastebin.ca/208852
>
> 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
>      password.
>
> 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 <c1vamsi1c@gmail.com> 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 <ammulder@alumni.princeton.edu> wrote:
> > > On 10/18/06, Vamsavardhana Reddy <c1vamsi1c@gmail.com> 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
> > >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>


-- 
Cheers,
Guillaume Nodet

Mime
View raw message