You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Guillaume Nodet <gn...@gmail.com> on 2006/10/18 14:51:16 UTC
WS-Security and Geronimo KeystoreInstance
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
Re: WS-Security and Geronimo KeystoreInstance
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
Guillaume,
There should not be any problem in providing these methods without requiring
a keystore password. java.security.KeyStore.load() allows a Keystore file
to be loaded without even a keystore password. This method will not accept
a wrong password, but will accept null as the keystore password parameter.
keypassword will be required for retrieving any private-key.
Vamsi
On 10/18/06, Vamsavardhana Reddy <c1...@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
> >
>
>
Re: WS-Security and Geronimo KeystoreInstance
Posted by Guillaume Nodet <gn...@gmail.com>.
I have raised a JIRA: http://issues.apache.org/jira/browse/GERONIMO-2504
Any objections to me committing this in ?
Well, actually, i will need help, as there is a very small patch to openejb
and I do not have karma ...
On 10/19/06, Guillaume Nodet <gn...@gmail.com> wrote:
> I came with the following interface definition:
> http://pastebin.ca/208852
>
> As stated by Vamsavardhana, nearly all methods have a char[] storePassword
> parameter, which MUST be non-null for editing the keystore (adding keys,
> locking / unlocking, removing keys, etc ...). Other read-only methods
> use this parameter the following way:
> 1) if a null parameter is provided, it means the call comes from a "service"
> (http ssl factory creation from jetty / tomcat, servicemix, etc ...). The
> keystore must have been previously unlocked for use and the operation
> will use the stored password to access the keystore
> 2) if a non-null parameter is provided, it means the caller is the "console"
> in which case, the operation will be performed using the provided
> password.
>
> I have also rewritten the exception handling. All exceptions now derive
> from the KeystoreException, and all methods throw an exception when a
> problem arise (instead of just logging it or returning null).
>
> These would allow to clean a bit the keystore portlets which
> * do not report any error
> * mess everything if you provided a wrong password
> * some operations fail if you have not unlocked the keystore for use
> (because some operations use the internal password instead of using
> the one provided by the console).
>
> The only problem left is for accessing the PrivateKey.
> I'm not very at ease with the java security check, but I feel
> that it could solve the problem better.
>
> On 10/18/06, Vamsavardhana Reddy <c1...@gmail.com> wrote:
> > Aaron,
> >
> > I forgot to add that my previous mail is applicable to "read-only" service
> > methods like getKeyManager, getCertificate etc.
> >
> > 1. Any edit methods (like add new certificate) will require a non null
> > valid keystore password parameter.
> > 2. Method to retrieve privateKey will require the key-password parameter.
> >
> > Vamsi
> >
> >
> > On 10/19/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> > > On 10/18/06, Vamsavardhana Reddy <c1...@gmail.com> wrote:
> > > > 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?
> > >
> > > If a keystore is unlocked for "use", I didn't think that should give
> > > any user a free pass to edit the keystore. For example, if I
> > > configure SSL and the keystore, should you as a random application
> > > user be able to do a GBean query to fetch the keystore manager, and
> > > then invoke methods to, say, export the private key, or add new
> > > different private keys and delete the current one, and stuff like
> > > that? I think that's bad -- I'd be against any solution like that.
> > > It sounds like you're saying that once the keystore is unlocked
> > > anybody has full access just by setting the password to null.
> > >
> > > If there is any way to cleanly separate the methods needed by server
> > > components at runtime from methods that let users inspect and
> > > manipulate the contents of the keystore, that would be ideal. It
> > > worked for SSL where we could cough up a socket factory for server
> > > callers rather than producing the actual key material, but it sounds
> > > like this is not going to work for ServiceMix. Maybe we can create a
> > > similar wrapper around the calls needed by ServiceMix where our
> > > wrapper class handles the key material and never exposes it directly
> > > to callers, and that's what could be unlocked for "use"?
> > >
> > > Thanks,
> > > Aaron
> > >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
--
Cheers,
Guillaume Nodet
Re: WS-Security and Geronimo KeystoreInstance
Posted by Guillaume Nodet <gn...@gmail.com>.
I came with the following interface definition:
http://pastebin.ca/208852
As stated by Vamsavardhana, nearly all methods have a char[] storePassword
parameter, which MUST be non-null for editing the keystore (adding keys,
locking / unlocking, removing keys, etc ...). Other read-only methods
use this parameter the following way:
1) if a null parameter is provided, it means the call comes from a "service"
(http ssl factory creation from jetty / tomcat, servicemix, etc ...). The
keystore must have been previously unlocked for use and the operation
will use the stored password to access the keystore
2) if a non-null parameter is provided, it means the caller is the "console"
in which case, the operation will be performed using the provided
password.
I have also rewritten the exception handling. All exceptions now derive
from the KeystoreException, and all methods throw an exception when a
problem arise (instead of just logging it or returning null).
These would allow to clean a bit the keystore portlets which
* do not report any error
* mess everything if you provided a wrong password
* some operations fail if you have not unlocked the keystore for use
(because some operations use the internal password instead of using
the one provided by the console).
The only problem left is for accessing the PrivateKey.
I'm not very at ease with the java security check, but I feel
that it could solve the problem better.
On 10/18/06, Vamsavardhana Reddy <c1...@gmail.com> wrote:
> Aaron,
>
> I forgot to add that my previous mail is applicable to "read-only" service
> methods like getKeyManager, getCertificate etc.
>
> 1. Any edit methods (like add new certificate) will require a non null
> valid keystore password parameter.
> 2. Method to retrieve privateKey will require the key-password parameter.
>
> Vamsi
>
>
> On 10/19/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> > On 10/18/06, Vamsavardhana Reddy <c1...@gmail.com> wrote:
> > > 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?
> >
> > If a keystore is unlocked for "use", I didn't think that should give
> > any user a free pass to edit the keystore. For example, if I
> > configure SSL and the keystore, should you as a random application
> > user be able to do a GBean query to fetch the keystore manager, and
> > then invoke methods to, say, export the private key, or add new
> > different private keys and delete the current one, and stuff like
> > that? I think that's bad -- I'd be against any solution like that.
> > It sounds like you're saying that once the keystore is unlocked
> > anybody has full access just by setting the password to null.
> >
> > If there is any way to cleanly separate the methods needed by server
> > components at runtime from methods that let users inspect and
> > manipulate the contents of the keystore, that would be ideal. It
> > worked for SSL where we could cough up a socket factory for server
> > callers rather than producing the actual key material, but it sounds
> > like this is not going to work for ServiceMix. Maybe we can create a
> > similar wrapper around the calls needed by ServiceMix where our
> > wrapper class handles the key material and never exposes it directly
> > to callers, and that's what could be unlocked for "use"?
> >
> > Thanks,
> > Aaron
> >
>
>
--
Cheers,
Guillaume Nodet
Re: WS-Security and Geronimo KeystoreInstance
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
Aaron,
I forgot to add that my previous mail is applicable to "read-only" service
methods like getKeyManager, getCertificate etc.
1. Any edit methods (like add new certificate) will require a non null
valid keystore password parameter.
2. Method to retrieve privateKey will require the key-password parameter.
Vamsi
On 10/19/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>
> On 10/18/06, Vamsavardhana Reddy <c1...@gmail.com> wrote:
> > 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?
>
> If a keystore is unlocked for "use", I didn't think that should give
> any user a free pass to edit the keystore. For example, if I
> configure SSL and the keystore, should you as a random application
> user be able to do a GBean query to fetch the keystore manager, and
> then invoke methods to, say, export the private key, or add new
> different private keys and delete the current one, and stuff like
> that? I think that's bad -- I'd be against any solution like that.
> It sounds like you're saying that once the keystore is unlocked
> anybody has full access just by setting the password to null.
>
> If there is any way to cleanly separate the methods needed by server
> components at runtime from methods that let users inspect and
> manipulate the contents of the keystore, that would be ideal. It
> worked for SSL where we could cough up a socket factory for server
> callers rather than producing the actual key material, but it sounds
> like this is not going to work for ServiceMix. Maybe we can create a
> similar wrapper around the calls needed by ServiceMix where our
> wrapper class handles the key material and never exposes it directly
> to callers, and that's what could be unlocked for "use"?
>
> Thanks,
> Aaron
>
Re: WS-Security and Geronimo KeystoreInstance
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 10/18/06, Vamsavardhana Reddy <c1...@gmail.com> wrote:
> 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?
If a keystore is unlocked for "use", I didn't think that should give
any user a free pass to edit the keystore. For example, if I
configure SSL and the keystore, should you as a random application
user be able to do a GBean query to fetch the keystore manager, and
then invoke methods to, say, export the private key, or add new
different private keys and delete the current one, and stuff like
that? I think that's bad -- I'd be against any solution like that.
It sounds like you're saying that once the keystore is unlocked
anybody has full access just by setting the password to null.
If there is any way to cleanly separate the methods needed by server
components at runtime from methods that let users inspect and
manipulate the contents of the keystore, that would be ideal. It
worked for SSL where we could cough up a socket factory for server
callers rather than producing the actual key material, but it sounds
like this is not going to work for ServiceMix. Maybe we can create a
similar wrapper around the calls needed by ServiceMix where our
wrapper class handles the key material and never exposes it directly
to callers, and that's what could be unlocked for "use"?
Thanks,
Aaron
Re: WS-Security and Geronimo KeystoreInstance
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
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 <da...@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 <da...@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 <c1...@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
> >>
> >>
>
>
Re: WS-Security and Geronimo KeystoreInstance
Posted by David Jencks <da...@yahoo.com>.
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 <da...@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 <c1...@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
>>
>>
Re: WS-Security and Geronimo KeystoreInstance
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@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 <c1...@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
>
>
Re: WS-Security and Geronimo KeystoreInstance
Posted by David Jencks <da...@yahoo.com>.
On Oct 18, 2006, at 5:47 PM, Aaron Mulder wrote:
> 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?
I'm not sure one way or the other. How about this:
-- modify security admin's login info so new password is added to
their private credentials when they login
-- they login as security admin
-- they create the keystore with the new password
-- they can access the new keystore because the password is already
in their subject.
As I said, I'm not sure one way or the other but it seems possible.
I may be arguing that permissions to create a keystore and administer
login config are different from permissions to change the contents of
the keystore.
thanks
david jencks
>
> Thanks,
> Aaron
>
> On 10/18/06, David Jencks <da...@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 <da...@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 <c1...@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
>>
>>
Re: WS-Security and Geronimo KeystoreInstance
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@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 <da...@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 <c1...@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
>
>
Re: WS-Security and Geronimo KeystoreInstance
Posted by David Jencks <da...@yahoo.com>.
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 <da...@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 <c1...@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
Re: WS-Security and Geronimo KeystoreInstance
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <da...@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 <c1...@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
Re: WS-Security and Geronimo KeystoreInstance
Posted by David Jencks <da...@yahoo.com>.
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 <c1...@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
Re: WS-Security and Geronimo KeystoreInstance
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <c1...@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
Re: WS-Security and Geronimo KeystoreInstance
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
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
>