Key Decisions
This article tracks the key decisions to be made regarding the security of the management APIs.
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.
Design Consideration - Management API Authentication Caching
The following article highlights some of the advantages and disadvantages of each approach.
Management API Security Token vs Per Node Authentication
Decision
| Option | Comments
|
|---|
| Traditional Only |
|
| Security Token Only |
|
| Traditional Only then add Secutiry Token Support |
|
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.
Management API Security Authentication Mechanisms
Decision
| Option | Comment |
|---|
| Support a simple property file based authentication? |
|
| Support LDAP based authentication? |
|
| Support Database based authentication? |
|
| Support delegate to domain controller type authentication? |
|
Host to Domain Controller Authentication
The following article explores the authentication and establishment of trust between the remote host and the domain controller.
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.
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.
Management API Security Configuration
The following article starts to explore in terms of traditional authentication how this could be defined.
Management API Security Possible Configuration Samples
Decision
| Option | Comment |
|---|
| Prefer configuration focussed in domain.xml? |
|
| Prefer configuration focussed in host.xml? |
|
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.
Decision
Who will previde the connection pool?
| Option | Comment |
|---|
| Provided by the management security implementation. |
|
| Will be provided as part of another task. |
|
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.
Management API Security Authorization Responsibility