On Jul 8, 2010, at 6:47 PM, Joe Di Pol wrote:
> Bill Shannon wrote:
>> There's still the bootstrap/startup problem.
>> What authentication do you use for the first sync request? And where
>> do you get it? Before the sync, there is no keystore on the client.
>> Some choices are:
>> 1. creating the instance ensures that the instance starts with a
>> keystore instead of starting with nothing.
>
> This seems to work well for create-instance where it can push the
> keystore to the instance and pass it to _creat-instance-filesystem.
> But maybe less well for create-local-instance. Where does it get
> the keystore?
>
>> 2. we save the admin username and password in the das.properties file
>> and use that for authentication during synchronization.
>
> And this works well for create-local-instance which has the admin
> username and password, but less so for create-instance which does not.
>
>> 3. we have a separate "node agent" keystore that contains the
>> authentication
>> information we use during synchronization.
>
> Looks like a variation of 1.
>
>> And don't forget that with whatever approach we choose there needs
>> to be
>> a way to change the authentication information used for
>> synchronization,
>> preferably without a manual step on each node.
>
> Which seems to argue for 1 or 3 since the DAS can push out a keystore
> but can't push out an admin password (because it doesn't have it).
As for bootstrapping... Here are the steps I'm thinking of.
The user installs the GF software on the DAS host. The default
domain1 includes a keystore with the default keystore password (the
master password) that contains the DAS private key with alias s1as.
This is in the glassfish.zip file today.
As the DAS first executes _register_instance or perhaps some related
hidden command, it sees that its keystore does not contain a private
key with alias, say, gf-instance-admin. (This would be
configurable.) The DAS generates a self-signed cert for use in
instance authentication and stores the private key into its keystore
with that alias.
On to instance creation. Two cases:
create-instance: This is a remote command (run anywhere, not
necessarily on the instance), so the end-user authenticates with
username and password to the DAS. This establishes that the end user
is someone we want to allow to create an instance. The _create-
instance-filesystem command that is sent over ssh to the instance
carries with it a copy of the DAS's keystore - not the keys separately
but the keystore file - and deposits it in the correct place. (Maybe
the copy is accomplished as a separate scp command that's part of what
create-instance does behind the scenes?? Joe?) At that point the
instance's file system now has a keystore which the instance can use
for mutual auth with the DAS.
create-local-instance: (The user has installed the software on the
remote host.) This is a remote command in that it contacts the DAS,
so the user who is logged into the remote host needs to authenticate
with username and password. Again, this establishes that we are OK
with this user creating an instance. Part of the create-local-
instance processing will include downloading a copy of the DAS
keystore and depositing it into the instance's config directory.
From then on, when the instance itself starts up and contacts the DAS
it has a keystore it can use to authenticate.
In both cases, the end user has authenticated to the DAS. In both
cases, the instance has securely received a keystore it can use for
authenticating to the DAS.
Thoughts?
- Tim