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
>