On Jul 8, 2010, at 11:12 AM, Tom Mueller wrote:
> 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
>
Yes, both.
> Because create-local-instance already does this in order to invoke
> the _register-instance command on the DAS.
Ah, in the ProgramOptions; I see now.
Then that'll work for what I have in mind. Bill's description didn't
mention that explicitly and it slipped my mind that the DAS
authentication was implicit in ProgramOptions declared in CLICommand.
Thanks.
- Tim
>
> 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
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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