Token vs Per Node Authentication
For the security of the management APIs we can consider either replicating the authentication mechanism to each node or we can consider implementing a token mechanism where a client can obtain a token that they subsequently embed in each request that can be verified simply to identify the user.
The primary reason for considering this is that authentication can be a slow process when communicating with remote stores of users, if we are considering scenarios where users connect directly to nodes to retrieve runtime state as a perfromance gain we need to ensure that authentication does not erode that gain.
Per Node Authentication
Here the management APIs will be secured so that the user can either authenticate by providing a username and password each time they connect or we will use their certificate used for the SSL connection to identify them.
| Advantages | Disadvantages |
|---|---|
| Uses a form of authentication we have used regularly elsewhere. | An authentication cache will be required on each node, domain wide invalidation requests will be required if any details of the users account changes. |
| User can authenticate in the same way on any node. | Performance hit requiring authentication to be performed on each node the user connect to. |
| Uses standard authentication mechanisms at the protocol level e.g. BASIC | Difficult to pass users identity to different nodes. |
Token Authentication
For this scenario the user will call some form of login operation on the master domain controller, this will perform normal authentication to verify the user and obtain their roles, a token will then be created that contains the users identity, their roles, a created time and an expiration time - this token will then be signed by the master domain controller. On each subsequent request this token will be passed as a part of the request, the signature will be verified as will the two times and then the contained list of roles will be used.
| Advantages | Disadvantages |
|---|---|
| Eliminates the need for an authentication cache as the token is the cache. | Will be a new concept for JBoss AS |
| Performance hit when token is created but after that any node can verify the token using certificates. | Some form of revocation list will be required on each node. i.e. Disallow all tokens for user X created before time Y. (Only required for a comprimised account as for changes such as new roles they can just request a new token) |
| Have a simple artefact that can be passed from node to node to transfer clients identity. | User potentially needs to authenticare on master DC first - although we could have slave DC signed tokens for requests only against that DC. |
| Passing the token would be outside of the standard authentication mechanisms at the protocol level. |
Comments