geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: WS-Security and Geronimo KeystoreInstance
Date Wed, 18 Oct 2006 20:12:25 GMT

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