Transport Authentication

At the tansport level a mechanism is required to recieve the users identity at the server, as we are using the simple HTTP server in addition to the Native API we have greater control of this compared to a JBoss Web style deployment using the web.xml descriptor to define the security constraints.

I propose that we use follow an approach that priorotises the mechanism used to recieve the identify falling back to other mechanisms as needed.

The order would be: -

1. Security Token
2. Username / Password
3. Client Certificate

Security Token

This is the highest priority as if the calling client has passed in a security token the authentication has already occurred so there would be no reason to fall back and repeat.

Username / Password

In terms of HTTP this would be a case of using the credentials passed using BASIC authentication from the client to the server.

The reason this is second and not third is because it will still be likely that SSL is used when username / password authentication is used so detecting a username and password has been sent in the request we can assume the user is deliverately trying to identify themselves with this pair.

Client Certificate

Finally if no security token is provided and no username/pasword is provided we can attempt to use the clients certificate for authentication.

Configuration

Username/Password authentication and client-cert authentication require different approaches to authentication so each will require a custom security domain to be defined.

Instead of adding any additional configuration to control username/password or client-cert authentication we can use the definition or lack of definition of the two domains to identify is username/password or client-cert authentication is supported.

i.e. For username / password authentication to even be considered a security domain for username / password authentication must have been defined - if this domain does not exist then this is not supported.