Remoting WildFly Subsystem Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(43 intermediate revisions by the same user not shown)
Line 2: Line 2:


* [[Remoting WildFly Subsystem]]
* [[Remoting WildFly Subsystem]]
=EAP 7 Note=
In EAP 7, the default remoting connector has changed from "remote" to "http-remoting" and the default remote connection port has changed from 4447 to 8080.
The JNDI provider URL for the default configuration has changed from remote://localhost:4447 to http-remoting://localhost:8080.
The initial context factory class name is <tt>org.jboss.naming.remote.client.InitialContextFactory</tt>.
=JNDI and Remoting=
See {{Internal|WildFly_JNDI_Concepts#JNDI_and_Remoting|JNDI and Remoting}}
=Remoting and the Management Interfaces=
==EAP 6==
<font color=red>TODO: clarify the relationship between the remoting subsystem and the instance's management interfaces. When booting an EAP 6 instance, we get:
<pre>
org.jboss.as.remoting] (MSC service thread 1-5) JBAS017100: Listening on 127.0.0.1:9999
</pre>
which indicates that the management interface (9999) and remoting are related.
</font>
==EAP 7==


=Security=
=Security=
Line 7: Line 36:
Remoting connection attempts are authenticated against a configurable set of authentication mechanisms.
Remoting connection attempts are authenticated against a configurable set of authentication mechanisms.


The presence of the '<tt>security-realm</tt>' attribute in the remoting connector configuration triggers enabling of authentication within the remoting service, by initializing the list of authentication mechanisms to those contributed by the security realm. The "ApplicationRealm" security realm employs "DIGEST" and "LOCAL" security mechanisms.  
The presence of the '<tt>security-realm</tt>' attribute in the remoting connector configuration triggers authentication enforcement within the remoting service, by initializing the list of authentication mechanisms to those contributed by the security realm.  


For more details on the local authentication mechanism see [[WildFly Security Realms#The_.24local_User|the 'LOCAL' authentication mechanism]].
For EAP 6:


Removing '<tt>security-realm="ApplicationRealm"</tt>' from the remoting connector configuration ends up in the installation of the "ANONYMOUS" authentication mechanism, which enforces no authentication.
<pre>
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
  <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
</subsystem>
</pre>


For more details on configuring <tt>security-realm</tt> see <tt>[[Remoting_WildFly_Subsystem_Configuration#security-realm|security-realm]]</tt>.
For EAP 7:


For more on JBoss 7 security, see [[WildFly Security Realms]].
<font color=red>TODO</font>


==Authenticated Remoting Call==
The "ApplicationRealm" security realm employs "DIGEST" and "LOCAL" security mechanisms.


<font color=red>
For more details on the local authentication mechanism see [[WildFly_Security_Realms#Local_File-Based_Authentication_Configuration|the local file-based authentication mechanism]].
How do I inject the credentials on the client so I actually make an authenticated remoting call?
</font>


=Remoting and JMX Access=
Removing '<tt>security-realm="ApplicationRealm"</tt>' from the remoting connector configuration ends up in the installation of the "ANONYMOUS" authentication mechanism, which enforces no authentication.


JBoss Remoting provides the transport of the [[JSR 160 Java Management Extensions (JMX) Remote API|JSR-160 Java Management Extensions (JMX) Remote API]] compliant implementation of a [[JMXConnector]] that can be used by standard monitoring applications (such as [[VisualVM]]) to access the JMX bus. This is why JBoss Remoting configuration and security is relevant when an external JMX client needs access to JBoss.
For more details on configuring <tt>security-realm</tt> see <tt>[[Remoting_WildFly_Subsystem_Configuration#security-realm|security-realm]]</tt>.


For generic concepts related to JMX support in WildFly, see:
For more on JBoss 7 security, see [[WildFly Security Realms]].
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly and JMX#Overview|WildFly and JMX]]
</blockquote>


For details on how to connect various JMX clients to a WildFly instance, see:
==JBoss Remoting Client-Side Programmatic Login==


<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
<span id='Authenticated_Remoting_Call'></span>When JBoss Remoting is used to by a JMX connection, authentication is programmed as described below: "[[Remoting_WildFly_Subsystem_Concepts#Authentication_for_Remoting_JMX_Access|Authentication for Remoting JMX Access]]".
* [[Generic JMX Access to WildFly]]
* [[Using VisualVM with WildFly]]
</blockquote>


=Threading Model=
=Threading Model=
Line 53: Line 77:
:[[WildFly_Threads_Subsystem_Concepts#How_Does_it_Relate_to_Remoting.3F|WildFly Threads Subsystem Concepts]]
:[[WildFly_Threads_Subsystem_Concepts#How_Does_it_Relate_to_Remoting.3F|WildFly Threads Subsystem Concepts]]
</blockquote>
</blockquote>
=Remoting and JMX Access=
JBoss Remoting provides the transport of the [[JSR 160 Java Management Extensions (JMX) Remote API|JSR-160 Java Management Extensions (JMX) Remote API]] compliant implementation of a [[JMXConnector]] that can be used by standard monitoring applications (such as [[VisualVM]]) to access the JMX bus. This is why JBoss Remoting configuration and security is relevant when an external JMX client needs access to JBoss.
For practical details on how various JMX clients can connect to WildFly instances, see:
{{Internal|WildFly and JMX#Overview|WildFly and JMX}}
==Authentication for Remoting JMX Access==
These considerations apply when JBoss Remoting is used to establish an authenticated '''remote JMX connection''' to the JBoss server. During connection initialization, JBoss Remoting runtime looks for an environment key named "jmx.remote.credentials"  ([https://docs.oracle.com/javase/8/docs/api/javax/management/remote/JMXConnector.html#CREDENTIALS javax.management.remote.JMXConnector.CREDENTIALS]), and expects that the corresponding value is a String[2], which in turn is expected to contain the username on the first position and the password on the second. If [https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/RemotingConnector.java org.jboss.remotingjmx.RemotingConnector] instance finds this environment entry, the proper UsernamePasswordCallbackHandler is installed by org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(...) so when an authentication challenge comes from the server, the proper credentials are processed.
Essentially, this is what is needed:
Map<String, Object> environment = new HashMap<>();
String[] payload = new String[] {"my-username", "my-password"};
environment.put(javax.management.remote.JMXConnector.CREDENTIALS, payload);
More details about the server-side digest mechanism used by JBoss can be found here [[WildFly_Security_Realms#The_Digest_Mechanism|JBoss Authentication Digest Mechanism]].

Latest revision as of 07:28, 8 September 2017

Internal

EAP 7 Note

In EAP 7, the default remoting connector has changed from "remote" to "http-remoting" and the default remote connection port has changed from 4447 to 8080.

The JNDI provider URL for the default configuration has changed from remote://localhost:4447 to http-remoting://localhost:8080.

The initial context factory class name is org.jboss.naming.remote.client.InitialContextFactory.

JNDI and Remoting

See

JNDI and Remoting

Remoting and the Management Interfaces

EAP 6

TODO: clarify the relationship between the remoting subsystem and the instance's management interfaces. When booting an EAP 6 instance, we get:

org.jboss.as.remoting] (MSC service thread 1-5) JBAS017100: Listening on 127.0.0.1:9999

which indicates that the management interface (9999) and remoting are related.


EAP 7

Security

Remoting connection attempts are authenticated against a configurable set of authentication mechanisms.

The presence of the 'security-realm' attribute in the remoting connector configuration triggers authentication enforcement within the remoting service, by initializing the list of authentication mechanisms to those contributed by the security realm.

For EAP 6:

<subsystem xmlns="urn:jboss:domain:remoting:1.1">
   <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
</subsystem>

For EAP 7:

TODO

The "ApplicationRealm" security realm employs "DIGEST" and "LOCAL" security mechanisms.

For more details on the local authentication mechanism see the local file-based authentication mechanism.

Removing 'security-realm="ApplicationRealm"' from the remoting connector configuration ends up in the installation of the "ANONYMOUS" authentication mechanism, which enforces no authentication.

For more details on configuring security-realm see security-realm.

For more on JBoss 7 security, see WildFly Security Realms.

JBoss Remoting Client-Side Programmatic Login

When JBoss Remoting is used to by a JMX connection, authentication is programmed as described below: "Authentication for Remoting JMX Access".

Threading Model

All invocations arriving on the subsystem's connectors are handled by the subsystem's threads, which are all grouped under the worker thread pool. Various worker thread pool attributes are configured on the worker-thread-pool element. For more details on configuring the thread pool, see:

<worker-thread-pool> Configuration

Also see:

WildFly Threads Subsystem Concepts

Remoting and JMX Access

JBoss Remoting provides the transport of the JSR-160 Java Management Extensions (JMX) Remote API compliant implementation of a JMXConnector that can be used by standard monitoring applications (such as VisualVM) to access the JMX bus. This is why JBoss Remoting configuration and security is relevant when an external JMX client needs access to JBoss.

For practical details on how various JMX clients can connect to WildFly instances, see:

WildFly and JMX

Authentication for Remoting JMX Access

These considerations apply when JBoss Remoting is used to establish an authenticated remote JMX connection to the JBoss server. During connection initialization, JBoss Remoting runtime looks for an environment key named "jmx.remote.credentials" (javax.management.remote.JMXConnector.CREDENTIALS), and expects that the corresponding value is a String[2], which in turn is expected to contain the username on the first position and the password on the second. If org.jboss.remotingjmx.RemotingConnector instance finds this environment entry, the proper UsernamePasswordCallbackHandler is installed by org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(...) so when an authentication challenge comes from the server, the proper credentials are processed.

Essentially, this is what is needed:

Map<String, Object> environment = new HashMap<>();
String[] payload = new String[] {"my-username", "my-password"};
environment.put(javax.management.remote.JMXConnector.CREDENTIALS, payload);

More details about the server-side digest mechanism used by JBoss can be found here JBoss Authentication Digest Mechanism.