Darran Lofthouse [
http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Token vs Per Node Authentication"
To view the document, visit:
http://community.jboss.org/docs/DOC-16584
--------------------------------------------------------------
h1. 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.
h2. 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. |
|
|
|
h2. 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. |
--------------------------------------------------------------
Comment by going to Community
[
http://community.jboss.org/docs/DOC-16584]
Create a new document in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]