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:22:09 GMT
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?

Vamsi

On 10/19/06, David Jencks <david_jencks@yahoo.com> wrote:
>
>
> On Oct 18, 2006, at 11:14 AM, Aaron Mulder wrote:
>
> > 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.
>
> This might get back to the idea I've had for a while that you should
> need some credentials to start the server, and that the server should
> be running as whatever user you started it as.
>
> >
> > 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.
> > :)
>
> I don't see a way to do that either.  I guess I need to understand
> the use cases better.
>
> thanks
> david jencks
>
> >
> > 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