[jboss-dev-forums] [JBoss AS7 Development] - Management API Security Key Decisions

[Brian Stansberry]

Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:

"Management API Security Key Decisions"

To view the document, visit: http://community.jboss.org/docs/DOC-16586

--------------------------------------------------------------
h1. Key Decisions

This article tracks the key decisions to be made regarding the security of the management APIs.

h2. Traditional Authentication or Security Tokens
This problem was introduced closely related to authentication caches - without the overhead invovled during authentication this would purely be about personal preferences.

 http://community.jboss.org/docs/DOC-16452 Design Consideration - Management API Authentication Caching

The following article highlights some of the advantages and disadvantages of each approach.

 http://community.jboss.org/docs/DOC-16584 Management API Security Token vs Per Node Authentication
h3. Decision
|| *Option* || *Comments
* ||
| Traditional Only | 
 |
| Security Token Only | Not an option; we need both the Remoting SASL integration and also HTTP standard based integration |
| Traditional Only then add Secutiry Token Support | This is our choice, but the security token is not a high priority. Will not be in 7.1 |

h2. Authentication Mechanisms (Server Side)
Regardless of if we stick with traditional authentication or use a security token some form of authentication will still be required first to provide the security token.

The following article discusses these options.
 http://community.jboss.org/docs/DOC-16574 Management API Security Authentication Mechanisms
h3. Decision
|| *Option* || *Comment* ||
| Support a simple property file based authentication? | Yes |
| Support LDAP based authentication? | Yes |
| Support Database based authentication? | Eventually; lower priority. May not be in 7.1 |
| Support delegate to domain controller type authentication? | Lowest priority. |

h2. Authentication Mechanism (Transport)
The following article explores how exposing our own APIs now gives us some flexibiliy regarding how to handle different authentication mechanisms for the transport.
 http://community.jboss.org/docs/DOC-16587 Management API Security Transport Authentication
Essentially we can now dynamically identify one of a number of potential mechanisms from a single request instead of the previous servlet container based approach where you would need to forward to different deployments to use different mechanisms.
h2. Host to Domain Controller Authentication
The following article explores the authentication and establishment of trust between the remote host and the domain controller.
 http://community.jboss.org/docs/DOC-16579 Management API Security Host to Domain Controller Security
Essentially the host is just a special type of user, initially no different to any other administrator but at some point when ACLs are defined we can review adding an ACL for 'register host' or something similar.

No decisions here unless there are additional comments?

This does imply that an exposed management API may need to support multiple authentication mechanisms at the protocol level as support certificates for the host to domain controller connection does not nescesarily mean a desire for administrators to also use certificates when they connect.

h2. Configuration Options
The security is going to require additional configuration for the definition, as the only configuration made available so far is which APIs to expose there are no pre-existing placeholders to insert the security configuration.

The following article shows the current configuration.
 http://community.jboss.org/docs/DOC-16494 Management API Security Configuration

The following article starts to explore in terms of traditional authentication how this could be defined.
 http://community.jboss.org/docs/DOC-16576 Management API Security Possible Configuration Samples
h3. Decision
|| *Option* || *Comment* ||
| Prefer configuration focussed in domain.xml? | 
 |
| Prefer configuration focussed in host.xml? | 
 |

h2. Database Connection Pool
We are required to integrate with existing security infrastructure, this means we will need to support a Database login module so we will require connections to the database.
h3. Decision
Who will previde the connection pool?
|| *Option* || *Comment* ||
| Provided by the management security implementation. | 
 |
| Will be provided as part of another task. | 
 |

h2. Authorization Checks
At this stage out only requirement is to verify that the user is authenticated, the following raises points to consider regarding how authorization checks will be performed depending on how a request reaches the management API on any host.
 http://community.jboss.org/docs/DOC-16583 Management API Security Authorization Responsibility
--------------------------------------------------------------

Comment by going to Community
[http://community.jboss.org/docs/DOC-16586]

Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&containerType=14&container=2225]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20111005/95a6c7cd/attachment.html