Re: WS-Security and Geronimo KeystoreInstance

Wed, 18 Oct 2006 16:07:06 -0700

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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

Reply via email to