[JBoss AS7 Development] - Management API Security Design
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/darran.lofthouse%40jboss.com] modified the document:
"Management API Security Design"
To view the document, visit: http://community.jboss.org/docs/DOC-16447
--------------------------------------------------------------
h1. Management API Security
h2. 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).
Tasks are being defined in the following document: -
http://community.jboss.org/docs/DOC-16463 Management Security Tasks
h2. 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: -
http://community.jboss.org/docs/DOC-16452 Design Consideration - Management API Authentication Caching
h3. 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.
h3. 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.
h4. 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: -
http://community.jboss.org/thread/162307 AS7 Property File Based Login Modules
h4. 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.
h4. 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.
*Update 9/Feb/2011 -* It has been confirmed that a host should be manually configured to connect to the domain controller at least once, the cached configuration from the domain controller can then be used for future security checks until the domain controller can be contacted again.
Once the host is associated with the domain then the domain configured security will apply to the management APIs.
h2. Authorization
h2. 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
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16447]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Management Security Tasks
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/darran.lofthouse%40jboss.com] created the document:
"Management Security Tasks"
To view the document, visit: http://community.jboss.org/docs/DOC-16463
--------------------------------------------------------------
Identified tasks for adding security to the AS7 management APIs: -
|| *Description* || *Jira Issues* || *Owner
* || *Dependencies
* || *Comments / Risks
* ||
| Define security configuration. |
|
| General management API configuration. |
|
| Login modules need to operate in non-AS domains. |
| Anil / Marcus |
|
|
| Add BASIC authenticator to HTTP API |
|
|
|
|
| Add TLS/SSL to HTTP API |
|
|
|
|
| Add CLIENT-CERT type authenticator to HTTP API |
|
|
|
|
| Ensure equivalent authentication possible through native API. |
|
| Initial native API with Remoting. |
|
| Security initialisation similar to subsystem initialisation. |
|
|
| To review as much re-use of security extension in non AS. |
| Interception of all inbound calls for authorization check. |
|
|
| Initial check may just be that the calling user must have been authenticated. |
| Define ACL scheme. |
|
|
|
|
| Add ACL checking to authorization. |
|
|
|
|
| Mechanism to provide users permissions to clients of the API. |
|
|
|
|
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16463]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Management API Security Design
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/darran.lofthouse%40jboss.com] modified the document:
"Management API Security Design"
To view the document, visit: http://community.jboss.org/docs/DOC-16447
--------------------------------------------------------------
h1. Management API Security
h2. 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).
h2. 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: -
http://community.jboss.org/docs/DOC-16452 Design Consideration - Management API Authentication Caching
h3. 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.
h3. 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.
h4. 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: -
http://community.jboss.org/thread/162307 AS7 Property File Based Login Modules
h4. 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.
h4. 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.
*Update 9/Feb/2011 -* It has been confirmed that a host should be manually configured to connect to the domain controller at least once, the cached configuration from the domain controller can then be used for future security checks until the domain controller can be contacted again.
Once the host is associated with the domain then the domain configured security will apply to the management APIs.
h2. Authorization
h2. 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
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16447]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months