[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.
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, 10 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.
Once the host is associated with the domain then the domain configured security will apply to the management APIs.
h2. Authorization
--------------------------------------------------------------
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, 10 months
[PicketBox Development] - AS7 Plugability for Dependencies
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/darran.lofthouse%40jboss.com] created the discussion
"AS7 Plugability for Dependencies"
To view the discussion, visit: http://community.jboss.org/message/586195#586195
--------------------------------------------------------------
For the AS7 managament API security we are currently discussing how to re-use as much as possible of the already integrated PicketBox project.
One requirement that we have is that the security of the management API is not going to be running within an AS7 so it is not possible to depend on some services normally available at runtime.
At the moment looking at the login modules would it be possible where identified for these to be re-factored to make either overriding access to the server resources easier or even including some form of plug-in mechanism for that access?
The first module that has been identified as having an issue without the AS is the DatabaseServerLoginModule, this module depends on both JNDI and a deployed datasource. When running within the domain controller JCA will definately not be available and I doubt the availability of JNDI but a connection pool may be available so for this module we would be looking for a way to override how the connection is obtained.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/586195#586195]
Start a new discussion in PicketBox Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 10 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. 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.
Once the host is associated with the domain then the domain configured security will apply to the management APIs.
h2. Authorization
--------------------------------------------------------------
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, 10 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. 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.
h2. Authorization
--------------------------------------------------------------
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, 10 months
[JBoss AS7 Development] - Design Consideration - Management API Authentication Caching
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/darran.lofthouse%40jboss.com] modified the document:
"Design Consideration - Management API Authentication Caching"
To view the document, visit: http://community.jboss.org/docs/DOC-16452
--------------------------------------------------------------
h1. Management API Authentication Caching
This document is to start exploring the options to minimise the calls out to the security infrastructure so these calls are not required for every administrative operation.
Initially I am starting to explore two areas but this may expand if there are further suggestions.
h2. Authentication Cache
This is an approach we have already used regularly in all AS releases as far back as I can remember, after a successful authentication the users username and password are stored in a cache, for every invocation to the server the users username and password are contained within the request and authentication is attempted - as a matching username and password are found in the cache the cached identity is used and the login modules are not called.
The design of the authentication cache being developed for AS7 is being discussed here: -
http://community.jboss.org/thread/159180 AS7: Authentication Cache Design
If we were only going to be receiving the administrative requests on a single node then requiring the client to send the username and password with every request and make use of the authentication cache on the server should be sufficient for our needs, however once we add multiple nodes receiving requests independently other issues become apparent.
Assuming the request handling on the hosts are just a cut down / slave domain controller the security configuration can be inherited from the domain controller allowing for the same login modules and cache configuration on each node.
The first issue is how to really perform the authentication on these sub-nodes?
1. Send a request to the domain controller to see if it has already performed this authentication?* However the reason for these direct calls is for performance so the domain controller can be bypassed in this calls.
2. Perform the authentication on the hosts in exactly the same way as it would be performed on the domain controller?* This would lead to a performance hit on the initial query of each node as each node would need to authenticate independently.
* This would also be a peak in load on the security infrastructure if the administrator contacts all nodes e.g. a script which loops to collect stats directly from each node.
* Servers in a server group may be on hosts issolated from the rest of the network, access may only be possible to the domain controller.
One required feature of an authentication cache is cache invalidation, this is used to remove either an individual entry from the cache or to clear the whole cache - the end result is that once the entry is remove the authentication needs to be repeated for the cleared users the next time they connect.
* Users will have their roles reloaded by this so this will allow role modifications to be picked up.
* Users who's accounts have been disabled or have had their password reset will not be able to authenticate with the password used previously.
Having an independent authentication cache on each host then introduces it's own issues as cache invalidation needs to be considered.
* Would a cache invalidation operation be propagated to every node?
* Would an administrator need to call the invalidation on each node independently?
h2. Authentication Token
The second option is to consider the user of an authentication token.
The user would invoke a login operation on the domain controller, the exact format would need to be designed further but in principal this would return a token which contains: -
* User identity
* Roles
* Created Time
* Expiration Time
This would be signed by the domain controller.
All subsequent requests would then contain this authentication token instead of the username and password.
Server side authentication would then verify the signature and check the token is between the created and expiration time and use the identity and roles from the token.
For distributed calls this would eliminate the need for non domain controller hosts to perform authentication either against the existing infrastructure or by calling the domain controller.
There is no need for an authentication cache as the token becomes the cache - however without a cache an alternative mechanism would be needed to cut a users access while there is a valid token for that user.
A black list could be maintained instead, if a user is to be forced to re-authenticate their identify could be added to the black list along with a time - any tokens created before that time will be rejected. Objects will only need to remain in the blacklist as long as the token could be valid.
For this approach the structure and integrity of the token becomes critical for it's safe operation.
h2. Out of Scope
This consideration is assuming confidentiality of the messages exchanged so this is not considering issues such as replay attacks as the token would not be publicly visible.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16452]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 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.
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. 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.
h2. Authorization
--------------------------------------------------------------
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, 10 months