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 Thu, 19 Oct 2006 00:47:33 GMT
I still have the problem that you can create a new keystore and add
new password-protected keys to the keystore(s) at runtime.  So I don't
see how at login/startup anything will be able to populate all the
needed passwords.

If you could add passwords to the Subject at runtime and they would be
saved for future runs, that's a possibility -- as in, when you create
or first access a keystore it saves the password you use for future
re-use.  But I'm not sure that's workable.  What do you think?

Thanks,
      Aaron

On 10/18/06, David Jencks <david_jencks@yahoo.com> wrote:
> This is a bit related to GERONIMO-1486,7,8.  I thought simon had
> fleshed these ideas out more than he seems to have.
>
> This is also not necessarily something we can implement quickly.
>
> - when you start the server you need to provide credentials.  You get
> logged in and a Subject is created using a bunch of login modules.
> What the server can do is determined by this Subject.  In particular
> the keystore gbean can look for a private credential in this subject
> to unlock the keystore.  This subject is attached to all threads
> unless they are processing an authenticated j2ee request.
>
> - For any user who can modify the keystore, the credentials necessary
> to allow them to do this are attached to their Subject when they
> login.  When they try to modify the keystore, we look for the
> credentials in their Subject.
>
> - We can also define permissions to modify the keystore, add role>>
> permission mappings, and use JACC to enforce them.  I did something
> similar with  the jetspeed2 portat permissions.
>
> I think these ideas are independent of each other.
>
> While I don't think we'd necessarily want to use the console login
> password as the keystore password, we also don't necessarily want to
> give the keystore password to those who can modify it.  By using JAAS
> to install it as a private credential in the Subject we can hide it
> from the user yet let them modify the keystore.  For our default demo
> console security we'd probably want to have 2 predefined users, one
> who can modify the keystore and one who can't
>
> Hopefully this is a little clearer..... keep asking questions if it
> isn't
>
> thanks
> david jencks
>
> On Oct 18, 2006, at 3:16 PM, Guillaume Nodet wrote:
>
> > 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