< Previous | Front page | Next >
Skip to end of metadata
Go to start of metadata

Introduction

As of WildFly 11 a common configuration framework has been introduced for use by the client libraries to define configuration, this allows for the configuration to be shared across multiple clients rather than relying on their own configuration files. As an example the configuration used by an EJB client can be shared with the JBoss CLI, if both of these required SSL configuration this can now be defined once and re-used.

Programatic APIs are also available for many of the options however this document is focusing on the configuration available within the common wildfly-config.xml configuration file.

wildfly-config.xml Discovery

At the time a client requires access to its configuration, the class path is scanned for a wildfly-config.xml or META-INF/wildfly-config.xml file. Once the file is located the configuration will be parsed to be made available for that client.

Alternatively, the wildfly.config.url system property can also be specified to identify the location of the configuration that should be used.

Configuration Sections

<authentication-client /> - WildFly Elytron

The <authentication-client/> element can be added to the wildfly-config.xml configuration to define configuration in relation to authentication configuration for outbound connections and SSL configuration for outbound connections e.g.

Note: A single wildfly-config.xml could be used by multiple projects using multiple versions of Wildfly Elytron, newer versions of WildFly Elytron will introduce new configuration using later namespace versions however they will still continue to support the previously released schemas until advertised otherwise. For the configuration to be compatible with this either use a schema and namespace compatible with all the versions in use, or multiple authentication-client elements can be added, these should be added ordered by namespace youngest to oldest. If a configuration with a later namespace is discovered by a newer WildFly Elytron client it will be used and parsing will not look for an older version as well.

The <authentication-client /> configuration can contain the following sections: -

  • <credential-stores /> - Definitions of credential stores to be referenced from elsewhere in the configuration.
  • <key-stores /> - Definitions of KeyStores to be referenced elsewhere in the configuration.
  • <authentication-rules /> - Rules to be applied for outbound connections to match against an appropriate authentication configuration.
  • <authentication-configurations /> - The individual authentication configurations that will be matched by the authentication rules.
  • <net-authenticator /> - Flag to enable integration with the java.net.Authenticator.
  • <ssl-context-rules /> - Rules to be applied for outbound connections to match against an appropriate SSL context configuration.
  • <ssl-contexts /> - Individual SSL context definitions that will be matched by the ssl context rules.
  • <providers/> - Definition of how java.security.Provider instances will be discovered.

<credential-stores />

The <credential-stores /> element can be used to define individual named credential stores that can subsequently be used elsewhere in the configuration to reference stored credentials as an alternative to the credentials being embedded in the configuration.

In addition to the name an individual <credential-store /> definition can contain the following optional attributes: -

  1. type - The type of the credential store, e.g.KeyStoreCredentialStore.
  2. provider - The name of the java.security.Provider to use to load the credential store.

The following child elements can also be added to configure the credential store.

  • <attributes .> - Definition of configuration attributes used to initialise the credential store.

e.g.

The <attribute/> element can be repeated as many times as is required for the configuration.

  • <protection-parameter-credentials /> - One or more credentials to be assembled into a protection parameter when initialising the credential store.

The <protection-paramter-credentials /> element can contain one more more child elements, which of these are actually supported will depend on the credential store implementation: -

The potential child elements of <protection-parameter-credentials /> are: -

  • <key-store-reference> - Defines a reference to an entry within a KeyStore for an entry to use.

The overall structure of this element is: -

This structure is identical to the structure use in <key-store-credential />.

  • <credential-store-reference store="..." alias="..." clear-text="..." /> - Reference to a credential stored in a credential store.
  • <clear-password password="..." /> - A password specified in the clear.
  • <key-pair public-key-pem="..." private-key-pem="..." /> - A public and private key pair.
  • <certificate private-key-pem="..." pem="..." />* - A pem encoded private key and corresponding certificate.
  • <public-key-pem>...</public-key-pem> - A pem encoded public key.
  • <bearer-token value="..." />* - A bearer token
  • <oauth2-bearer-token>...</oauth2-bearer-token> - An oath2 bearer token.

The full structure of this element is: -

<key-stores />

The <key-stores /> element can be used to define individual key-store definitions that can subsequently be referenced from alternative locations within the configuration.

An individual <key-store /> definition must contain exactly one of the following elements to define where to load the store from.

  1. <file name="..." /> - Load from file where 'name' is the name of the file.
  2. <load-from uri="..." /> - Load the file from the URI specified.
  3. <resource name="..." /> - Load as a resource from the Thread context classloader where 'name' is the name of the resource to load.

Exactly one of the following elements must also be present to specify the protection parameter for initialisation of the KeyStore.

  1. <key-store-clear-password password="..." /> - A password specified in the clear.
  2. <key-store-credential>...</key-store-credential> - A reference to another KeyStore to obtain an Entry to use as the protection parameter to access this KeyStore.


The structure of the <key-store-credential /> element is.

This element contains two attributes: -

  1. key-store-name (Mandatory) - Name of the KeyStore being referenced to load the entry from.
  2. alias (Optional) - The alias of the entry to load from the referenced KeyStore, this can only be omitted for KeyStores that contain only a single entry.

Java KeyStores also make use of a protection parameter when accessing a single entry in addition to the protection parameter to load the KeyStore, exactly one of the following elements must be present to specify the protection parameter of the entry being loaded.

  1. <key-store-clear-password password="..." /> - A password specified in the clear.
  2. <credential-store-reference store="..." alias="..." clear-text="..." /> - Reference to a credential stored in a credential store.
  3. <key-store-credential>...</key-store-credential> - A reference to another KeyStore to obtain an Entry to use as the protection parameter to access the alias.

The <key-store-credential /> is exactly the same, this means theoretically a chain of references could be used to lead to the unlocking of the required alias.

<authentication-rules /> and <ssl-context-rules />

When either an authentication-configuration or an ssl-context is required the URI of the resources being accessed as well as an optional abstract type and abstract type authority and matched against the rules defined in the configuration to identify which authentication-configuration or ssl-context should be used.

The rules to match <authentication-configuration /> instances are defined within the <authentication-rules /> element.

The rules to match against the <ssl-context /> definitions are contains within the <ssl-context-rules /> element.

Overall this means that authentication configuration matching is independent of SSLContext matching. By separating the rules from the configurations is means multiple rules can be defined that match against the same configuration.

The rules applied so first match wins and not most specific match wins, to achieve a most specific match wins configuration place the most specific rules at the beginning leaving the more general matches towards the end.

For both the <authentication-rules /> and the <ssl-context-rules /> the structure of the rules is identical other than one references an authentication configuration and the other references an SSLContext.

Where multiple matches are defined within a rule they must all match for the rule to apply. If a rule is defined with no match elements then it becomes a match all rule and will match anything, these can be useful at the end of the configuration to ensure something matches.

The individual match elements are: -

  • <match-no-user /> - user-info can be embedded within a URI, this rule matches when there is no user-info.
  • *<match-user name="..." /> - Matches when the user-info embedded in the URI matches the name specified within this element.
  • *<match-protocol name="..." /> - Matches the protocol within the URI against the name specified in this match element.
  • *<match-host-name name="..." /> - Matches the host name from within the URI against the name specified in this match element.
  • *<match-path name="..." /> - Matches the path from the URI against the name specified in this match element.
  • *<match-port number="..." /> - Matches the port number specified within the URI against the number in this match element. This only matches against the number specified within the URI and not against any default derrived from the protocol.
  • *<match-urn name="..." />" - Matches the scheme specific part of the URI against the name specified within this element.
  • <match-domain-name name="..."/>* - Matches where the protocol of the URI is 'domain' and the scheme specific part of the URI is the name specified within this match element.
  • <match-abstract-type name="..." authority="..." /> - Matches the abstract type and/or authority against the values specified within this match element.

<authentication-configurations />

The <authentication-configurations /> element contains named configurations that can then be matched from the <authentication-rules />

The elements within the <configuration /> element provide the following features: -

The first three elements override the destination.

  • <set-host-name name="..." /> - Override the host name for the authenticated call.
  • <set-port-number number="..." /> - Override the port number for the authenticated call.
  • <set-protocol name="..."/> - Override the protocol for the authenticated call.

The next two are mutually exclusive and can be used to set the name for authentication or switch to anonymous authentication.

  • <set-user-name name="..."/> - Set the user name to use for authentication.
  • <set-anonymous /> - Switch to anonymous authentication.
  • <set-mechanism-realm-name name="..." /> - Specify the name of the realm that will be selected by the SASL mechanism if required.
  • <rewrite-user-name-regex pattern="..." replacement="..." /> - A regular expression pattern and replacement to re-write the user name used for authentication.
  • <sasl-mechanism-selector selector="..." /> - A SASL mechanism selector using the syntax from org.wildfly.security.sasl.SaslMechanismSelector,fromString()
  • <set-mechanism-properties>...</set-mechanism-properties> - One or more properties defined as <property key="..." value="..." /> to be passed to the authentication mechanisms.
  • <credentials>...</credentials> - One or more credentials available for use during authentication.

The content of this element is the same as documented for <protection-parameter-credentials />

  • <set-authorization-name name="..." /> - Specify the name that should be used for authorization if different from the authentication identity.
  • <providers/> - This element is described in more detail within <providers /> and overrides the default or inherited provider discovery with a definition specific to this authentication configuration definition.

The final two elements are mutually exclusive and define how the SASL mechanism factories will be discovered for authentication.

  • <use-provider-sasl-factory /> - The java.security.Provider instances either inherited or defined in this configuration will be used to locate the available SASL client factories.
  • <use-service-loader-sasl-factory module-name="..." /> - SASL client factories will be discovered using service loader discovery on the specified module or if not specified using the ClassLoader loading the configuration.

<net-authenticator />

This element contains no specific configuration, however if present the org.wildfly.security.auth.util.ElytronAuthenticator will be registered with java.net.Authenticator.setDefault(Authenticator) meaning that the WildFly Elytron authentication client configuration can be used for authentication where the JDK APIs are used for HTTP calls which require authentication.

There are some limitations within this integration as the JDK will cache the authentication JVM wide from the first call so is better used in stand alone processes that don't require different credentials for different calls to the same URI,

<ssl-contexts />

The <ssl-contexts /> element holds individual names SSLContext definitions that can subsequently be matched by the <ssl-context-rules />.

The element <default-ssl-context name="..." /> simply takes the SSLContext obtainable from javax.net.ssl.SSLContext.getDefault() and assigns it a name so it can referenced from the <ssl-context-rules />. This element can be repeated meaning the default SSLContext can be referenced using different names.

The element <ssl-context /> is used to define a named configured SSLContext, each of the child elements is optional and can be specified at most once to build up the configuration of the SSLContext.

  • <key-store-ssl-certificate> - Defines a reference to an entry within a KeyStore for the key and certificate to use in this SSLContext.

The overall structure of this element is: -

This structure is identical to the structure use in <key-store-credential />, the only difference being it is now to obtain the entry for the key and certificate, the nested elements however remain the protection parameter to unlock the entry.

  • <trust-store-key-store-name /> - A reference to a KeyStore that will be used to initialise the TrustManager.

The following would be a cipher suite selector performing the default filtering.

  • <protocol /> - used to define a space separated list of the protocols to be supported.
  • <provider-name /> - Once the available providers have been identified only the provider with the name defined on this element will be used.
  • <providers/> - This element is described in more detail within <providers /> and overrides the default or inherited provider discovery with a definition specific to this SSLContext definition.
  • <certificate-revocation-list /> - The presence of this element enabled checking the peer's certificate against a certificate revocation list, this element defines both a path to the certificate revocation list and also specifies the maximum number of non-self-issued intermediate certificates that may exist in a certification path

<providers />

The <providers /> element is used to define how java.security.Provider instances are located when required. The other configuration sections of <authentication-client /> are independent of each other, the <providers /> configuration however applies to the current element and it's children unless overridden, this configuration can be specified in the following locations.

If an individual <credential-store />, <authentication-configuration />, or <ssl-context /> contains a <providers /> definition that that definition will apply specifically to that instance. If a configured item does not contain a <providers /> definition but a top level <providers /> is defined within <authentication-configuration /> then that will be used instead.

The <providers /> element can be defined as: -

Both the child elements are optional, can appear in any order and can be repeated although repeating <global /> would not really be beneficial.

  • <global /> - The providers from java.security.Security.getProviders()
  • <credential-stores /> - Providers loaded using service loader discovery from the module specified, if no module is specified the ClassLoader which loaded the authentication client is used.

Where no <provider /> configuration exists the default behaviour is the equivalent of: -

This gives the WildFly Elytron Provider priority over any globally registered Providers but also allows for the globally registered providers to be used.

<jboss-ejb-client /> - EJB Client

The <jboss-ejb-client /> element in a wildfly-config.xml file can be used to specify EJB Client configuration. This element is from the “urn:jboss:wildfly-client-ejb:3.0” namespace, e.g.

This section describes the child elements and attributes that can be configured within this element.

The <jboss-ejb-client /> element can optionally contain the following three child elements, as described in the next sections:

  • <invocation-timeout />
  • <global-interceptors />
  • <connections />

<invocation-timeout />

This element is used to specify an EJB invocation timeout. It has one attribute which is required:

Attribute
Description
seconds
The timeout, in seconds, for the EJB handshake or method invocation request/response cycle. The invocation of any method throws a java.util.concurrent.TimeoutException if the execution takes longer than the timeout period. The server side will not be interrupted.

<global-interceptors />

This element is used to specify global EJB client interceptors. It can contain any number of <interceptor /> elements.

<interceptor />

This element is used to specify an EJB client interceptor. It has two attributes:

Attribute
Description
class
The name of a class that implements the org.jboss.ejb.client.EJBClientInterceptor interface.
module
The optional name of the module that should be used to load the interceptor class.

<connections />

This element is used to specify EJB client connections. It can contain any number of <connection /> elements.

<connection />

This element is used to specify an EJB client connection. It has one required attribute. It can also optionally contain an <interceptors /> element.

Attribute
Description
uri
The connection destination URI.

<interceptors />

This element is used to specify EJB client interceptors and can contain any number of <interceptor /> elements.

<endpoint /> - Remoting Client

You can use the endpoint element, which is in the urn:jboss-remoting:5.0 namespace, to configure a JBoss Remoting client endpoint using the wildfly-config.xml file. This section describes how to configure a JBoss Remoting client using this element.

This section describes the child elements and attributes that can be configured within this element.

The <endpoint /> element contains the following optional attribute:

Attribute Name Attribute Description
name The endpoint name. If not given, an endpoint name will be derived from the system's host name, if possible.

The <endpoint /> element can optionally contain the following two child elements, as described in the next sections:

  • <providers />
  • <connections />

The configured endpoint will use the default XNIO configuration.

<providers />

This optional element specifies transport providers for the remote endpoint. It can contain any number of <provider /> sub-elements.

<provider />

This element defines a remote transport provider provider. It has the following attributes.

Attribute Name Attribute Description
scheme The primary URI scheme which corresponds to this provider. This attribute is required.
aliases A space-separated list of other URI scheme names that are also recognized for this provider . This attribute is optional.
module The name of the module that contains the provider implementation. This attribute is optional; if not given, the class loader of JBoss Remoting itself will be searched for the provider class.
class The name of the class that implements the transport provider. This attribute is optional; if not given, the Java java.util.ServiceLoader facility will be used to search for the provider class.

This element has no content.

<connections />

This optional element specifies connections for the remote endpoint. It can contain any number of connection elements.

<connection />

This element defines a connection for the remote endpoint. It has the following attributes.

Attribute Name Attribute Description
destination The destination URI for the connection. This attribute is required.
read-timeout The timeout, in seconds, for read operations on the corresponding socket. This attribute is optional, however it should only be given if a heartbeat-interval is defined.
write-timeout The timeout, in seconds, for a write operation. This attribute is optional, however it should only be given if a heartbeat-interval is defined..
ip-traffic-class Defines the numeric IP traffic class to use for this connection's traffic. This attribute is optional.
tcp-keepalive Boolean setting that determines whether to use TCP keepalive. This attribute is optional.
heartbeat-interval The interval, in milliseconds, to use when checking for a connection heartbeat. This attribute is optional.

Example Remoting Client Configuration in the wildfly-config.xml File

<worker /> - XNIO Client

You can use the worker element, which is in the urn:xnio:3.5 namespace, to configure a default XNIO worker using the wildfly-config.xml file. This section describes how to do this.

This section describes the child elements that can be configured within this root worker element.

The <worker /> element can optionally contain the following child elements, as described in the next sections:

  • <daemon-threads />
  • <worker-name />
  • <pool-size />
  • <task-keepalive />
  • <io-threads />
  • <stack-size />
  • <outbound-bind-addresses />

<daemon-threads />

This optional element takes a single required attribute:

Attribute Name Attribute Description
value The value of the setting (required). A value of true indicates that worker and task threads should be daemon threads, and false indicates that they should not be daemon threads. If this element is not given, a value of true is assumed.

This element has no content.

<worker-name />

This element defines the name of the worker. The worker name will appear in thread dumps and in JMX.

Attribute Name Attribute Description
value The worker's name (required).

This element has no content.

<pool-size />

This optional element defines the size parameters of the worker's task thread pool. The following attributes are allowed:

Attribute Name Attribute Description
max-threads A positive integer which specifies the maximum number of threads that should be created (required).

<task-keepalive />

This optional element establishes the keep-alive time of task threads before they may be expired.

Attribute Name Attribute Description
value A positive integer which represents the minimum number of seconds to keep idle threads alive (required).

<io-threads />

This optional element determines how many I/O (selector) threads should be maintained. Generally this number should be a small constant multiple of the number of available cores.

Attribute Name Attribute Description
value A positive integer value for the number of I/O threads (required).

<stack-size />

This optional element establishes the desired minimum thread stack size for worker threads.

Attribute Name Attribute Description
value A positive integer value which indicates the requested stack size, in bytes (required).

<outbound-bind-addresses />

This optional element specifies bind addresses to use for outbound connections. Each bind address mapping consists of a destination IP address block, and a bind address and optional port number to use for connections to destinations within that block.

<bind-address />

This element defines an individual bind address mapping.

Attribute Name Attribute Description
match The IP address block in CIDR notation to match (required).
bind-address The IP address to bind to if the address block matches (required).
bind-port A specific port number to bind to if the address block matches (optional, defaults to 0 meaning "any port").
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.