[JBoss AS7 Development] - AS7 Network Ports
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"AS7 Network Ports"
To view the document, visit: http://community.jboss.org/docs/DOC-16507
--------------------------------------------------------------
This article will act as a resource to determine the various ports that AS7 can open. It needs to be updated whenever a new port is opened or changed or removed.
Readers are encouraged to see the "Interfaces" and "Sockets and Socket Binding Groups" discussions in the http://community.jboss.org/docs/DOC-16068 AS 7 Users Guide.
The ports available for use can be determined from the standalone.xml config file, or the domain.xml and host.xml config files if the server is running in domain mode.
The current trunk copy of these files are at:
https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/... standalone.xml
https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/... domain.xml
https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/... host.xml
The available ports come from two sections:
h5. Sockets Used by Subsystems
<socket-binding-group name="standard-sockets" default-interface="default">
<socket-binding name="jndi" port="1099"/>
<socket-binding name="jmx-connector-registry" port="1090"/>
<socket-binding name="jmx-connector-server" port="1091"/>
<socket-binding name="http" port="8080"/>
<socket-binding name="https" port="8447"/>
<socket-binding name="osgi-http" port="8090"/>
<socket-binding name="remoting" port="4447"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<socket-binding name="txn-socket-process-id" port="4714"/>
<socket-binding name="messaging" port="5445"/>
<socket-binding name="messaging-throughput" port="5455"/>
</socket-binding-group>
This provides the basic socket definitions for sockets used by subsystems. It provides a "palette" of available socket definitions. Whether a given definition is used to actually create a socket depends on whether a subsystem accesses it. Generally, the "name" attribute should give some indication of the intended use.
Subsystems reference the socket definition by name as part of their own configuration. For example here is a section of the messaging subsystem configuration that configures the connectors HornetQ uses:
<connectors>
<in-vm-connector name="in-vm" server-id="0"/>
<netty-connector name="netty" socket-binding="messaging"/>
<netty-connector name="netty-throughput" socket-binding="messaging-throughput">
<param key="batch-delay" value="50"/>
</netty-connector>
</connectors>
The "socket-binding" attributes are references to the socket binding definitions. Different subsystems may use different attribute names for such references.
(We'll try to not include socket definitions in our standard config files unless a subsystem in the config file is going to use it. But development is fluid so this may not always be strictly followed.)
h5. Management Sockets
<management>
<native-api interface="default" port="9999"/>
<http-api interface="default" port="9990"/>
</management>
Above is found in standalone.xml and host.xml. This defines the ports opened for use by management clients wishing to administer the server. (Note: this configuration section is still undergoing significant development and is likely to change. For sure how it looks will change for standalone.xml, since for a standalone server the socket information should come from the socket-binding-group section shown above.)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16507]
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
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 Possible Configuration Samples
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Possible Configuration Samples"
To view the document, visit: http://community.jboss.org/docs/DOC-16576
--------------------------------------------------------------
h1. Management API Security Possible Configuration Samples
When defining the management API security there are a couple of options regarding how we could structure the configuration, for these options we also need to consider how it will look for both domain deployments and for a standalone server.
So far these samples show the authentication configuration, the ACLs for authorization still need to be considered.
h2. Host Focussed Configuration (Authentication)
For "Host Focussed" the bulk of the configuration would be in the host.xml.
h3. Domain Example
*domain.xml*
<?xml version="1.0" ?>
<domain xmlns="urn:jboss:domain:1.0">
...
</domain>
*host.xml*
<?xml version="1.0" ?>
<host xmlns="urn:jboss:domain:1.0">
...
<management>
<datasource-pools>
<pool name="UsersDatabase">
<pool-option name="driver" value="org.something.JDBCDriver"/>
<pool-option name="url" value="db://somehost:someport"/>
</pool>
</datasource-pools>
<security>
<security-domain>
<login-module code="Database" flag="required">
<module-option name="PoolName" value="UsersDatabase" />
</login-module>
</security-domain>
</security>
<native-api interface="public" port="9991"/>
<http-api interface="public" port="9992"/>
</management>
<domain-controller>
<remote host="127.0.0.1" port="9999"/>
</domain-controller>
...
</host>
h3. Standalone Example
*standalone.xml*
<server xmlns="urn:jboss:domain:1.0"
...
<management>
<datasource-pools>
<pool name="UsersDatabase">
<pool-option name="driver" value="org.something.JDBCDriver"/>
<pool-option name="url" value="db://somehost:someport"/>
</pool>
</datasource-pools>
<security>
<security-domain>
<login-module code="Database" flag="required">
<module-option name="PoolName" value="UsersDatabase" />
</login-module>
</security-domain>
</security>
<native-api interface="public" port="9991"/>
<http-api interface="public" port="9992"/>
</management>
...
</server>
h2. Domain Central Configuration (Authentication)
For "Domain Central" configuration as much of the configuration as possible will be in the domain.xml, remote nodes will recieve this configuration when they connect to the master domain controller.
h3. Domain Example
*domain.xml*
<?xml version="1.0" ?>
<domain xmlns="urn:jboss:domain:1.0">
...
<management>
<datasource-pools>
<pool name="UsersDatabase">
<pool-option name="driver" value="org.something.JDBCDriver"/>
<pool-option name="url" value="db://somehost:someport"/>
</pool>
</datasource-pools>
<security>
<security-domain>
<login-module code="Database" flag="required">
<module-option name="PoolName" value="UsersDatabase" />
</login-module>
</security-domain>
</security>
</management>
...
</domain>
*host.xml*
<?xml version="1.0" ?>
<host xmlns="urn:jboss:domain:1.0">
...
<management-apis>
<native-api interface="public" port="9991"/>
<http-api interface="public" port="9992"/>
</management-apis>
<domain-controller> <remote host="127.0.0.1" port="9999"/>
</domain-controller>
...
</host>
h3. Standalone Example
*standalone.xml*
<server xmlns="urn:jboss:domain:1.0"
...
<management>
<datasource-pools>
<pool name="UsersDatabase">
<pool-option name="driver" value="org.something.JDBCDriver"/>
<pool-option name="url" value="db://somehost:someport"/>
</pool>
</datasource-pools>
<security>
<security-domain>
<login-module code="Database" flag="required">
<module-option name="PoolName" value="UsersDatabase" />
</login-module>
</security-domain>
</security>
</management>
<management-apis>
<native-api interface="public" port="9991"/>
<http-api interface="public" port="9992"/>
</management-apis>
...
</server>
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16576]
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
[IronJacamar Development] - Re: IronJacamar RHQ plugin development
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] created the discussion
"Re: IronJacamar RHQ plugin development"
To view the discussion, visit: http://community.jboss.org/message/590675#590675
--------------------------------------------------------------
> 1. For the code structure, we will create 2 sub packages for implementation of AS7, ironjacamar standalone separately. The most common functions will be abstracted to the package: *+org.jboss.jca.rhq.core+*,
>
> And the build process will create 2 jars like:
> * ironjacamar-rhq-plugin-as7.jar // used in AS 7
> * ironjacamar-rhq-plugin-standalone.jar // used in ironjacamar standalone mode
>
> except we can find a way to know which situation the current runtime environment is in.
That is the job of the Discover process - default being a discovery against an in-vm instance. I'll take a look at this soon.
> 2. If the *+org.jboss.jca.core.api.management.ManagementRepository+* can be transferred to RHQ plugin in all situations, we can use it directly without abstracting our own model for this RHQ plugin. This class is used only for RHQ to discover JCA resources.
ManagementRepository is the instance that lives in the same VM as the container, and will delegate all calls in-vm.
So in case of a plugin connecting to a remove instance you'll need a "proxy" to handle that communication:
In-VM:
------
RHQ Plugin -> Embedded discovery -> ManagementRepository
Remote VM:
----------
RHQ Plugin -> Remote discovery -> Network transport -> RemoteManagementRepository -> ManagementRepository
Of course we can have a facade for ManagementRepository in the plugin such that communication can be optimized in the remote scenario, since in some instances a query for configuration property names will limit network bandwidth.
The ManagementRepository should always delegate calls to dynamic attributes and operations. In most cases we can handle that by supplying a WeakReference to the actual object, and just call directly. We just need to expose the information we need in the right locations - like the .api...Pool class.
However, currently the focus on the purely embedded case - using IronJacamar/Embedded for testing, and IronJacamar/AS7 for real data.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/590675#590675]
Start a new discussion in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 2 months
[JBoss AS7 Development] - Management API Security Authentication Mechanisms
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"Management API Security Authentication Mechanisms"
To view the document, visit: http://community.jboss.org/docs/DOC-16574
--------------------------------------------------------------
h1. Authentication Mechanisms
Outside of the discussion regarding how authentication will occur at the protocol level and how this will be cached there will still be a need for an authentication against store of users.
JBoss AS has always shipped with a simple solution that can be used out of the box for the definition of users and their roles, in addition to this there is also a requirement for integration with existing infrastructure so for the initial release I believe we should make the following mechanisms available: -
h3.
Property File
This is the simplest mechanism currently in use today, one property file is created containing the users and their password and a second property file is created containing the list of roles to assign to each user.
The property file would be placed within a configurable location which in general would be within the JBoss AS installation.
Each AS node would contain it's own copy of the properties files.
At a later point we could review an option for a node to retrieve the properties file from the domain controller on start up but that is not required at this stage.
h3.
Database Login
Within existing security infrastructure user account information is commonly stored within a database, we will support the configuration of authentication against a database.
When running in domain controller mode the management API security will be outside the context of a running AS so we may also need an alternative connection pool mechanism to manage the connection to the database.
h3. LDAP Login
Another location commonly used to store user account information is within a directory server accessible using LDAP, we will also support the configuration of authentication against LDAP.
h3. Master Domain Controller
Depending on some other discussions we may have a requirement for clients to be able to establish a connection to each node and authenticate against that node.
Reviewing different mechanisms for the configuration used on the master domain controller to be replicated to the individual nodes is possible but there may still be scenarios where it is not desirable for the exact same mechanism to be used on the non-domain controller nodes, a couple of examples are: -
* Nodes running on restricted network, only outbound communication is to the domain controller.* The domain controller may be on a different network with less restricted access so whilst the domain controller can connect to the corporate LDAP server or Database this is not possible from the nodes running the AS instances.
* Using properties files but do not wish to replicate these across an entire estate of AS nodes.
There is a trade off between simplifying the configuration and performance but I believe that should be reviewed on an installation by installation basis so I am proposing that we add an authentication mechanism that can be used on slave DCs to call the master-DC to perform authentication. This will allow the master-DC to act as a proxy for the authentication.
This option should however not be mandatory so it's use can be restricted to where it is considered appropriate.
h2.
Implementation
The management APIs and domain controller can be running outside the scope of a running server however we do still have msc available for services. A lot of the required functionality is already made available by PicketBox so the implementation would be along the lines of: -
* Define the configuration for the management API security and where possible re-use the XML types already defined for the security integration.
* Implement a custom parser for the management API security parsing but where possible review where some re-use of the existing security parsers can be used - especially for the re-used XML types.
* Either: -* Ensure the security integration operations can work both within a running server and within a domain controller process without the server.
* Modify the security integration operations so they have a common abstract base with extensions specific to either domain mode or server mode.
* Inbound calls will then be intercepted at a suitable point for the integrated security subsystem to be called to perform the actual authentication.
At this stage the only required authorization check is that we have an authenticated user, more advanced authorization will be defined in another document.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16574]
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. 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