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.

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.

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,

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.

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.

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.

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.

Client -> Domain Slave -> Domain Controller -> Domain Slave (Optional)

(Note: we have decided not to support this call pattern any time in the forseeable future. So the following discussion is for reference only.)

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.

(If we were to use a signed security token then for this final scenrio is would be easier to support this scenario by allowing the token to be passed to the master domain controller it would then be able to verify the token as if it had been recieved directly whilst avoiding a scenario of passing credentials from node to node)