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 Wed, 18 Oct 2006 22:16:44 GMT
How does the java security mechanism integrates with JAAS and / or JACC ?

Btw, one of the problem I see (but this may not be a problem, I'm not
very proficient in this area), is that the console requires a password
to edit the keystore.  We can not just use the user provided when
logging in the console...

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
>
>


-- 
Cheers,
Guillaume Nodet

Mime
View raw message