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.
The following article highlights some of the advantages and disadvantages of each approach.
|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|
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.
|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.|
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.
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.
Host to Domain Controller Authentication
The following article explores the authentication and establishment of trust between the remote host and the domain controller.
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.
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.
The following article starts to explore in terms of traditional authentication how this could be defined.
|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.
Who will previde the connection pool?
|Provided by the management security implementation.|
|Will be provided as part of another task.|
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.