Bill raised some interesting points about what would be in the
keystores and truststores, esp. with respect to sync.
Things actually get simpler if the DAS and the instances share the
same keystore and truststore via the sync mechanism.
First, looking separately at what the DAS needs and what an instance
needs to mutually authenticate over SSL:
| Req'd by DAS | Req'd by instance |
=====================================================
needed | | |
in the | DAS private | instance private |
keystore | key entry | key entry |
-----------------------------------------------------
needed | | |
in the | instance trusted | DAS trusted |
truststore | public cert entry | public cert entry |
-----------------------------------------------------
Second, let's say that all instances will use the same instance key
pair. (This is a change from my earlier thoughts.)
Now, during domain creation the DAS would create not only the key pair
it will use for its own authentication but also the single key pair
that all instances will use. It would store both private keys into
its keystore and both trusted cert entries into its truststore.
Then, the initial sync for the new instance will place a copy of the
common keystore and truststore files in the instance's directory.
This avoids the problem Bill alluded to of an instance-generated key
that was stored in the (sync-ed) keystore being overwritten during a
later sync. Also, the instance would not need to send the DAS its
public key cert because the instance keys would not be unique and the
DAS already knows the keys which all instances will use.
The difference is that the DAS admin listener will be configured to
use the DAS's private key alias for authentication, while the instance
admin listeners will be configured to use the instance private key
alias. We could enhance the admin adapter to reject incoming traffic
if the originating Principal is the same as itself. (This would
prevent accidental or purposeful attempts to send admin requests from
DAS to DAS or from an instance to another instance.)
- Tim
On Jul 8, 2010, at 4:07 PM, Bill Shannon wrote:
> Tim Quinn wrote on 07/08/2010 05:11 AM:
>> On Jul 7, 2010, at 10:23 PM, Bill Shannon wrote:
>>> I'm not sure I followed the discussion below...
>>>
>>> start-instance is a remote command. It's a way for an
>>> administrator to
>>> (from anywhere) ask the DAS to please start a particular
>>> instance. The
>>> DAS uses SSH or (eventually) contacts the node agent on the machine
>>> where the instance will run to start the instance. Obviously the
>>> user
>>> needs to authenticate with the DAS.
>>>
>>> start-local-instance is a local command. No authentication is
>>> required
>>> beyond the operating system permissions to access the files
>>> necessary to
>>> start the server.
>>>
>>> create-local-instance saves all the authentication information
>>> necessary
>>> for start-local-instance to authenticate itself with the DAS based
>>> only
>>> on the contents of local files, without requiring the user to
>>> provide
>>> additional authentication information. Or at least it should, I
>>> don't
>>> know if it currently does.
>>>
>>> Did you think it should work differently?
>> What I think is that whatever command saves authentication
>> information locally so start-local-instance can work without end-
>> user auth. should itself require end-user auth. In your
>> description, that's create-local-instance. I was not clear whether
>> this would happen during create-local-instance or start-local-
>> instance.
>
> In general, I think we want create-local-instance to contact the DAS
> and verify the authentication and set everything up. I don't remember
> whether we also intended to support doing create-local-instance
> "offline",
> assuming a create-instance would be done separately and then
> everything
> would be set up by the time the instance was started. Maybe that's
> not
> an important use case.
>
>> One part of setting up the locally-saved info will be receiving
>> from the DAS the self-signed cert that the DAS proposes to use for
>> future SSL mutual auth. If the end-user accepts the DAS cert then
>> the command saves it in the instance's truststore.
>
> It will also be in the DAS's truststore, right?
>
>> Another part of the local file initialization will be generating a
>> self-signed cert that the instance will use in future SSL mutual
>> auth with the DAS. The command will present that cert to the DAS
>> (the DAS will save the instance cert in its truststore) and the
>> command will save the generated private key in the instance's local
>> keystore.
>
> How will the private key survive full synchronization of the instance?
> Will it also be stored in the keystore on the DAS? Will it be stored
> in a keystore that is not part of synchronization?
>
>> Because the instance's self-signed cert is how the DAS will trust
>> this instance in the future, and because create-local-instance
>> seems like the command that will generate that cert, I think create-
>> local-instance should do end-user authentication. Saving a cert in
>> the DAS truststore is just as much a change in the domain
>> configuration as anything that's stored in domain.xml, and we
>> require end-user auth before allowing those sorts of changes.
>
> So in addition to the _register-instance call that create-local-
> instance
> will make, does there need to be another call or calls to handle the
> cert exchange?
>
>> IIRC I've heard create-local-instance described as a local command
>> not requiring the end-user to authenticate to the DAS. I would
>> have thought that adding an instance to the domain would be
>> considered a config change and would involve authenticating the end-
>> user to the DAS. But apart from that, if create-local-instance
>> will be the command that sets up the instance's local files with
>> trusted authentication information, then shouldn't we require end-
>> user auth for that?
>
> Yes.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
Tim Quinn | Principal Member of Technical Staff | +1.847.604.9475
Oracle GlassFish Engineering
Lake Forest, IL