Hi Guillaume,
In the current KeystoreInstance interface, I see that the lockKeystore
method needs keystore password and throws NullPointerException on null
parameter. How to lock the keystore under this scenario?
VamsiOn 10/19/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
I came with the follow
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 <[EMAIL PROTECTED]> wrote:
I came with the follo
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 pass
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
sa
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
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 c
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
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-passw
On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> 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
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
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 se
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
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 LoginM
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 exi
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 pass
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
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 se
17 matches
Mail list logo