geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: WS-Security and Geronimo KeystoreInstance
Date Wed, 18 Oct 2006 18:14:09 GMT
This is a good conversation to have -- all the options we've
considered previously seem bad in some way or other.

The original goals were:
1) require that a user enter a password to view or manipulate the keystore
2) provide a way for the server to remember the password(s) needed at
runtime, but still respecting #1 (that is, just because the server is
going to use SSL, don't make that a back door for anyone to view/edit
the keystore contents)
3) Don't leave the keystore/key passwords lying around in the
configuration for any callers (Jetty, Tomcat, ServiceMix, etc.)...
with #2, this led to the idea of a keystore "unlocked" for usage by
server components but not for editing, and with #1 led to the separate
"unlocked for editing" bit.

The side effects are kind of muddled usage contracts, and the problem
that if the keystore is fully locked and you still enable SSL then
Geronimo won't start.

It looks like ServiceMix needs pretty extensive access to the keystore
-- more extensive than HTTPS requires even.

I wonder if we should take all the keystore passwords out of the
current API and have a method on the keystore manager where it gets a
password somehow and it gives the caller an unlocked read-only
keystore -- for HTTPS and ServiceMix to use (though we'd still need to
deal with private key passwords?).  Then it could have a separate
method where the caller gives it a password and it gives you an
unlocked read/write keystore -- for the console or other user tools to
use.  We could attempt to restrict access to the two methods
separately, with java.lang.security permissions or whatever.  I guess
that suggests we might need two separate GBeans, one read-only and one
read-write, or something like that.  But we wouldn't want people to be
able to just do a GBean query to get an unlocked keystore.

This still doesn't solve the problem that if the keystore is not
"unlocked" then the server won't start.

I still don't see a great solution.  Maybe the JAAS thing would help
but I don't see how you'd arrange for all the password(s) to be
available at the time the login module was executed (especially since
you can add private keys at runtime).  More discussion would be good.
:)

Thanks,
    Aaron

On 10/18/06, David Jencks <david_jencks@yahoo.com> wrote:
> I'm wondering if we can solve this using JAAS and java security and
> maybe even JACC??
>
> I haven't checked to see if there are already permission checks on
> the keystore methods.  If not, I'd suggest defining an appropriate
> permission and checking it.
>
> For the password I suggest using a LoginModule to attach a private
> credential to the Subject for those authorized to unlock and/or use
> the keystore.  The methods wouldn't need to have the password as a
> parameter, it could be extracted from the Subject.
>
> thanks
> david jencks
>
>
> On Oct 18, 2006, at 7:25 AM, Guillaume Nodet wrote:
>
> > Yeah, I do understand that the key password has to be provided.
> >
> > I see three different ways I could handle the modification:
> >  1) duplicate all methods that are read-only wrt to the keystore
> >     and remove the keystore password (it would use the internal one)
> >  2) remove the keystore password on existing methods
> >  3) assume that when password is null, it uses the internal one
> >
> > The second method can not really be used, because the internal
> > password is only set when the keystore is unlocked for use.
> > The first one is not really clean imho, so I would go for the third
> > option.
> >
> > Btw, I found several problems in the current implementation.
> > Some edition methods do not have a password given, so they
> > use the internal one.  This means that they fail when executing
> > the method on a keystore that is locked for use. This can be
> > reproduce if you try to delete an entry from a locked keystore.
> > It seems to be the case for
> >  * deleteEntry
> >  * importPKCS7Certificate
> >  * generateCSR
> >
> > I will try to fix these, add the new needed methods (with the ones
> > from the GERONIMO-2413 patch) and when the given password
> > is null for read-only method, try to use the internal password.
> >
> > However, I'm wondering if the private key password problem
> > could be solved by using the java.lang.SecurityManager.
> >
> >
> > On 10/18/06, Vamsavardhana Reddy <c1vamsi1c@gmail.com> wrote:
> >> Hi Guillaume,
> >>
> >>  To make the CA Portlet
> >> (http://issues.apache.org/jira/browse/GERONIMO-2413) use a
> >> KeystoreInstance to store its keys, I have added a getCertificate
> >> () and
> >> getPrivateKey() methods.
> >>
> >>  Now coming to the methods you need, except for getPrivateKey(),
> >> it may be
> >> alright to provide methods in KeystoreInstance not to require
> >> keystore
> >> password and these would succeed only if the keystore is unlocked
> >> for "use".
> >>  We should make getPrivateKey() method always require a keyPassword.
> >>
> >>  Vamsi
> >>
> >>
> >> On 10/18/06, Guillaume Nodet < gnodet@gmail.com> wrote:
> >> > I'm trying to look at integrating ServiceMix
> >> > security in Geronimo.  Security in ServiceMix
> >> > has several different aspects, but one of them
> >> > is to be able to encrypt / decrypt, sign messages
> >> > using WS-Security.
> >> > I have defined in ServiceMix a Crypto [1] implementation [2]
> >> > (used by wss4j) on top of a servicemix KeystoreInstance [3]
> >> > (which is quite the same as the Geronimo one).
> >> > The main differences are 2 new methods (getCertificateChain and
> >> > getCertificateAlias) and the fact that the methods do not need
> >> > the keystore password in the parameters.
> >> >
> >> > I had a close look at the Geronimo KeystoreInstance and found
> >> > that nearly all methods are called from the console only.  The only
> >> > real methods used inside the server are when an SSLSocketFactory
> >> > is created.
> >> >
> >> > So I'm wondering what is the best way to go.  I can easily add
> >> the two new
> >> > methods to the KeystoreInstance, but the need to give the password
> >> > for all the calls is a bit disturbing. I need to access the
> >> following
> >> methods:
> >> >   * listPrivateKeys
> >> >   * listTrustCertificates
> >> >   * getCertificate
> >> >   * getCertificateAlias
> >> >   * getCertificateChain
> >> >   * getPrivateKey
> >> >
> >> > Would it be possible from the FileKeystoreInstance to use the
> >> > keystorePassword attribute instead of passing the password
> >> > in the parameters ? I do understand that this may be a security
> >> > hole, as the private keys would be available to everyone inside
> >> > the server, so I'm willing to find a better way ...
> >> >
> >> > Any ideas ?
> >> >
> >> >
> >> > [1]
> >> http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/
> >> components/crypto/Crypto.html
> >> > [2]
> >> http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-
> >> soap/src/main/java/org/apache/servicemix/soap/handlers/security/
> >> KeystoreInstanceCrypto.java?view=markup
> >> > [3]
> >> http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-
> >> core/src/main/java/org/apache/servicemix/jbi/security/keystore/
> >> KeystoreInstance.java?view=markup
> >> >
> >> >
> >> >
> >> > --
> >> > Cheers,
> >> > Guillaume Nodet
> >> >
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
>
>

Mime
View raw message