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 Thu, 19 Oct 2006 02:49:06 GMT

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 <david_jencks@yahoo.com> wrote:
>> This is a bit related to GERONIMO-1486,7,8.  I thought simon had
>> fleshed these ideas out more than he seems to have.
>>
>> This is also not necessarily something we can implement quickly.
>>
>> - when you start the server you need to provide credentials.  You get
>> logged in and a Subject is created using a bunch of login modules.
>> What the server can do is determined by this Subject.  In particular
>> the keystore gbean can look for a private credential in this subject
>> to unlock the keystore.  This subject is attached to all threads
>> unless they are processing an authenticated j2ee request.
>>
>> - For any user who can modify the keystore, the credentials necessary
>> to allow them to do this are attached to their Subject when they
>> login.  When they try to modify the keystore, we look for the
>> credentials in their Subject.
>>
>> - We can also define permissions to modify the keystore, add role>>
>> permission mappings, and use JACC to enforce them.  I did something
>> similar with  the jetspeed2 portat permissions.
>>
>> I think these ideas are independent of each other.
>>
>> While I don't think we'd necessarily want to use the console login
>> password as the keystore password, we also don't necessarily want to
>> give the keystore password to those who can modify it.  By using JAAS
>> to install it as a private credential in the Subject we can hide it
>> from the user yet let them modify the keystore.  For our default demo
>> console security we'd probably want to have 2 predefined users, one
>> who can modify the keystore and one who can't
>>
>> Hopefully this is a little clearer..... keep asking questions if it
>> isn't
>>
>> thanks
>> david jencks
>>
>> On Oct 18, 2006, at 3:16 PM, Guillaume Nodet wrote:
>>
>> > How does the java security mechanism integrates with JAAS and / or
>> > JACC ?
>> >
>> > Btw, one of the problem I see (but this may not be a problem,  
>> I'm not
>> > very proficient in this area), is that the console requires a  
>> password
>> > to edit the keystore.  We can not just use the user provided when
>> > logging in the console...
>> >
>> > On 10/18/06, David Jencks <david_jencks@yahoo.com> wrote:
>> >> I'm wondering if we can solve this using JAAS and java security  
>> and
>> >> maybe even JACC??
>> >>
>> >> I haven't checked to see if there are already permission checks on
>> >> the keystore methods.  If not, I'd suggest defining an appropriate
>> >> permission and checking it.
>> >>
>> >> For the password I suggest using a LoginModule to attach a private
>> >> credential to the Subject for those authorized to unlock and/or  
>> use
>> >> the keystore.  The methods wouldn't need to have the password as a
>> >> parameter, it could be extracted from the Subject.
>> >>
>> >> thanks
>> >> david jencks
>> >>
>> >>
>> >> On Oct 18, 2006, at 7:25 AM, Guillaume Nodet wrote:
>> >>
>> >> > Yeah, I do understand that the key password has to be provided.
>> >> >
>> >> > I see three different ways I could handle the modification:
>> >> >  1) duplicate all methods that are read-only wrt to the keystore
>> >> >     and remove the keystore password (it would use the internal
>> >> one)
>> >> >  2) remove the keystore password on existing methods
>> >> >  3) assume that when password is null, it uses the internal one
>> >> >
>> >> > The second method can not really be used, because the internal
>> >> > password is only set when the keystore is unlocked for use.
>> >> > The first one is not really clean imho, so I would go for the  
>> third
>> >> > option.
>> >> >
>> >> > Btw, I found several problems in the current implementation.
>> >> > Some edition methods do not have a password given, so they
>> >> > use the internal one.  This means that they fail when executing
>> >> > the method on a keystore that is locked for use. This can be
>> >> > reproduce if you try to delete an entry from a locked keystore.
>> >> > It seems to be the case for
>> >> >  * deleteEntry
>> >> >  * importPKCS7Certificate
>> >> >  * generateCSR
>> >> >
>> >> > I will try to fix these, add the new needed methods (with the  
>> ones
>> >> > from the GERONIMO-2413 patch) and when the given password
>> >> > is null for read-only method, try to use the internal password.
>> >> >
>> >> > However, I'm wondering if the private key password problem
>> >> > could be solved by using the java.lang.SecurityManager.
>> >> >
>> >> >
>> >> > On 10/18/06, Vamsavardhana Reddy <c1vamsi1c@gmail.com> wrote:
>> >> >> Hi Guillaume,
>> >> >>
>> >> >>  To make the CA Portlet
>> >> >> (http://issues.apache.org/jira/browse/GERONIMO-2413) use a
>> >> >> KeystoreInstance to store its keys, I have added a  
>> getCertificate
>> >> >> () and
>> >> >> getPrivateKey() methods.
>> >> >>
>> >> >>  Now coming to the methods you need, except for getPrivateKey 
>> (),
>> >> >> it may be
>> >> >> alright to provide methods in KeystoreInstance not to require
>> >> >> keystore
>> >> >> password and these would succeed only if the keystore is  
>> unlocked
>> >> >> for "use".
>> >> >>  We should make getPrivateKey() method always require a
>> >> keyPassword.
>> >> >>
>> >> >>  Vamsi
>> >> >>
>> >> >>
>> >> >> On 10/18/06, Guillaume Nodet < gnodet@gmail.com> wrote:
>> >> >> > I'm trying to look at integrating ServiceMix
>> >> >> > security in Geronimo.  Security in ServiceMix
>> >> >> > has several different aspects, but one of them
>> >> >> > is to be able to encrypt / decrypt, sign messages
>> >> >> > using WS-Security.
>> >> >> > I have defined in ServiceMix a Crypto [1] implementation [2]
>> >> >> > (used by wss4j) on top of a servicemix KeystoreInstance [3]
>> >> >> > (which is quite the same as the Geronimo one).
>> >> >> > The main differences are 2 new methods  
>> (getCertificateChain and
>> >> >> > getCertificateAlias) and the fact that the methods do not
 
>> need
>> >> >> > the keystore password in the parameters.
>> >> >> >
>> >> >> > I had a close look at the Geronimo KeystoreInstance and found
>> >> >> > that nearly all methods are called from the console only.
>> >> The only
>> >> >> > real methods used inside the server are when an  
>> SSLSocketFactory
>> >> >> > is created.
>> >> >> >
>> >> >> > So I'm wondering what is the best way to go.  I can easily
 
>> add
>> >> >> the two new
>> >> >> > methods to the KeystoreInstance, but the need to give the
>> >> password
>> >> >> > for all the calls is a bit disturbing. I need to access the
>> >> >> following
>> >> >> methods:
>> >> >> >   * listPrivateKeys
>> >> >> >   * listTrustCertificates
>> >> >> >   * getCertificate
>> >> >> >   * getCertificateAlias
>> >> >> >   * getCertificateChain
>> >> >> >   * getPrivateKey
>> >> >> >
>> >> >> > Would it be possible from the FileKeystoreInstance to use
the
>> >> >> > keystorePassword attribute instead of passing the password
>> >> >> > in the parameters ? I do understand that this may be a  
>> security
>> >> >> > hole, as the private keys would be available to everyone 

>> inside
>> >> >> > the server, so I'm willing to find a better way ...
>> >> >> >
>> >> >> > Any ideas ?
>> >> >> >
>> >> >> >
>> >> >> > [1]
>> >> >> http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/
>> >> >> components/crypto/Crypto.html
>> >> >> > [2]
>> >> >> http://svn.apache.org/viewvc/incubator/servicemix/trunk/
>> >> servicemix-
>> >> >> soap/src/main/java/org/apache/servicemix/soap/handlers/ 
>> security/
>> >> >> KeystoreInstanceCrypto.java?view=markup
>> >> >> > [3]
>> >> >> http://svn.apache.org/viewvc/incubator/servicemix/trunk/
>> >> servicemix-
>> >> >> core/src/main/java/org/apache/servicemix/jbi/security/keystore/
>> >> >> KeystoreInstance.java?view=markup
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Cheers,
>> >> >> > Guillaume Nodet
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Cheers,
>> >> > Guillaume Nodet
>> >>
>> >>
>> >
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>>
>>


Mime
View raw message