Darran Lofthouse [
http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Authorization Responsibility"
To view the document, visit:
http://community.jboss.org/docs/DOC-16583
--------------------------------------------------------------
h1. Authorization Responsibility
An ACL scheme for the authorization checks is still to be defined as it is not a priority
at this stage, this document however is to capture the optimum locations that the
authorization checks will occur.
When a request is recieved by from a client for a management operation this request can
affect anything from the whole domain to individual nodes in the domain, it is quite
possible that an administrator could send a request for which they have the permission to
perform the majority of the requested operations but some aspects may be prohibited - this
is not nescesarily due to the administrator deliberately attempting to perform prohibited
actions but could be caused by the use of wildcards within addresses.
When performing the authorization check it is desirable that if the request is going to
fail due to an authorization check that this failure is detected early so we do not need
to rely on compendating operations to reverse a partially applied request.
h2. General Approach
The general approach for authorization is that after a request is recieved that may
involve a compound operation or my involve wildcard addresses this operation should be
'resolved' to identify the real operation calls that this will result in - this
list can then be checked before it is executed to verify that the calling user is
authorized to perform all operations.
This is assuming a centralised ACL scheme covering a whole domain rather than ACL
definitions defined independently on each host.
h2. Call Routing
The flexible nature of the domain architecutre means that there are multiple ways
operations can be requested and transferred to the hosts that will end up acting on them,
h3. Internal / Start-Up
The bootstrap process for the JBoss AS domain configuration involves the parsing of the
configuration and the calling of numerous operations to start and configure the actual
servers and the required services.
There may also be a need for further operation requests to be executed after being
requested internally.
All requests originating in this way should be automatically authorized.
h3. Client -> Standalone
This is the simplest scenario where a client is calling the management APIs exposed by the
running standalone instance.
Authorization will follow the basic steps highlighted at the start of this article and the
operations will be resolved and and authorization check performed.
As this is standalone there is no requirement to consider remote nodes.
h3. Client -> Domain Controller -> Domain Slave
I would expect this to be the dominant use case for administration when working with
domain deployments, the administrator will connect to the management API of the domain
controller and the requests will be passed to the slave domain controllers to be passed to
the servers running on that host.
On start up the domain slave will have established a connection to the domain controller,
the trust mechanisms are being covered in a different article but for the point of
considering the authorization checks this connection can be considered a trusted
connection.
For authorization the domain controller will have performed the resolve step to break down
the request into the discrete steps, and authorization check will then be performed on the
steps before passing the request to the relevent slave domain controllers.
The slave domain controllers can assume all requests coming over this connection are
authorized and no further checks will be performed, this will also mean the slave domain
controller works the same regardless of if this is bootstrap type start up requests or
live requests from an administrator.
h3. Client -> Domain Slave
In this scenario the client has established a direct connection to the slave domain
controller of a host, this scenario is most likely if the administrator is specifically
interest in the running state of a specific host or are making changes for the host.xml of
that host.
The slave domain controller will be required to have access to the same ACL scheme as
defined on the domain controller
This is very similar to the standalone scenario (in terms of the authorization
requirements at least) - the request will be 'resolved' to identify the resulting
steps and these will be verified for authorization before the request is executed.
h3. Client -> Domain Slave -> Domain Controller -> Domain Slave (Optional)
This final scenario adds some additional complexity, if a slave domain controller receives
a request from a client that needs to be handled by the master domain controller this
request will be passed to the domain controller to execute.
This needs further consideration as the authentication / authorization is not as clean.
One option is that the domain controller that recieves the request performs the full
authentication / authorization before passing to the master so the master will trust this
request is authorizaed - however I don't believe the slave will have all the
information available if this is a cross domain request, there is also a question as to if
you should place that much trust in the slave domain controller.
A variation of the first option is that when the request is passed to the domain
controller the principal of the caller is also passed along with their roles - the master
domain controller can then use this for the authorization check. This solves one problem
from the first option but still leaves the question regarding how much do you trust the
slave.
A third option is that the credentials used to authenticate the client are passed to the
domain controller so a full authentication / authorization check can be performed there.
This does then help remove trusting a slave domain controller but now credentials that
need to be protected are being passed from node to node.
A final option is to prohibit this scenrio and instead if a slave domain controller
recieves a request it can handled a redirect should be returned so the client can connect
to the master domain controller.
--------------------------------------------------------------
Comment by going to Community
[
http://community.jboss.org/docs/DOC-16583]
Create a new document in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]