[JBoss AS7 Development] - Management API Security Authorization Responsibility
by Darran Lofthouse
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&co...]
13 years, 2 months
[JBoss AS7 Development] - Command Line Interface
by Alexey Loubyansky
Alexey Loubyansky [http://community.jboss.org/people/aloubyansky] modified the document:
"Command Line Interface"
To view the document, visit: http://community.jboss.org/docs/DOC-16581
--------------------------------------------------------------
The AS7 Command Line Interface (CLI) is a command line management tool for the AS 7 domain or a standalone server. It allows a user to connect to the AS7 domain controller or a standalone server and execute management operations available through the http://community.jboss.org/docs/DOC-16317 AS7 detyped management model. Depending on the operation system, the CLI is launched using jboss-admin.sh or jboss-admin.bat located in the AS7 bin directory.
h2. Features
The CLI features include:
* connect to the specific controller or server instance by specifying the host and the port;
* send operation requests (providing the managed component's address, attribute or operation name and parameters) following the http://community.jboss.org/docs/DOC-16317 AS7 detyped management model;
* view the available managed components, their attributes and operations;
* tab-completion for commands and operation requests;
* history of the executed commands and operation requests.
h2. Commands
There are commands and operations. Commands don't trigger server management actions, they are performed locally and may affect only the command line session settings. Operations, on the other hand, are actually translated into the operation requests and sent for the execution to the server.
To syntactically differentiate between the commands and the operations, the commands start with '/', e.g. '/help' which, btw, lists all the supported commands, options and other useful info. Another way to list all the supported commands is to type '/' and press the tab key.
h3. Connection
The first thing to do after the CLI has started is to connect to a managed AS7 instance. This is done using the connect command, e.g.
/connect
which is equivalent to
/connect localhost:9999
localhost:9999 is the default host and port combination for the AS7 model controller client. Both, the host and the port, are optional parameters and can be specified together or separately.
h3. Quit
To terminate the session type '/quit'.
h2. Operation requests
The format for the operation requests is
[node-type=node-name (,node-type=node-name)*] : operation-name [( [parameter-name=parameter-value (,parameter-name=parameter-value)*] )]
e.g.
profile=production,subsystem=threads,bounded-queue-thread-pool=pool1:write-core-threads (count=0, per-cpu=20)
It's a lot of typing but tab-completion is supported for all the composing parts, i.e. node-types and node-names, operation names and parameter names. We are also looking into adding custom commands/aliases that would be less verbose for the user but would translate into the corresponding operation requests on the background.
Whitespaces between the separators in the operation request strings are not significant.
Operation requests might not always have the address part or the parameters. E.g.
:read-resource
which will list all the root node types. Notice that ':' is still required before the operation name. This is not to confuse the tab-completion which will consider any string not prefix with ':' as a beginning of a node-type.
h3. How the tab-completion works
Suppose, the cursor is positioned at the beginning of an empty line. Pressing the tab key in this case will print a list of all the available node types. After selecting the node type you want and adding '=', pressing the tab key again will result in a list of all the node names available for the chosen node type. If, after selecting the node name from the list, you want to continue with the node path then add ',' after the selected node name and press the tab key again. This will print all the available node types for the previously select node.
After you are done with the node path, adding ':' at the end of the node path and pressing the tab key will print all the available operation names for the selected node.
To see all the parameters of the operation, add '(' after the operation name and press the tab key. Choose the parameter you want and specify its value after '='. Tab-completion for parameter values is not supported yet. If you want to add more parameters, add ',' and press the tab key to see the rest of the available parameter names.
Finally, when all the parameters have been specified, add ')' and press enter.
h2. Node path prefix
If you want to execute a series of operations against the same node, to avoid typing the same node path for every operation request you can set the current node path prefix to the target node using command '/prefix' or its shorter form '/to', e.g.
[~]/to subsystem=logging
After that the command line prompt will change to
[subsystem=logging]
and every operation entered w/o the node path will be executed against the node subsystem=logging. If you do specify a node path for the operation, it will be prefixed with subsystem=logging, in other words it will be relative to subsystem=logging.
The prefix might not necessarily end on a node name. It might be just
[~]/to subsystem
[subsystem]
Then to execute an operation against the logging subsystem you would type in
[subsystem] logging:read-resource
To reset the current prefix type in
[subsystem] /to ~
[~]
You can also navogate to the parent node
[subsystem=web,connector=http] /to ..
[subsystem=web]
or the node type
[subsystem=web] /to .type
[subsystem]
TODO: the node path tab-completion isn't supported for the argument of '/to' at the moment.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16581]
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 Configuration
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Configuration"
To view the document, visit: http://community.jboss.org/docs/DOC-16494
--------------------------------------------------------------
This document is to list the configuration required to secure the management APIs. Some of these tasks may be taken care of within other tasks but this is a general overview.
h3. Overall Domain Management Security
Currently no top level element to hold this although should probably be a child of some 'domain-management' element.
h3. Existing Configuration
Currently the domain management configuration is limited to options to specify which management APIs to expose and for nodes where to locate the domain controller.
h4. Standalone Configuration
For standalone servers the following can be defined within the standalone.xml :-
<management>
<native-api interface="default" port="9999"/>
<http-api interface="default" port="9990"/>
</management>
i.e. At this stage the only configuration is to identify which APIs to expose publicly.
h4. Domain Configuration
For domain deployments the following can be defined in the host.xml :-
<management>
<native-api interface="public" port="9999"/>
<http-api interface="public" port="9990"/>
</management>
i.e. As before the APIs to expose can be defined on a host by host basis.
The node which has the master domain controller can also have the following: -
<domain-controller>
<local/>
</domain-controller>
This is simple as the sole purpose is to indicate that this node manages the domain locally so does not need to work with any remote domain controller.
If the node will use a remote domain controller it may have the following defined instead: -
<domain-controller>
<remote host="127.0.0.1" port="9999"/>
</domain-controller>
This is defining a connection to the native-api of the node with the master domain controller.
At this stage there is no centralised configuration for domain management.
h3. Future Requirements
h4. Authentication (Internal)
The following document contains some information regarding the requirements for the back end authentication to the existing infrastructure: -
http://community.jboss.org/docs/DOC-16574 Management API Security Authentication Mechanisms
The following document then shows a couple of starting points to consider how configuration of the authentication could fit within the three descriptors: -
http://community.jboss.org/docs/DOC-16576 Management API Security Possible Configuration Samples
h4. Host to Domain Controller Communication
I am planning that the hosts are just another type of user when they connect to the domain controller, the following article explorers the options we will support with some initial ideas relating to the configuration.
http://community.jboss.org/docs/DOC-16579 Management API Security Host to Domain Controller Security
h3. Transport Level Configuration
Two transports will be made available, the current configuration is as: -
<management>
<native-api interface="default" port="9999"/>
<http-api interface="default" port="9990"/>
</management>
Could this be renamed management-api ?
At the transport level the following options may be required: -
* Authentication mechanism e.g. BASIC / DIGEST / CLIENT-CERT
* SSL Certificates* These are very much host specific as there should be a mapping between the name in the certificate and the hostname used to connect to the management API.
Other than the final certificate selection could this be made generic at the domain level? i.e. Select username/password or certificate for identification?
Is SSL going to be mandatory for all communication or optional? If mandatory DIGEST could easily be ommitted.
Kerberos / SPNEGO based authentication at some point in the future?
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16494]
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 Host to Domain Controller Security
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Host to Domain Controller Security"
To view the document, visit: http://community.jboss.org/docs/DOC-16579
--------------------------------------------------------------
h1. Host to Domain Controller Security
Once a host connects to the domain controller the host can obtain the full domain model and the relevent deployments from the domain controller, this connection needs to be secured to ensure that only valid hosts can connect to the domain controller and retrieve this configuration.
After the authenticate everywhere / token based authentication discussion this may need refining but starting with the assumption of authenticate everwhere this can be secured as follows.
These considerations only apply to domain based installations as there is no host -> domain controller connection for standalone installations. This does lead to the risk that for shared XML schemas some items could be added that are not relevent to standalone although these could be handled with suitable error notifications.
h2.
Same Mechanism as User Authentication / Authorization
User authentication and authorization will be implemented anyway, for this reason I propose that the connection to the domain controller from the host will be secured in exactly the same way.
The host then becomes a user that requires a specific set of priviledges.
h3. Shared Secret
For this scenario this will be username / password authentication as the host establishes the connection to the domain controller.
The following PicketBox discussion is regarding any new capabilities being added to aid password encryption/obfuscation so we can try and take advantage of what will be available: -
http://community.jboss.org/thread/163545 AS7 Password Encryption / Obfuscation
By default the username used for the connection will be the name of the host but it will be possible to override this.
The password can either be passed in using the command line or can be defined in the host.xml. Using the command line can be simpler for some but it does cause concerns where command line arguments can be seen when listing running processes.
One possible host.xml configuration could look like: -
<host xmlns="urn:jboss:domain:1.0">
...
<domain-controller>
<remote host="192.168.100.1" port="9999"
userName="host_a" password="my_secret" />
</domain-controller>
...
</host>
Alternatively a child element could be added to <remote> to allow different client side authentication mechanisms to be define.
h3. Certificate Based Authentication
The following discussion is regarding the capabilities that PicketBox will be able to provide that we will re-use for this scenario: -
AS7: Construct for centralized security
The connection over the Native API will be a SSL/TLS connection, both the domain controller node and the host will have a certificate and this will be used on the domain controller side to authenticate the host. Optionally it will also be possible to configure the host for verification of the domain controllers certificate.
This connection is persistent so the authentication will only occur at the stage the connection is created and negotiated.
This would be adjusted based on the discussion linked above but in principal information relating to the keystores / truststores will need to be define on the <remote> element: -
<host xmlns="urn:jboss:domain:1.0">
...
<domain-controller>
<remote host="192.168.100.1" port="9999"
keystore="host.keystore" truststore="domain_controller.truststore" />
</domain-controller>
...
</host>
(There will be quite few additional attributes required such as alias selection, control of hostname verification, passwords to access the stores ...)
h2. Access Control
The access control mechanism is still to be defined as it is not a primary requirement for this current phase of development.
However for the perspective of host actions I would anticipate that there would be an ACL definition for something similar to 'joinDomain', this priviledge will only be granted to accounts allowed to join the domain - further consideration will be required but this could also be extended for things like listing server groups that a host can run.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16579]
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
[PicketBox Development] - Security Domain Selector
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] created the discussion
"Security Domain Selector"
To view the discussion, visit: http://community.jboss.org/message/590996#590996
--------------------------------------------------------------
I am not sure if this has ever come up elsewhere but in a couple of places I have seen a potential need for a more advanced selection of a security domain than our current one-to-one mapping of security domain to secured resource.
When there is a single login module that performs both the authentication check and loads the roles then the flag can quite often be used to allow modules to fail and pass through to the next module in the list until one succeeds, however once you start to have pairs of modules chained together this fall through starts to become difficult.
One place that I saw this was within JBoss Negotiation where the SPNEGOLoginModule is chained with another module to load the roles - when it came to adding support for username/password fallback the chaining of the modules became too complex and I have ended up with one module calling out to another domain if it should fall back to username/password authentication.
Within AS7 there is also potentially a similar issue - in the domain controller we may in general want the exposed API to be accessed using a username and password when administrators are connecting - however the same connection is also used by the remote hosts that are connecting to the domain controller, in this case we may prefer that they identify themselves based on their certificate.
For both of these it could be easier if there were some location to possibly plug in some kind of security domain selector so the correct security domain can be selected based on the context of the call.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/590996#590996]
Start a new discussion in PicketBox Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 2 months