geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vamsavardhana Reddy" <c1vams...@gmail.com>
Subject Re: WS-Security and Geronimo KeystoreInstance
Date Wed, 18 Oct 2006 20:53:48 GMT
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
>

Mime
View raw message