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
