Tim,
When you say that create-local-instance should require end-user auth, do
you mean that it should:
1) take --user and --passwordfile options
2) read the ~/.asadminpass file if those options are not provided
Because create-local-instance already does this in order to invoke the
_register-instance command on the DAS.
Tom
On 7/8/2010 7:11 AM, Tim Quinn wrote:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> - Tim
>
>>
>>
>> Tim Quinn wrote on 07/05/2010 09:36 PM:
>>> I'm finally getting back to this thread.
>>> On Jun 23, 2010, at 6:51 PM, Bill Shannon wrote:
>>>> Tim Quinn wrote on 06/23/10 01:50 PM:
>>>>> Hi.
>>>>>
>>>>> In GlassFish 2 the start-instance command accepts authentication
>>>>> (--user
>>>>> and --passwordfile).
>>>>
>>>> Because it's a remote command, not a local command. Same in v3.
>>> Yes, a command in either version accepts auth. if and only if it's a
>>> remote command. I guess my concern really comes down to labeling
>>> the v3 start-instance it as a local command vs. a remote one.
>>> Here's why.
>>> Our plan for DAS-to-instance security relies on the DAS and the
>>> server using mutual certificate-based authentication. What looks to
>>> the user like the single operation of the initial start-up of an
>>> instance actually will involve several internal steps:
>>> 1. The process and VM are started.
>>> 2. The instance and the DAS exchange security information which they
>>> will use in later connections for mutual authentication.
>>> 3. The instance syncs with the DAS to get the application bits it
>>> needs to load and run.
>>> As part of internal step 2, the instance and the DAS will exchange
>>> public keys with each other (no problem there). At the same time,
>>> the DAS will need to send to the instance the private key which the
>>> instance should use in later mutual authentication with the DAS.
>>> This private key is much more sensitive than the the public keys
>>> and GlassFish needs to be careful where it sends that information.
>>> So, in this sense at least, the initial instance start-up resembles
>>> a remote command in that it needs to interact with the DAS.
>>> I think as part of this initial start-up we want two things to happen:
>>> 1. The DAS will make sure that the person starting the initial
>>> instance is a legitimate admin user.
>>> 2. The user doing the initial instance start-up should be able to
>>> see the self-signed certificate offered by the DAS before going
>>> ahead with the operation.
>>> These are both characteristics of commands we call "remote." Among
>>> other things, I think we'd want to allow the user to specify a
>>> username and password file on the start-instance command line. But
>>> every subsequent start-up of that instance indeed needs to behave as
>>> a local command; we don't want (and won't need) the DAS to be up in
>>> order for the instance to start after its initial start-up.
>>> As long as we understand - and document clearly - that there is this
>>> first-time-only processing that DOES require authentication with the
>>> DAS then, sure, we can call start-instance a local command.
>>> Another option, which I mentioned earlier in the thread, is to rely
>>> solely on file system protections to prevent unauthorized users from
>>> starting an instance. It seems OK to rely on file access
>>> permissions to control who can start a previously-started instance.
>>> I think we want to rely on more than just file permissions to
>>> control who can do that initial start-up of an instance which we
>>> know must include contact with the DAS to succeed -- it should rely
>>> on the same kind authentication to the DAS that other "remote"
>>> operations require.
>>> - Tim
>>>>> In GlassFish 3 the start-local-instance command does not accept
>>>>> auth, so
>>>>> presumably any user with access to the GlassFish installation files
>>>>> could start a local instance.
>>>>>
>>>>> Of course, in GlassFish 3 (currently at least) the only thing to
>>>>> authenticate with is the DAS, and we don't want to have to contact the
>>>>> DAS to start an instance because the DAS might not be up. So in
>>>>> GlassFish 3 we rely only on the access controls in the file system to
>>>>> prevent rogue instance starts?
>>>>
>>>> Right. Just like v2, I believe. In v2 I think you could manually
>>>> start
>>>> a server instance using a local command.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> <mailto:admin-unsubscribe_at_glassfish.dev.java.net>
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>> <mailto:admin-help_at_glassfish.dev.java.net>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> <mailto:admin-unsubscribe_at_glassfish.dev.java.net>
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>> <mailto:admin-help_at_glassfish.dev.java.net>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> <mailto:admin-unsubscribe_at_glassfish.dev.java.net>
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>> <mailto:admin-help_at_glassfish.dev.java.net>
>>
>