Management API Security

Introduction

The purpose of this document is to capture the requirements, considerations and desicions regarding the securing access to the management APIs for managing or monitoring both standalone JBoss AS7 installations and complete JBoss AS7 domains.

At a high level the JBoss AS7 domains will be managed by a single domain controller, the hosts will then establish a connection with this domain controller to recieve their management operations to be performed on the host or servers running on that host.  In addition to this there is also the possibility for clients to connect directly to hosts to retrieve state from those running hosts and their servers.

The standalone AS7 installations will have all of this combined into a single process, however the same management APIs will be exposed and the same operations possible in the context of a single standalone installation (i.e. operations such as starting a server on a remote host will no longer be applicable).

Authentication

For the authentication there are two distinct areas to consider, one is the transport used between the client and the domain controller or even host and the second is the actual authentication mechanism that will be used within the domain controller / host process.

To minimise calls to the security infrastructure some form of caching of the users identity will be required, this is being considered here: -

Design Consideration - Management API Authentication Caching

Transport

There may be different clients making use of the transports but essentially the transport will either be over the HTTP admin interface or over Remoting.

Server Integration

The domain management will be happening within the domain controller process, this is not a server so all integration will be specifically for use within the domain controller.

Out of the Box Security

The security implementation for the management APIs has a requirement to be able to integrate with existing security infrastructure, in general this is achievable using LDAP or Database login modules to connect to the existing systems.  However there is also a requirement to not introduce an out of the box dependency on external systems so some form of out of the box store for users with their passwords and roles is required.

Traditionally this would be approached by making use of properties files however from the following thread a PicketLink approach may be considered for HornetQ so this may also be an approach that can be taken for the management APIs: -

AS7 Property File Based Login Modules

Multi-Node Request Handling

Administrators can submit requests to the domain controller and where required this will contact the relevent hosts and return a response back to the client aggregating the responses, the client can however for reading metrics at least contact the host directly - the reason for this is for performance gains so the security of the management API can not impose a large overhead on each node in the domain.

Independent Hosts

In addition to working in a full domain it is also possible for hosts to be running disconnected from any domain controller, this could happen if a host has been orphaned or it may mean the host is a new host that has not previously been associated with a domain controller.

I am proposing that we consider this a special case and have a single user defined against this host, the user would be given limited abilities to only view the domain controller connection settings and update if required.

Once the host is associated with the domain then the domain configured security will apply to the management APIs.

Authorization

Configuration

I believe that to reduce complexity the security for the management APIs should be defined within the domain.xml for domains and for the standalone server in the standalone.xml - for the domains all settings where appropriate can also apply equally to the management APIs exposed by the individual hosts.

Where the management APIs are running we can not assume we are in an AS process so everything is likely to need to be bootstrapped differently to if it was running within an AS process.  Having said that it still makes sense to try and re-use the schema defined by the security subsystem and the related parsing and initialisation in a non-AS situation - this will mean users familiar with the configuration for the security sub system will also be familar of the security for the management API configuration.

The exception to this would be from the discussion in connection to independent hosts above which unless we want to introduce an additional file I believe the host specific user would be defined within the host.xml