Michael Hall wrote:
>This assumes OS X where JAAS UnixLoginModule determining the correct
>Principal to use to access the user private information _may_ be
>fine. But again not a platform neutral solution where there is no
>'user' based JAAS login module provided.
There isn't going to be a completely platform-neutral solution, unless you
deploy a platform-neutral JAAS login module. The default login modules
are, of necessity, specific to a platform or specific to an authentication
technology.
>Again I'm pretty sure I didn't use the application('s), or java test
>programs to add them so I'm pretty sure this is the case either.
Use Keychain Access.app to examine your keychain(s).
Find one of the specific items your app is requesting, and double-click it.
You should see a window with an Attributes tab and Access Control tab.
Click Access Control and it prompts for a password (the enclosing
keychain's password). Look at the resulting list and make sure there are
no apps listed as "Always allow access by these applications".
Then from the Edit menu, choose Change Settings for Keychain "blah"...
Enter a password if necessary. A modal dialog appears with optional
idle-lock interval ("Lock after N minutes of inactivity") sleep-lock, and
sync. If you don't have the idle-lock checkbox checked, then you don't
have an idle-lock timeout.
Also review the tabs of the Preferences dialog.
My login keychain is empty, and I mostly keep it that way. I have a
separate keychain with a password different from my login password, in
which I keep my passwords, keys, certs, etc. I get prompted for first
access to this keychain, and am not reprompted within that keychain's
idle-lock interval. After the idle-lock interval expires, I am reprompted
for that keychain's password.
My empty login keychain doesn't have an idle-lock interval set.
I have a cert in my non-login keychain, and with a Java test program that
just lists KeyStore aliases, it gets listed whether I provide a password or
not. But I expected this, because plain certs (which mine is) don't
contain secrets, so don't need passwords. I don't have any private keys in
my keychains, so I can't tell whether the rest of the test is doing what it
should or not. I have a number of passwords stored in my keychains, but
KeyStore doesn't list their aliases, so it can't return them.
However, if you're looking for cross-platform authentication, then using
the Keychain keystore may not be the way to go, since it only exists on Mac
OS X. So regardless of how Keychain behaves or misbehaves with Java, you
can't use it cross-platform.
In any case, being able to retrieve a private key from a KeyStore isn't
authentication or access-control. It's just key management.
You still have to present something signed by the key to the agent doing
the authentication. That is, you still have to present your credentials at
an access-controlled gateway (a checkpoint), and get either a grant or a
refusal.
Since you haven't yet said anything about where that checkpoint is or what
credentials are needed to get through it, I don't see the relevance between
key-retrieval and authentication.
Or are you keeping the MySQL database passwords in your KeyStore, and
retrieving them with a keystore-password for creating a JDBC connection?
In other words, is your JDBC connection the access-control checkpoint?
I'm seeing various pieces, but the big picture is murky:
Who authenticates Whom for access to What.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
