Host to Domain Controller Security

Once a host connects to the domain controller the host can obtain the full domain model and the relevent deployments from the domain controller, this connection needs to be secured to ensure that only valid hosts can connect to the domain controller and retrieve this configuration.

After the authenticate everywhere / token based authentication discussion this may need refining but starting with the assumption of authenticate everwhere this can be secured as follows.

These considerations only apply to domain based installations as there is no host -> domain controller connection for standalone installations.  This does lead to the risk that for shared XML schemas some items could be added that are not relevent to standalone although these could be handled with suitable error notifications.

Same Mechanism as User Authentication / Authorization

User authentication and authorization will be implemented anyway, for this reason I propose that the connection to the domain controller from the host will be secured in exactly the same way. 

The host then becomes a user that requires a specific set of priviledges.

Shared Secret

For this scenario this will be username / password authentication as the host establishes the connection to the domain controller.

The following PicketBox discussion is regarding any new capabilities being added to aid password encryption/obfuscation so we can try and take advantage of what will be available: -

AS7 Password Encryption / Obfuscation

By default the username used for the connection will be the name of the host but it will be possible to override this.

The password can either be passed in using the command line or can be defined in the host.xml.  Using the command line can be simpler for some but it does cause concerns where command line arguments can be seen when listing running processes.

One possible host.xml configuration could look like: -

<host xmlns="urn:jboss:domain:1.0">
...
    <domain-controller>
       <remote host="192.168.100.1" port="9999" 
               userName="host_a" password="my_secret" />
    </domain-controller>
...
</host>

Alternatively a child element could be added to <remote> to allow different client side authentication mechanisms to be define.

Or maybe on the command line: -

>  ./domain.sh userName=host_a password=my_secret

Certificate Based Authentication

The following discussion is regarding the capabilities that PicketBox will be able to provide that we will re-use for this scenario: -

AS7: Construct for centralized security

The connection over the Native API will be a SSL/TLS connection, both the domain controller node and the host will have a certificate and this will be used on the domain controller side to authenticate the host.  Optionally it will also be possible to configure the host for verification of the domain controllers certificate.

This connection is persistent so the authentication will only occur at the stage the connection is created and negotiated.

This would be adjusted based on the discussion linked above but in principal information relating to the keystores / truststores will need to be define on the <remote> element: -

<host xmlns="urn:jboss:domain:1.0">
...
    <domain-controller>
       <remote host="192.168.100.1" port="9999"
               keystore="host.keystore" truststore="domain_controller.truststore" />
    </domain-controller>
...
</host>

(There will be quite few additional attributes required such as alias selection, control of hostname verification, passwords to access the stores ...)

Also as for the shared secret options there may be a need to make use of the PicketBox password encryption/obfuscation for the passwords although if the whole configuration for SSL/TLS can be passed back to PicketBox we may just reference a PicketBox defined configuration.

Access Control

The access control mechanism is still to be defined as it is not a primary requirement for this current phase of development.

However for the perspective of host actions I would anticipate that there would be an ACL definition for something similar to 'joinDomain', this priviledge will only be granted to accounts allowed to join the domain - further consideration will be required but this could also be extended for things like listing server groups that a host can run.