geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: WS-Security and Geronimo KeystoreInstance
Date Wed, 18 Oct 2006 23:06:45 GMT
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