Chapter 1. Securing the Server and Its Interfaces 1.1. Building Blocks 1.1.1. Interfaces and socket bindings JBoss EAP utilizes its host's interfaces, for example inet-address and nic , as well as ports for communication for both its web applications as well as its management interfaces. These interfaces and ports are defined and configured through the interfaces and socket-binding-groups settings in the JBoss EAP. For more information on how to define and configure interfaces and socket-binding-groups , see the Socket Bindings section of the JBoss EAP Configuration Guide . Example: Interfaces <interfaces> <interface name="management"> <inet-address value="USD{jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="USD{jboss.bind.address:127.0.0.1}"/> </interface> </interfaces> Example: Socket Binding Group <socket-binding-group name="standard-sockets" default-interface="public" port-offset="USD{jboss.socket.binding.port-offset:0}"> <socket-binding name="management-http" interface="management" port="USD{jboss.management.http.port:9990}"/> <socket-binding name="management-https" interface="management" port="USD{jboss.management.https.port:9993}"/> <socket-binding name="ajp" port="USD{jboss.ajp.port:8009}"/> <socket-binding name="http" port="USD{jboss.http.port:8080}"/> <socket-binding name="https" port="USD{jboss.https.port:8443}"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group> 1.1.2. Elytron Subsystem 1.1.2.1. Enable Elytron Security Across the Server There is a simple way to enable Elytron across the server. JBoss EAP 7.1 introduced an example configuration script that enables Elytron as the security provider. This script resides in the EAP_HOME /docs/examples directory in the server installation. Execute the following command to enable Elytron security across the server. 1.1.2.2. Create an Elytron Security Domain Security domains in the elytron subsystem, when used in conjunction with security realms, are used for both core management authentication as well as for authentication with applications. Important Deployments are limited to using one Elytron security domain per deployment. Scenarios that may have required multiple legacy security domains can now be accomplished using a single Elytron security domain. Add a Security Domain Using the Management CLI Add a Security Domain Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Other Settings and click View . Select SSL Security Domain and use the Add button to configure a new security domain. 1.1.2.3. Create an Elytron Security Realm Security realms in the elytron subsystem, when used in conjunction with security domains, are used for both core management authentication as well as for authentication with applications. Security realms are also specifically typed based on their identity store, for example jdbc-realm , filesystem-realm , properties-realm , etc. Add a Security Realm Using the Management CLI Examples of adding specific realms, such as jdbc-realm , filesystem-realm , and properties-realm can be found in sections. Add a Security Realm Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Security Realms and click View . Select the appropriate security realm type from the Security Realm tab and click Add to configure a new security realm. 1.1.2.4. Create an Elytron Role Decoder A role decoder converts attributes from the identity provided by the security realm into roles. Role decoders are also specifically typed based on their functionality, for example empty-role-decoder , simple-role-decoder , and custom-role-decoder . Add a Role Decoder Using the Management CLI Add a Role Decoder Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Mappers / Decoders and click View . Click on Role Decoder , select the appropriate role decoder type and click Add to configure a new role decoder. 1.1.2.5. Adding a source-address-role-decoder to the elytron subsystem You can use either the management CLI or the Management Console to add the source-address-role-decoder role decoder to the elytron subsystem. By configuring this role decoder in the mappers element, you make use of the IP address of a client when making authorization decisions. The source-address-role-decoder extracts the IP address of a client and checks if it matches the IP address specified in the pattern attribute or the source-address attribute. If the IP address of the client matches the IP address specified in either attribute then elytron uses the roles attribute to assign roles to the user. Note The procedure uses the management CLI to add source-address-role-decoder to the mappers element in the elytron subsystem. If you want to use the Management Console to complete this task, refer to the link provided in the Additional resources section. Prerequisites Note the IP address of the server's client. Procedure In the elytron subsystem, use the management CLI to add source-address-role-decoder . For a source-address-role-decoder , you must specify an IP address and at least one role for a user. Example of adding the source-address-role-decoder to the mappers element: The example shows a configured source-address-role-decoder , named as decoder1 . When a client attempts to connect to a server, the elytron subsystem uses the source-address-role-decoder to check that the client's IP address matches the IP address that was specified in either the pattern attribute or the source-address attribute. In the example, the source-address-role-decoder checks if the client's IP address is 10.10.10.10 . If the client's IP address is 10.10.10.10 then elytron uses the roles attribute to assign the Administrator role to the user. Note You can configure a source-address-role-decoder to assign specific roles to a user who needs to establish connections from different networks. In the security-domain , reference the configured source-address-role-decoder in the role-decoder attribute. This ensures that an Elytron security domain uses source-address-role-decoder when making authorization decisions. Example of referencing a configured source-address-role-decoder , decoder1 , in the role-decoder attribute: Additional resources For information about adding a role decoder with the management console, see Elytron Subsystem . For information about the elytron subsystem, see Elytron Subsystem in the Security Architecture guide. 1.1.3. Configuring an aggregate-role-decoder to the elytron subsystem The aggregate-role-decoder consists of two or more role decoders. You can use an aggregate-role-decoder to aggregate the roles returned from each role decoder. Prerequisites Configure at least two role decoders in the elytron subsystem. Procedure Add at least two role decoders to the aggregate-role-decoder role decoder. Example of adding decoder1 and decoder2 to the aggregate-role-decoder role decoder: Additional resources For information about available role decoders in the elytron subsystem, see Resources in the Elytron Subsystem in the Security Architecture guide. For information about creating a role decoder, see Elytron Subsystem . 1.1.3.1. Create an Elytron Role Mapper A role mapper maps roles after they have been decoded to other roles. Examples include normalizing role names or adding and removing specific roles from principals after they have been decoded. Role mappers are also specifically typed based on their functionality, for example add-prefix-role-mapper , add-suffix-role-mapper , and constant-role-mapper . Adding a Role Mapper Takes the General Form Adding a Role Mapper Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Mappers / Decoders and click View . Click on Role Mapper , select the appropriate role mapper type and click Add to configure a new role mapper. 1.1.3.2. Create an Elytron Permission Set Permission sets can be used to assign permissions to an identity. Add a Permission Set Using the Management CLI The permissions parameter consists of a set of permissions, where each permission has the following attributes: class-name is the fully qualified class name of the permission. This is the only permission attribute that is required. module is an optional module used to load the permission. target-name is an optional target name passed to the permission as it is constructed. action is an optional action passed to the permission as it is constructed. 1.1.3.3. Create an Elytron Permission Mapper In addition to roles being assigned to a identity, permissions may also be assigned. A permission mapper assigns permissions to an identity. Permission mappers are also specifically typed based on their functionality, for example logical-permission-mapper , simple-permission-mapper , and custom-permission-mapper . Add a Permission Mapper Using the Management CLI Add a Permission Mapper Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Mappers / Decoders and click View . Click on Principal Decoder , select the appropriate principal decoder type and click Add to configure a new principal decoder. 1.1.3.4. Creating an Authentication Configuration An authentication configuration contains the credentials to use when making a connection. For more information on authentication configurations, see Configure Client Authentication with Elytron Client in How to Configure Identity Management for JBoss EAP. Note Instead of a credential store, you can configure an Elytron security domain to use the credentials of the accessing user. For instance, a security domain can be used in conjunction with Kerberos for authenticating incoming users. Follow the instructions in Configure the Elytron Subsystem in How to Set Up SSO with Kerberos for JBoss EAP, and set obtain-kerberos-ticket=true in the Kerberos security factory. Add an Authentication Configuration Using the Management CLI Add an Authentication Configuration Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Other Settings and click View . Click on Authentication Authentication Configuration and click Add to configure a new authentication configuration. For the full list of authentication-configuration attributes, see Elytron Subsystem Components Reference . 1.1.3.5. Creating an Authentication Context An authentication context contains a set of rules and either authentication configurations or SSL contexts to use for establishing a connection. For more information on authentication contexts, see Configure Client Authentication with Elytron Client in How to Configure Identity Management for JBoss EAP. Add an Authentication Context Using the Management CLI An authentication context can be created using the following management CLI command. Typically, an authentication context will contain a set of rules and either an authentication configuration or a SSL context. The following CLI command provides demonstrates defining an authentication context that only functions when the hostname is localhost . Add an Authentication Context Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Other Settings and click View . Click on Authentication Authentication Context and click Add to configure a new authentication context. For the full list of authentication-context attributes, see Elytron Subsystem Components Reference . 1.1.3.6. Create an Elytron Authentication Factory An authentication factory is an authentication policy used for specific authentication mechanisms. Authentication factories are specifically based on the authentication mechanism, for example http-authentication-factory , sasl-authentication-factory and kerberos-security-factory . Add an Authentication Factory Using the Management CLI Add an Authentication Factory Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Factories / Transformers and click View . Click on HTTP Factories , SASL Factories , or Other Factories , choose the appropriate factory type, and click Add to configure a new factory. 1.1.3.7. Create an Elytron Keystore A key-store is the definition of a keystore or truststore including the type of keystore, its location, and the credential for accessing it. To generate an example keystore for use with the elytron subsystem, use the following command: USD keytool -genkeypair -alias localhost -keyalg RSA -keysize 1024 -validity 365 -keystore keystore.jks -dname "CN=localhost" -keypass secret -storepass secret Add a Keystore Using the Management CLI To define a key-store in Elytron that references the newly made keystore, execute the following management CLI command. This command species the path to the keystore, relative to the file system path provided, the credential reference used for accessing the keystore, and the type of keystore. Note The above command uses relative-to to reference the location of the keystore file. Alternatively, you can specify the full path to the keystore in path and omit relative-to . Add a Keystore Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Other Settings and click View . Click on Stores Key Store and click Add to configure a new keystore. 1.1.3.8. Create an Elytron Key Manager A key-manager references a key-store , and is used in conjunction with an SSL context. Add a Key Manager Using the Management CLI The following command specifies the underlying keystore to reference, the algorithm to use when initializing the key manager, and the credential reference for accessing the entries in the underlying keystore. Important Red Hat did not specify the algorithm attribute in the command, because the Elytron subsystem uses KeyManagerFactory.getDefaultAlgorithm() to determine an algorithm by default. However, you can specify the algorithm attribute. To specify the algorithm attribute, you need to know what key manager algorithms are provided by the JDK you are using. For example, a JDK that uses SunJSSE provides the PKIX and SunX509 algorithms. In the command you can specify SunX509 as the key manager algorithm attribute. Add a Key Manager Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Other Settings and click View . Click on SSL Key Manager and click Add to configure a new key manager. 1.1.3.9. Create an Elytron Truststore To create a truststore in Elytron execute the following CLI command. In order to successfully execute the command above you must have an application.truststore file inside your EAP_HOME /standalone/configuration directory. The truststore must contain the certificates associated with the endpoint or a certificate chain in case the end point's certificate is signed by a CA. Red Hat recommends you to avoid using self-signed certificates. Ideally, certificates should be signed by a CA and your truststore should contain a certificate chain representing your ROOT and intermediary CAs. 1.1.3.10. Create an Elytron Trust Manager To define a trust manager in Elytron execute the following CLI command. This sets the defined truststore as the source of the certificates that the application server trusts. 1.1.3.11. Using the Out of the Box Elytron Components JBoss EAP provides a default set of Elytron components configured in the elytron subsystem. You can find more details on these pre-configured components in the Out of the Box section of the Security Architecture guide. 1.1.3.11.1. Securing Management Interfaces You can find more details on the enabling JBoss EAP to use the out of the box Elytron components for securing the management interfaces in the User Authentication with Elytron section. 1.1.3.11.2. Securing Applications The elytron subsystem provides application-http-authentication for http-authentication-factory by default, which can be used to secure applications. For more information on how to configure application-http-authentication , see the Out of the Box section of the Security Architecture guide. To configure applications to use application-http-authentication , see Configure Web Applications to Use Elytron or Legacy Security for Authentication in How to Configure Identity Management Guide . You can also override the default behavior of all applications using the steps in the Override an Application's Authentication Configuration section of the JBoss EAP How to Configure Identity Management Guide . 1.1.3.11.3. Using SSL/TLS JBoss EAP does provide a default one-way SSL/TLS configuration using the legacy core management authentication, but it does not provide one in the elytron subsystem. You can find more details on configuring SSL/TLS using the elytron subsystem for both the management interfaces as well as for applications in the following sections: Enable One-way SSL/TLS for the Management Interfaces Using the Elytron Subsystem Enable Two-Way SSL/TLS for the Management Interfaces using the Elytron Subsystem Enable One-way SSL/TLS for Applications using the Elytron Subsystem Enable Two-Way SSL/TLS for Applications using the Elytron Subsystem 1.1.3.11.4. Using Elytron with Other Subsystems In addition to securing applications and management interfaces, Elytron also integrates with other subsystems in JBoss EAP. batch-jberet You can configure the batch-jberet subsystem to run batch jobs using an Elytron security domain. For more information, see Configure Security for Batch Jobs in the Configuration Guide . datasources You can use a credential store or an Elytron security domain to provide authentication information in a datasource definition. For more information, see Datasource Security in the Configuration Guide . ejb3 You can create mappings for Elytron security domains in the ejb3 subsystem to be referenced by deployments. For more information, see Elytron Integration with the EJB Subsystem in Developing Jakarta Enterprise Beans Applications . iiop-openjdk You can use the elytron subsystem to configure SSL/TLS between clients and servers using the iiop-openjdk subsystem. For more information, see Configure IIOP to use SSL/TLS with the Elytron Subsystem in the Configuration Guide . jca You can use the elytron-enabled attribute to enable Elytron security for a work manager. For more information, see Configuring the JCA Subsystem in the Configuration Guide . jgroups You can configure the SYM_ENCRYPT and ASYM_ENCRYPT protocols to reference keystores or credential references defined in the elytron subsystem. For more information, see Securing a Cluster in the Configuration Guide . mail You can use a credential store to provide authentication information in a server definition in the mail subsystem. For more information, see Use a Credential Store for Passwords in the Configuration Guide . messaging-activemq You can secure remote connections to the remote connections used by the messaging-activemq subsystem. For more information, see the Using the Elytron Subsystem section of Configuring Messaging . modcluster You can use an Elytron client ssl-context to communicate with a load balancer using SSL/TLS. For more information, see Elytron Integration with the ModCluster Subsystem . remoting You can configure inbound and outbound connections in the remoting subsystem to reference authentication contexts, SASL authentication factories, and SSL contexts defined in the elytron subsystem. For full details on configuring each type of connection, see Elytron Integration with the Remoting Subsystem . resource-adapters You can secure connections to the resource adapter using Elytron. You can enable security inflow to establish security credentials when submitting work to be executed by the work manager. For more information, see Configure Resource Adapters to Use the Elytron Subsystem in the Configuration Guide . undertow You can use the elytron subsystem to configure both SSL/TLS and application authentication. For more information on configuring application authentication, see Using SSL/TLS and Configure Web Applications to Use Elytron or Legacy Security for Authentication in How to Configure Identity Management . 1.1.3.12. Enable and Disable the Elytron Subsystem The elytron subsystem comes pre-configured with the default JBoss EAP profiles alongside the legacy security subsystem. If you are using a profile where the elytron subsystem has not been configured, you can add it by adding the elytron extension and enabling the elytron subsystem. To add the elytron extension required for the elytron subsystem: To enable the elytron subsystem in JBoss EAP: To disable the elytron subsystem in JBoss EAP: Important Other subsystems within JBoss EAP may have dependencies on the elytron subsystem. If these dependencies are not resolved before disabling it, you will see errors when starting JBoss EAP. 1.1.4. Legacy Security Subsystem 1.1.4.1. Disabling the security subsystem You can disable the security subsystem in JBoss EAP by executing the remove operation of the subsystem. Procedure Disable the security subsystem in JBoss EAP: Important Other subsystems within JBoss EAP may have dependencies on the security subsystem. If these dependencies are not resolved before disabling it, you will see errors when starting JBoss EAP. 1.1.4.2. Enabling the security subsystem You can enable the security subsystem in JBoss EAP by executing the add operation of the subsystem. Procedure Enable the security subsystem in JBoss EAP: 1.1.5. Legacy security realms JBoss EAP uses security realms to define authentication and authorization mechanisms, such as local, LDAP properties, which can then be used by the management interfaces. Example: Security realms <security-realms> <security-realm name="ManagementRealm"> <authentication> <local default-user="USDlocal" skip-group-loading="true"/> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization map-groups-to-roles="false"> <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm> <security-realm name="ApplicationRealm"> <authentication> <local default-user="USDlocal" allowed-users="*" skip-group-loading="true"/> <properties path="application-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm> </security-realms> Note In addition to updating the existing security realms, JBoss EAP also allows you to create new security realms. You can create new security realms via the management console as well as invoking the following command from the management CLI: If you create a new security realm and want to use a properties file for authentication or authorization, you must create a new properties file specifically for the new security domain. JBoss EAP does not reuse existing files used by other security domains nor does it automatically create new files specified in the configuration if they do not exist. Additional resources For more information on security realms, see Security Realms . 1.1.6. Using authentication and socket bindings for securing the management interfaces You can use a combination of socket-binding , http-authentication-factory , and http-upgrade to secure the management interfaces using the elytron subsystem. Alternatively, you can use socket-binding with security-realm to secure the management interfaces with the legacy core management authentication. You can also disable the management interfaces, and configure users of the interfaces to have various roles and access rights. By default, JBoss EAP defines an http-interface to connect to the management interfaces. Procedure Display server management interfaces settings: 1.2. How to Secure the Management Interfaces The following sections show how to perform various operations related to securing the JBoss EAP management interfaces and related subsystems. Note The management CLI commands shown assume that you are running a JBoss EAP standalone server. For more details on using the management CLI for a JBoss EAP managed domain, see the JBoss EAP Management CLI Guide . Elytron Integration with the Management CLI The management interfaces can be secured using resources from the elytron subsystem in the same way as it is done by the legacy security realms. The SSL configuration for connections comes from one of these locations: Any SSL configuration within the CLI specific configuration. The default SSL configuration that automatically prompts users to accept the server's certificate. The java system property. Client configuration can be modified using the wildfly-config.xml file. Note If you set the -Dwildfly.config.url property, any file can be used by the client for configuration. 1.2.1. Configure networking and ports Depending on the configuration of the host, JBoss EAP may be configured to use various network interfaces and ports. This allows JBoss EAP to work with different host, networking, and firewall requirements. Additional resources For more information on the networking and ports used by JBoss EAP, as well as how to configure these settings, see the Network and Port Configuration section of the JBoss EAP Configuration Guide . 1.2.2. Disabling the management console Other clients, such as JBoss Operations Network, operate using the HTTP interface for managing JBoss EAP. In order to continue using these services, just the web-based management console itself may be disabled. This is accomplished by setting the console-enabled attribute to false . Procedure To disable the web-based management console in JBoss EAP: 1.2.3. Disabling remote access to JMX Remote access to the jmx subsystem allows for JDK and application management operations to be triggered remotely. Procedure To disable remote access to JMX in JBoss EAP, remove the remoting connector in the jmx subsystem: 1.2.4. Silent authentication The default installation of JBoss EAP contains a method of silent authentication for a local management CLI user. This allows the local user the ability to access the management CLI without username or password authentication. This functionality can be enabled to allow local users run the management CLI scripts without requiring authentication. It is considered a useful feature given that access to the local configuration typically also gives the user the ability to add their own user details or otherwise disable security checks. Silent authentication can be disabled where greater security control is required. This can be achieved by removing the local element within the security-realm attribute of the configuration file. This is applicable to both standalone instance as well as managed domain. Important The removal of the local element should only be done if the impact on the JBoss EAP instance and its configuration is fully understood. Procedure To remove silent authentication when using the elytron subsystem: To remove silent authentication when using a legacy security realm: 1.2.5. One-way SSL/TLS for the management interfaces using the Elytron subsystem In JBoss EAP, you can enable one-way SSL/TLS for the management interfaces using the JBoss EAP management CLI or the management console. In the management CLI, one-way SSL/TLS can be enabled in two ways: Using security command . Using elytron subsystem commands . In the management console, one-way SSL/TLS can be enabled in as follows: Using the management console 1.2.5.1. Enabling one-way SSL/TLS using a security command The security enable-ssl-management command can be used to enable one-way SSL/TLS for the management interfaces. Procedure Enter the security enable-ssl-management --interactive command in the CLI. Example Note Once the command is executed, the management CLI will reload the server and reconnect to it. You can disable one-way SSL/TLS for the management interfaces using the disable-ssl-management command. This command does not delete the Elytron resources. It configures the system to use the ApplicationRealm legacy security realm for its SSL configuration. 1.2.5.2. Enabling one-way SSL/TLS using the Elytron subsystem commands You can enable one-way SSL/TLS for the management interfaces using the elytron subsystem commands. Procedure Configure a key-store . Note The above command uses relative-to to reference the location of the keystore file. Alternatively, you can specify the full path to the keystore in path and omit relative-to . If the keystore file does not exist yet, the following commands can be used to generate an example key pair: Create a key-manager and server-ssl-context . Important Red Hat did not specify the algorithm attribute in the command, because the Elytron subsystem uses KeyManagerFactory.getDefaultAlgorithm() to determine an algorithm by default. However, you can specify the algorithm attribute. To specify the algorithm attribute, you need to know what key manager algorithms are provided by the JDK you are using. For example, a JDK that uses SunJSSE provides the PKIX and SunX509 algorithms. In the command you can specify SunX509 as the key manager algorithm attribute. You also need to determine what HTTPS protocols you want to support. The example commands above use TLSv1.2 . You can use the cipher-suite-filter to specify cipher suites, and the use-cipher-suites-order argument to honor server cipher suite order. The use-cipher-suites-order attribute by default is set to true . This differs from the legacy security subsystem behavior, which defaults to honoring client cipher suite order. Enable HTTPS on the management interface. Reload the JBoss EAP instance. One-way SSL/TLS is now enabled for the management interfaces. Important In cases where you have both a security-realm and ssl-context defined, JBoss EAP will use the SSL/TLS configuration provided by ssl-context . Additional resources key-store Attributes key-manager Attributes server-ssl-context Attributes 1.2.5.3. Enabling one-way SSL/TLS using the management console You can enable SSL for the management interface used by the management console using an SSL wizard in the management console. Procedure Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Runtime , click the appropriate server name. Click View to server name. Click HTTP Manageme... to open the HTTP Management Interface configuration page. Click Enable SSL to launch the wizard. The wizard guides you through the following scenarios for enabling SSL: You want to create a certificate store and generate a self-signed certificate. You want to obtain a certificate from Let's Encrypt Certificate Authority. You already have the certificate store on the file system, but no keystore configuration. You already have a keystore configuration that uses a valid certificate store. Using the wizard, you can optionally create a truststore for mutual authentication. 1.2.6. Two-way SSL/TLS for the management interfaces using the Elytron Subsystem In JBoss EAP, two-way SSL/TLS for the management interfaces can be enabled either by using a security command or by using the elytron subsystem commands. To enable two-way SSL/TLS, first you must obtain or generate a client certificate. You can generate a client certificate by using the following procedure: Generating client certificates You can then enable two-way SSL/TLS for the management interfaces using one of the following methods: Enabling two-way SSL/TLS using a security command Enabling two-way SSL/TLS using the Elytron subsystem commands 1.2.6.1. Generating client certificates You can generate client certificates using the keytool command in the CLI. Procedure Generate your client certificate: USD keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret Export the client certificate: USD keytool -exportcert -keystore client.keystore.jks -alias client -keypass secret -storepass secret -file /path/to/client.cer 1.2.6.2. Enabling two-way SSL/TLS using a security command The security enable-ssl-management command can be used to enable two-way SSL/TLS for the management interfaces. Note The following example does not validate the certificate as no chain of trust exists. If you are using a trusted certificate, then the client certificate can be validated without issue. Prerequisites You have configured a client keystore. You have exported a certificate for a server trust store. For more information, see Generating client certificates . Procedure Enter the security enable-ssl-management --interactive command in the CLI. Example Note Once the command is executed, the management CLI will reload the server and attempt to reconnect to it. To complete the two-way SSL/TLS authentication, you need to import the server certificate into the client truststore and configure your client to present the client certificate. You can disable two-way SSL/TLS for the management interfaces using the disable-ssl-management command. security disable-ssl-management This command does not delete the Elytron resources. It configures the system to use the ApplicationRealm legacy security realm for its SSL configuration. 1.2.6.3. Enabling two-way SSL/TLS using the Elytron subsystem commands You can use the elytron subsystem commands to enable two-way SSL/TLS for the management interfaces. Prerequisites You have exported a certificate for a server trust store. For more information, see Generating client certificates . Procedure Obtain or generate your keystore. Before enabling one-way SSL/TLS in JBoss EAP, you must obtain or generate the keystores, truststores and certificates you plan on using. To generate an example set of keystores, truststores, and certificates, use the following commands. Configure a key-store . Note The above command uses relative-to to reference the location of the keystore file. Alternatively, you can specify the full path to the keystore in path and omit relative-to . Export your server certificate. Create a key-store for the server trust store and import the client certificate into the server truststore. Note The following example does not validate the certificate as no chain of trust exists. If you are using a trusted certificate, then the client certificate can be validated without issue. Configure a key-manager , trust-manager , and server-ssl-context for the server keystore and truststore. Important Red Hat did not specify the algorithm attribute in the command, because the Elytron subsystem uses KeyManagerFactory.getDefaultAlgorithm() and TrustManagerFactory.getDefaultAlgorithm() to determine an algorithm by default. However, you can specify the algorithm attribute. To specify the algorithm attribute, you need to know what key manager algorithms are provided by the JDK you are using. For example, a JDK that uses SunJSSE provides the PKIX and SunX509 algorithms. In the command you can specify SunX509 as the key manager algorithm attribute and PKIX as the trust manager algorithm attribute. You also need to determine what HTTPS protocols you want to support. The example commands above use TLSv1.2 . You can use the cipher-suite-filter to specify cipher suites, and the use-cipher-suites-order argument to honor server cipher suite order. The use-cipher-suites-order attribute by default is set to true . This differs from the legacy security subsystem behavior, which defaults to honoring client cipher suite order. Enable HTTPS on the management interface. Reload the JBoss EAP instance. Note To complete the two-way SSL/TLS authentication, you need to import the server certificate into the client truststore and configure your client to present the client certificate. Configure your client to use the client certificate. You need to configure your client to present the trusted client certificate to the server to complete the two-way SSL/TLS authentication. For example, if using a browser, you need to import the trusted certificate into the browser's trust store. This results in a forced two-way SSL/TLS authentication, without changing the original authentication to the server management. If you want to change the original authentication method, see Configure Authentication with Certificates in How to Configure Identity Management for JBoss EAP. Two-way SSL/TLS is now enabled for the management interfaces. Important In cases where you have both a security-realm and ssl-context defined, JBoss EAP will use the SSL/TLS configuration provided by ssl-context . Additional resources key-store Attributes key-manager Attributes server-ssl-context Attributes trust-manager Attributes 1.2.7. SASL authentication for the management interfaces using the CLI security command You can use the CLI security command to enable and disable SASL authentication for the management interfaces. You can also use the command to reorder SASL mechanisms. Enable SASL authentication In JBoss EAP, SASL authentication, using an elytron SASL authentication factory, can be enabled for the management interfaces with the security enable-sasl-management command. This command creates all of the non-existing resources required to configure authentication. By default this command associates the included SASL factory with the http-interface . Example: Enable SASL Authentication Note Once the command is executed, the management CLI will reload the server and reconnect to it. If a SASL factory already exists, then the factory is updated to use the mechanism defined by the --mechanism argument. For a list of arguments, see Authorization Security Arguments . Disable SASL authentication To remove the active SASL authentication factory use the following command: Alternatively, to remove specific mechanisms from the active SASL authentication factory, use the following command: Reorder SASL mechanisms The order of defined SASL mechanisms dictate how the server authenticates the request, with the first matching mechanism being sent to the client. You can change this order by passing a comma-separated to to the security reorder-sasl-management command, for example: Additional resources Security Authorization Arguments 1.2.8. HTTP authentication for the management interfaces using the CLI security command You can use the CLI security command to enable and disable HTTP authentication for the management interfaces. Enable HTTP authentication In JBoss EAP, HTTP authentication, using an elytron HTTP authentication factory, can be enabled for the management interfaces with the security enable-http-auth-management command. This command can only target the http-interface , and with no additional arguments the included HTTP authentication factory will be associated with this interface. Example: Enable HTTP Authentication Note Once the command is executed, the management CLI will reload the server and reconnect to it. If an HTTP factory already exists, then the factory is updated to use the mechanism defined by the --mechanism argument. For a list of arguments, see Authorization Security Arguments . Disable HTTP Authentication To remove the active HTTP authentication factory use the following command. Alternatively, you can use the following command to remove specific mechanisms from the active HTTP authentication factory. Additional resources Authorization Security Arguments 1.2.9. Configuring the management interfaces for one-way SSL/TLS with legacy core management authentication Configuring the JBoss EAP management interfaces for communication only using one-way SSL/TLS provides increased security. All network traffic between the client and the management interfaces is encrypted, which reduces the risk of security attacks such as a man-in-the-middle attack. In this procedure unencrypted communication with the JBoss EAP instance is disabled. This procedure applies to both standalone server and managed domain configurations. For a managed domain, prefix the management CLI commands with the name of the host, for example: /host=master . Important While performing the steps for enabling one-way SSL/TLS on the management interfaces, do not reload the configuration unless explicitly instructed. Doing so may cause you to be locked out of the management interfaces. Create a keystore to secure the management interfaces. For more information, see Creating a keystore to secure the management interfaces . Ensure the management interfaces bind to HTTPS. For more information, see Ensuring the management interfaces bind to HTTPS . Optional: Implement a custom socket-binding-group . For more information, see Custom socket-binding-group . Create a new security realm. For more information, see Creating a new security realm . Configure the management interfaces to use the new security realm. For more information, see Configuring the management interfaces to use a security realm . Configure the management interfaces to use the keystore. For more information, see Configuring the management interfaces to use a keystore . Update the jboss-cli.xml . For more information, see Updating the jboss-cli.xml file . 1.2.9.1. Creating a keystore to secure the management interfaces Create a keystore to secure the management interfaces. This keystore must be in JKS format as the management interfaces are not compatible with keystores in JCEKS format. Procedure Create a keystore using the following CLI command: Replace the example values for the parameters, for example alias , keypass , keystore , storepass and dname , with the correct values for the environment. USD keytool -genkeypair -alias appserver -storetype jks -keyalg RSA -keysize 2048 -keypass password1 -keystore EAP_HOME /standalone/configuration/identity.jks -storepass password1 -dname "CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US" -validity 730 -v Note The parameter validity specifies for how many days the key is valid. A value of 730 equals two years. 1.2.9.2. Ensuring the management interfaces bind to HTTPS Configure JBoss EAP to ensure management interfaces bind to HTTPS. Procedure Configuration when running a Standalone Server To ensure the management interfaces bind to HTTPS, you must add the management-https configuration and remove the management-http configuration. Use the following CLI commands to bind the management interfaces to HTTPS: Configuration when running a Managed Domain Change the socket element within the management-interface attribute by adding secure-port and removing port configuration. Use the following commands to bind the management interfaces to HTTPS: 1.2.9.3. Custom socket-binding-group If you want to use a custom socket-binding-group , you must ensure the management-https binding is defined, which by default is bound to port 9993 . You can verify this from the socket-binding-group attribute of the server's configuration file or using the management CLI: 1.2.9.4. Creating a new security realm Create a new security realm. In this procedure, the new security realm using HTTPS, ManagementRealmHTTPS , uses a properties file named https-mgmt-users.properties located in the EAP_HOME /standalone/configuration/ directory for storing user names and passwords. Procedure Create a properties file for storing user name and passwords. User names and passwords can be added to the file later, but for now, you need to create an empty file named https-mgmt-users.properties and save it to that location. The below example shows using the touch command, but you may also use other mechanisms, such as a text editor. Example: Using the touch Command to Create an Empty File USD touch EAP_HOME /standalone/configuration/https-mgmt-users.properties , use the following management CLI commands to create a new security realm named ManagementRealmHTTPS : Add users to the properties file. At this point, you have created a new security realm and configured it to use a properties file for authentication. You must now add users to that properties file using the add-user script, which is available in the EAP_HOME /bin/ directory. When running the add-user script, you must specify both the properties file and the security realm using the -up and -r options respectively. From there, the add-user script will interactively prompt you for the user name and password information to store in the https-mgmt-users.properties file. USD EAP_HOME /bin/add-user.sh -up EAP_HOME /standalone/configuration/https-mgmt-users.properties -r ManagementRealmHTTPS ... Enter the details of the new user to add. Using realm 'ManagementRealmHTTPS' as specified on the command line. ... Username : httpUser Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file. - The password must not be one of the following restricted values {root, admin, administrator} - The password must contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s) - The password must be different from the username ... Password : Re-enter Password : About to add user 'httpUser' for realm 'ManagementRealmHTTPS' ... Is this correct yes/no? yes .. Added user 'httpUser' to file 'EAP_HOME/configuration/https-mgmt-users.properties' ... Is this new user going to be used for one AS process to connect to another AS process? e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls. yes/no? no Important When configuring security realms that use properties files to store usernames and passwords, it is recommended that each realm use a distinct properties file that is not shared with another realm. 1.2.9.5. Configuring the management interfaces to use a security realm You can configure the management interfaces to use a security realm by using a management CLI command. Procedure Use the following management CLI command: 1.2.9.6. Configuring the management interfaces to use a keystore Configure the management interfaces to use a keystore by using management CLI commands. Procedure Use the following management CLI command to configure the management interfaces to use the keystore. For the parameters file, password and alias their values must be copied from the Create a Keystore to Secure the Management Interfaces step. Note To update the keystore password, use the following CLI command: Reload the server's configuration: After reloading the server configuration, the log should contain the following, just before the text which states the number of services that are started: 13:50:54,160 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0061: Http management interface listening on https://127.0.0.1:9993/management 13:50:54,162 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0052: Admin console listening on https://127.0.0.1:9993 The management interfaces are now listening on port 9993 , which confirms that the procedure was successful. Important At this point, the CLI will disconnect and will be unable to reconnect since the port bindings have changed. Proceed to the step to update the jboss-cli.xml file to allow the management CLI to reconnect. 1.2.9.7. Updating the jboss-cli.xml file If using the management CLI to perform management actions, you must update the EAP_HOME /bin/jboss-cli.xml file. Procedure Update the EAP_HOME /bin/jboss-cli.xml file as following: Update the value of <default-protocol> to https-remoting . In <default-controller> , update the value of <protocol> to https-remoting . In <default-controller> , update the value of <port> to 9993 . Example: jboss-cli.xml <jboss-cli xmlns="urn:jboss:cli:2.0"> <default-protocol use-legacy-override="true">https-remoting</default-protocol> <!-- The default controller to connect to when 'connect' command is executed w/o arguments --> <default-controller> <protocol>https-remoting</protocol> <host>localhost</host> <port>9993</port> </default-controller> ... The time you connect to the management interface using the management CLI, you must accept the server certificate and authenticate against the ManagementRealmHTTPS security realm: Example: Accepting Server Certificate and Authenticating USD ./jboss-cli.sh -c Unable to connect due to unrecognised server certificate Subject - CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US Issuer - CN=appserver, OU=Sales, O=Systems Inc, L=Raleigh, ST=NC, C=US Valid From - Tue Jun 28 13:38:48 CDT 2016 Valid To - Thu Jun 28 13:38:48 CDT 2018 MD5 : 76:f4:81:8b:7e:c3:be:6d:ee:63:c1:7a:b7:b8:f0:fb SHA1 : ea:e3:f1:eb:53:90:69:d0:c9:69:4a:5a:a3:20:8f:76:c1:e6:66:b6 Accept certificate? [N]o, [T]emporarily, [P]ermenantly : p Authenticating against security realm: ManagementRealmHTTPS Username: httpUser Password: [standalone@localhost:9993 /] Important In cases where you have both a security-realm and ssl-context defined, JBoss EAP will use the SSL/TLS configuration provided by ssl-context . 1.2.10. Setting up two-way SSL/TLS for the management interfaces with legacy core management authentication Two-way SSL/TLS authentication, also known as client authentication , authenticates both the client and the server using SSL/TLS certificates. This differs from the Configure the Management Interfaces for One-way SSL/TLS section in that both the client and server each have a certificate. This provides assurance that not only is the server who it says it is, but the client is also who it says it is. In this section the following conventions are used: HOST1 The JBoss server hostname. For example: jboss.redhat.com . HOST2 A suitable name for the client. For example: myclient . Note this is not necessarily an actual hostname. CA_HOST1 The DN (distinguished name) to use for the HOST1 certificate. For example: cn=jboss,dc=redhat,dc=com . CA_HOST2 The DN (distinguished name) to use for the HOST2 certificate. For example: cn=myclient,dc=redhat,dc=com . Note If a password vault is used to store the keystore and truststore passwords, which is recommended, the password vault should already be created. For more information on the password vault, see the Password Vault section as well as the Password Vault System section of the Red Hat JBoss Enterprise Application Platform 7 Security Architecture guide. Warning Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages. Procedure Generate the keystores. USD keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secret USD keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret Export the certificates. USD keytool -exportcert -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer USD keytool -exportcert -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer Import the certificates into the opposing truststores. USD keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer USD keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer Define a CertificateRealm. Define a CertificateRealm in the configuration for the server ( host.xml or standalone.xml ) and point the interface to it. This can be done using the following commands: Change the security-realm of the http-interface to the new CertificateRealm. Add the SSL/TLS configuration for the CLI. Important In addition to adding the two-way SSL/TLS, the management interface should also be configured to bind to HTTPS. For details, see Ensure the Management Interfaces Bind to HTTPS in the section entitled Configure the Management Interfaces for One-way SSL/TLS with Legacy Core Management Authentication . Add the SSL/TLS configuration for the CLI, which uses EAP_HOME /bin/jboss-cli.xml as a settings file. To store the keystore and truststore passwords in plain text, edit EAP_HOME /bin/jboss-cli.xml and add the SSL/TLS configuration using the appropriate values for the variables: Example: jboss-cli.xml Storing Keystore and Truststore Passwords in Plain Text <ssl> <alias>HOST2_alias</alias> <key-store>/path/to/HOST2.keystore.jks</key-store> <key-store-password>secret</key-store-password> <trust-store>/path/to/HOST2.truststore.jks</trust-store> <trust-store-password>secret</trust-store-password> <modify-trust-store>true</modify-trust-store> </ssl> To use the keystore and truststore passwords stored in a password vault, you need to add the vault configuration and appropriate vault values to EAP_HOME /bin/jboss-cli.xml : Example: jboss-cli.xml Storing Keystore and Truststore Passwords in a Password Vault <ssl> <vault> <vault-option name="KEYSTORE_URL" value="path-to/vault/vault.keystore"/> <vault-option name="KEYSTORE_PASSWORD" value="MASK-5WNXs8oEbrs"/> <vault-option name="KEYSTORE_ALIAS" value="vault"/> <vault-option name="SALT" value="12345678"/> <vault-option name="ITERATION_COUNT" value="50"/> <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/> </vault> <alias>HOST2_alias</alias> <key-store>/path/to/HOST2.keystore.jks</key-store> <key-store-password>VAULT::VB::cli_pass::1</key-store-password> <key-password>VAULT::VB::cli_pass::1</key-password> <trust-store>/path/to/HOST2.truststore.jks</trust-store> <trust-store-password>VAULT::VB::cli_pass::1</trust-store-password> <modify-trust-store>true</modify-trust-store> </ssl> Important In cases where you have both a security-realm and ssl-context defined, JBoss EAP will use the SSL/TLS configuration provided by ssl-context . 1.2.11. HTTPS Listener Reference For a full list of attributes available for the HTTPS listener, see the Undertow Subsystem Attributes section in the JBoss EAP Configuration Guide . 1.2.11.1. About Cipher Suites You can configure a list of the encryption ciphers which are allowed. For JSSE syntax, it must be a comma-separated list. For OpenSSL syntax, it must be a colon-separated list. Ensure that only one syntax is used. The default is the JVM default. Important Using weak ciphers is a significant security risk. See NIST Guidelines for NIST recommendations on cipher suites. See the OpenSSL documentation for a list of available OpenSSL ciphers . Note that the following are not supported: @SECLEVEL SUITEB128 SUITEB128ONLY SUITEB192 See the Java documentation for a list of the standard JSSE ciphers . To update the list of enabled cipher suites, use the enabled-cipher-suites attribute of the HTTPS listener in the undertow subsystem. Example: Management CLI Command for Updating the List of Enabled Cipher Suites Note The example only lists two possible ciphers, but real-world examples will likely use more. 1.2.12. Enabling support for the TLS 1.3 protocol with the OpenSSL provider You can enable support for the TLS 1.3 protocol with the OpenSSL provider for TLS by configuring the cipher-suite-names attribute in the ssl-context configuration. Choose one of the following methods for configuring JBoss EAP to use the OpenSSL TLS provider: Configure the Elytron subsystem to use the OpenSSL TLS provider by default. Configure the providers attribute of a server-ssl-context component or a client-ssl-context component to use the OpenSSL TLS provider. Important Compared with TLS 1.2, you might experience reduced performance when running TLS 1.3 with JDK 11. This can occur when clients make a very large number of TLS 1.3 requests to a server. A system upgrade to a newer JDK version can improve performance. Test your setup with TLS 1.3 for performance degradation before enabling it in production. Prerequisites Enable one-way SSL/TLS or two-way SSL/TLS for applications. Procedure Choose one of the following methods to configure your JBoss EAP 7.4 instance to use the OpenSSL TLS provider: Configure the elytron subsystem to use the OpenSSL TLS provider by default. To do this, remove the default final-providers configuration, which registers the OpenSSL TLS provider after all globally registered providers. , register the OpenSSL TLS provider ahead of all globally registered providers. Configure the providers attribute of a server-ssl-context or a client-ssl-context to use the OpenSSL TLS provider. Example of setting the providers attribute for an existing server-ssl-context called serverSSC . Optional: If you configured your ssl-context to use a protocol other than the TLS 1.3 protocol, you must configure the protocols attribute in the ssl-context to include the TLS 1.3 protocol: Enable support for the TLS 1.3 protocol with the OpenSSL provider by configuring the cipher-suite-names attribute in the ssl-context configuration. The following example sets TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 as the value for the cipher-suite-names attribute: Reload your JBoss EAP instance: Optional: Test that you can successfully establish an SSL-encrypted connection with the server by using the TLS 1.3 protocol and the TLS 1.3 cipher suite. Use a tool, such as curl , to check the output of the configuration: Example output showing TLS_AES_256_GCM_SHA384 with the TLS 1.3 protocol to secure the SSL connection. SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=localhost * start date: Oct 6 14:58:16 2020 GMT * expire date: Nov 5 15:58:16 2020 GMT * issuer: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=localhost * SSL certificate verify result: self signed certificate (18), continuing anyway. Additional resources For information about enabling one-way SSL/TLS or two-way SSL/TLS for applications, see Enable One-way SSL/TLS for Applications Using the Elytron Subsystem . For information about the client-ssl-context , see Using a client-ssl-context . For information about the server-ssl-context , see Using a server-ssl-context . 1.2.13. FIPS 140-2 Compliant Cryptography It is possible to configure FIPS 140-2 compliant cryptography on Red Hat Enterprise Linux using either of the following methods. Using the SunPKCS11 provider with an NSS database Using the third party BouncyCastle providers 1.2.13.1. Enable FIPS 140-2 Cryptography for SSL/TLS on Red Hat Enterprise Linux 7 and Later You can configure Undertow to use FIPS 140-2 compliant cryptography for SSL/TLS. The scope of this configuration example is limited to Red Hat Enterprise Linux 7 and later, using the Mozilla NSS library in FIPS mode. Important The installed Red Hat Enterprise Linux must already be configured to be FIPS 140-2 compliant. For more information, see the solution titled How can I make RHEL 6 or RHEL 7 FIPS 140-2 compliant? , which is located on the Red Hat Customer Portal. Warning Using the TLS 1.2 protocol when running JBoss EAP in FIPS mode can cause a NoSuchAlgorithmException to occur. More details on this issue can be found in the solution titled NoSuchAlgorithmException: no such algorithm: SunTls12MasterSecret , which is located on the Red Hat Customer Portal. Therefore, it is not possible to configure HTTP/2 in FIPS mode because HTTP/2 requires the TLS 1.2 protocol. FIPS mode (PKCS11) supports the TLS 1 and the TLS 1.1 protocols so you can use: TLS 1.1 in case of Oracle/OpenJDK TLS 1 in case of IBM java To configure Undertow to use FIPS 140-2 compliant cryptography for SSL/TLS, you must do the following: Configure the NSS database . Configure the management CLI for FIPS 140-2 compliant cryptography for SSL/TLS . Configure the undertow subsystem to use either Elytron or the legacy core management authentication . Note The OpenSSL provider requires a private key, but it is not possible to retrieve a private key from the PKCS11 store. FIPS does not allow the export of unencrypted keys from FIPS compliant cryptographic module. Therefore, for both the elytron subsystem as well as legacy security, it is not possible to use the OpenSSL provider for TLS when in FIPS mode. Configuring the NSS database Create a directory owned by the appropriate user to house the NSS database. Example Commands for Creating the NSS Database Directory USD mkdir -p /usr/share/jboss-as/nssdb USD chown jboss /usr/share/jboss-as/nssdb USD modutil -create -dbdir /usr/share/jboss-as/nssdb Note DBM file format, the default database format in RHEL 7 and earlier, has been deprecated. NSS now uses SQL by default . The jboss user is only an example. Replace it with an active user on your operating system to run JBoss EAP. Create the NSS configuration file: /usr/share/jboss-as/nss_pkcsll_fips.cfg . It must specify: a name the directory where the NSS library is located the directory where the NSS database was created in the step Example: nss_pkcsll_fips.cfg Note If you are not running a 64-bit version of Red Hat Enterprise Linux 6 then set nssLibraryDirectory to /usr/lib instead of /usr/lib64 . Edit the Java security configuration file. This configuration file affects the entire JVM, and can be defined using either of the following methods. A default configuration file, java.security , is provided in your JDK. This file is used if no other security configuration files are specified. See the JDK vendor's documentation for the location of this file. Define a custom Java security configuration file and reference it by using the -Djava.security.properties= /path/to/ java.security.properties . When referenced in this manner it overrides the settings in the default security file. This option is useful when having multiple JVMs running on the same host that require different security settings. Add the following line to your Java security configuration file: Example: java.security Note The nss_pkcsll_fips.cfg configuration file specified in the above line is the file created in the step. You also need to update the following link in your configuration file from: to Important Any other security.provider.X lines in this file, for example security.provider.2 , must have the value of their X increased by one to ensure that this provider is given priority. Run the modutil command on the NSS database directory you created in the step to enable FIPS mode. Note You may get a security library error at this point requiring you to regenerate the library signatures for some of the NSS shared objects. Set the password on the FIPS token. The name of the token must be NSS FIPS 140-2 Certificate DB . Important The password used for the FIPS token must be a FIPS compliant password. If the password is not strong enough, you may receive an error: ERROR: Unable to change password on token "NSS FIPS 140-2 Certificate DB". Create a certificate using the NSS tools. Example Command USD certutil -S -k rsa -n undertow -t "u,u,u" -x -s "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /usr/share/jboss-as/nssdb Verify that the JVM can read the private key from the PKCS11 keystore by running the following command: Important Once you have FIPS enabled, you may see the following error when starting JBoss EAP: This message will appear if you have any existing key managers configured, such as the default key manager in legacy core management authentication, that do not use FIPS 140-2 compliant cryptography. Configure the Management CLI for FIPS 140-2 Compliant Cryptography for SSL/TLS You must configure the JBoss EAP management CLI to work in an environment with FIPS 140-2 compliant cryptography for SSL/TLS enabled. By default, if you try to use the management CLI in such an environment, the following exception is thrown: org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used . If you are using the legacy security subsystem: Update the javax.net.ssl.keyStore and javax.net.ssl.trustStore system properties in the jboss-cli.sh file, as shown below: If you are using the elytron subsystem: Create an XML configuration file for the management CLI with the following contents: Example: cli-wildfly-config.xml <configuration> <authentication-client xmlns="urn:elytron:client:1.2"> <key-stores> <key-store name="truststore" type="PKCS11"> <key-store-clear-password password="P@ssword123"/> </key-store> </key-stores> <ssl-contexts> <ssl-context name="client-cli-context"> <trust-store key-store-name="truststore"/> <cipher-suite selector="USD{cipher.suite.filter}"/> <protocol names="TLSv1.1"/> </ssl-context> </ssl-contexts> <ssl-context-rules> <rule use-ssl-context="client-cli-context"/> </ssl-context-rules> </authentication-client> </configuration> Note If you are using the IBM JDK, see the IBM management CLI configuration example for the specific configuration required. When starting the management CLI, pass the configuration file to the management CLI script using the -Dwildfly.config.url property. For example: Configure the Elytron and Undertow Subsystems Add the FIPS 140-2 compliant cryptography key-store , key-manager and ssl-context . Update the undertow subsystem to use the new ssl-context . Note https-listener must always have either a security-realm or ssl-context configured. When changing between the two configurations, the commands must be executed as a single batch, as shown below. In the elytron subsystem, OpenJDK and Oracle JDK in FIPS mode restrict the usage of any advanced features that are based on providing custom KeyManager or TrustManager implementations. The following configuration attributes do not work on the server: server-ssl-context.security-domain trust-manager.certificate-revocation-list Configure Undertow with the Legacy Core Management Authentication Optionally, you can still use the legacy core management authentication instead of the elytron subsystem to complete the setup of FIPS 140-2 compliant cryptography for SSL/TLS: Configure Undertow to use SSL/TLS. Note The following commands below must either be run in batch mode, or the server must be reloaded after adding the ssl server identity. The example below is shown using batch mode. The basic details for configuring Undertow to SSL/TLS are covered in Setting up an SSL/TLS for Applications . Configure the cipher suites used by Undertow. Once you have SSL/TLS configured, you need to configure the https listener and security realm to have a specific set of cipher suites enabled: Required Cipher Suites The basics behind enabling cipher suites for the https listener are covered in About Cipher Suites . To enable cipher suites on the https listener: Example Command for Enabling Cipher Suites on the Https Listener Enable cipher suites on the security realm. Example Command for Enabling Cipher Suites on the Security Realm 1.2.13.2. Enable FIPS 140-2 Cryptography for SSL/TLS Using Bouncy Castle You can configure Undertow to use FIPS 140-2 compliant cryptography for SSL/TLS. The scope of this configuration example is limited to Red Hat Enterprise Linux 7 and later. The Bouncy Castle JARs are not provided by Red Hat, and must be obtained directly from Bouncy Castle. Prerequisites Ensure your environment is configured to use the BouncyCastle provider . A Bouncy Castle keystore must exist on the server. If one does not exist, it can be created using the following command. Configure the Management CLI for FIPS 140-2 Compliant Cryptography for SSL/TLS Using Elytron You must configure the JBoss EAP management CLI to work in an environment with FIPS 140-2 compliant cryptography for SSL/TLS enabled. Create an XML configuration file for the management CLI with the following contents: Example: cli-wildfly-config.xml <configuration> <authentication-client xmlns="urn:elytron:client:1.2"> <key-stores> <key-store name="truststore" type="BCFKS"> <file name="USD{truststore.location}" /> <key-store-clear-password password="USD{password}" /> </key-store> <key-store name="keystore" type="BCFKS"> <file name="USD{keystore.location}" /> <key-store-clear-password password="USD{password}" /> </key-store> </key-stores> <ssl-contexts> <ssl-context name="client-cli-context"> <key-store-ssl-certificate algorithm="PKIX" key-store-name="keystore"> <key-store-clear-password password="USD{password"} /> </key-store-ssl-certificate> <trust-store key-store-name="truststore"/> <trust-manager algorithm="PKIX"> </trust-manager> <cipher-suite selector="TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CCM,TLS_RSA_WITH_AES_128_CCM"/> <protocol names="TLSv1.2"/> </ssl-context> </ssl-contexts> <ssl-context-rules> <rule use-ssl-context="client-cli-context"/> </ssl-context-rules> </authentication-client> </configuration> When starting the management CLI, pass the configuration file to the management CLI script using the -Dwildfly.config.url property. For example: Configure the Elytron and Undertow Subsystems Add the FIPS 140-2 compliant cryptography key-store , key-manager and ssl-context . When defining the keystore, the type must be BCFKS . Update the undertow subsystem to use the new ssl-context . Note https-listener must always have either a security-realm or ssl-context configured. When changing between the two configurations, the commands must be executed as a single batch, as shown below. 1.2.14. FIPS 140-2 Compliant Cryptography on IBM JDK On the IBM JDK, the IBM Java Cryptographic Extension (JCE) IBMJCEFIPS provider and the IBM Java Secure Sockets Extension (JSSE) FIPS 140-2 Cryptographic Module (IBMJSSE2) for multi-platforms provide FIPS 140-2 compliant cryptography. For more information on the IBMJCEFIPS provider, see the IBM Documentation for IBM JCEFIPS and NIST IBMJCEFIPS - Security Policy . For more information on IBMJSSE2, see Running IBMJSSE2 in FIPS mode . 1.2.14.1. Key Storage The IBM JCE does not provide a keystore. The keys are stored on the computer and do not leave its physical boundary. If the keys are moved between computers they must be encrypted. To run keytool in FIPS-compliant mode use the -providerClass option on each command like this: 1.2.14.2. Management CLI Configuration To configure the management CLI for FIPS 140-2 compliant cryptography on the IBM JDK, you must use a management CLI configuration file specifically for the IBM JDK, such as the following: Example: cli-wildfly-config-ibm.xml <configuration> <authentication-client xmlns="urn:elytron:client:1.2"> <key-stores> <key-store name="truststore" type="JKS"> <file name="/path/to/truststore"/> <key-store-clear-password password="P@ssword123"/> </key-store> </key-stores> <ssl-contexts> <ssl-context name="client-cli-context"> <trust-store key-store-name="truststore"/> <cipher-suite selector="USD{cipher.suite.filter}"/> <protocol names="TLSv1"/> </ssl-context> </ssl-contexts> <ssl-context-rules> <rule use-ssl-context="client-cli-context"/> </ssl-context-rules> </authentication-client> </configuration> 1.2.14.3. Examine FIPS Provider Information To examine information about the IBMJCEFIPS used by the server, enable debug-level logging by adding -Djavax.net.debug=true to the standalone.conf or domain.conf files. Information about the FIPS provider is logged to the server.log file, for example: 1.2.15. Starting a Managed Domain when the JVM is Running in FIPS Mode Update each host controller and the master domain controller to use SSL/TLS for communication. Prerequisites Before you begin, make sure you have completed the following prerequisites. You have implemented a managed domain. For details about configuring a managed domain, see the Domain Management section in the JBoss EAP Configuration Guide . You have configured FIPS. For details about configuring FIPS, see Enable FIPS 140-2 Cryptography for SSL/TLS on Red Hat Enterprise Linux 7 and later . You have created all necessary certificates and have imported the domain controller's certificate into each controller's truststore. Warning Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 in all affected packages. On the master domain controller, create an SSL/TLS security realm that is configured to use your NSS database as a PKCS11 provider.. Example: Security Realm on the Master Domain Controller <security-realm name="HTTPSRealm"> <server-identities> <ssl> <engine enabled-protocols="TLSv1.1"/> <keystore provider="PKCS11" keystore-password="strongP@ssword1"/> </ssl> </server-identities> <authentication> <local default-user="\USDlocal"/> <properties path="https-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> </security-realm> On each host controller, create a security realm with an SSL/TLS truststore for authentication. Example: Security Realm on Each Host Controller <security-realm name="HTTPSRealm"> <authentication> <truststore provider="PKCS11" keystore-password="strongP@ssword1"/> </authentication> </security-realm> Note Repeat this process on each host. Secure the HTTP interface on the master domain controller with the security realm you just created. Example: HTTP Interface <management-interfaces> <http-interface security-realm="HTTPSRealm"> <http-upgrade enabled="true"/> <socket interface="management" port="USD{jboss.management.http.port:9990}"/> </http-interface> </management-interfaces> Use the SSL/TLS realm on each host controller to connect to the master domain controller. Update the security realm used for connecting to the master domain controller. Modify the host controller's configuration file, for example host.xml or host-slave.xml , while the server is not running. Example: Host Controller Configuration File <domain-controller> <remote security-realm="HTTPSRealm"> <discovery-options> <static-discovery name="primary" protocol="USD{jboss.domain.master.protocol:remote}" host="USD{jboss.domain.master.address}" port="USD{jboss.domain.master.port:9990}"/> </discovery-options> </remote> </domain-controller> Update how each server connects back to its host controller. Example: Server Configuration <server name="my-server" group="my-server-group"> <ssl ssl-protocol="TLS" trust-manager-algorithm="PKIX" truststore-type="PKCS11" truststore-password="strongP@ssword1"/> </server> Configure two-way SSL/TLS in a managed domain. To enable two-way SSL/TLS, add a truststore authentication method to the SSL/TLS security realm for the master domain controller, execute the following management CLI commands: You also need to update each host controller's security realm to have an SSL server identity, execute the following management CLI commands: Important You also need to ensure that each host's certificate is imported into the domain controller's truststore. 1.2.16. Secure the Management Console with Red Hat Single Sign-On You can secure the JBoss EAP management console with Red Hat Single Sign-On using the elytron subsystem. Note This feature is only available when running a standalone server and is not supported when running a managed domain. It is not supported to use Red Hat Single Sign-On to secure the management CLI. Use the following steps to set up Red Hat Single Sign-On to authenticate users for the JBoss EAP management console. Configure a Red Hat Single Sign-On server for JBoss EAP management . Install the Red Hat Single Sign-On client adapter on JBoss EAP . Configure JBoss EAP to use Red Hat Single Sign-On . Configure a Red Hat Single Sign-On Server for JBoss EAP Management Download and install a Red Hat Single Sign-On server. See the Red Hat Single Sign-On Getting Started Guide for basic instructions. Start the Red Hat Single Sign-On server. This procedure assumes that you started the server with a port offset of 100 . Log in to the Red Hat Single Sign-On administration console at http://localhost:8180/auth/ . If this is the first time you have accessed the Red Hat Single Sign-On administration console, you are prompted to create an initial administration user. Create a new realm called wildfly-infra . From the drop down to the realm name, click Add realm , enter wildfly-infra in the Name field, and click Create . Create a client application called wildfly-console . Important The name of this client application must be wildfly-console . Select Clients and click Create . Enter wildfly-console in the Client ID field and click Save . In the Settings screen that appears, set Access Type to public , Valid Redirect URIs to http://localhost:9990/console/* , Web Origins to http://localhost:9990 , and click Save . Create a client application called wildfly-management . Select Clients and click Create . Enter wildfly-management in the Client ID field and click Save . In the Settings screen that appears, set Access Type to bearer-only and click Save . Create a role to grant access to the JBoss EAP management console. Select Roles and click Add Role . Enter ADMINISTRATOR in uppercase in the Role Name field and click Save . This procedure uses the ADMINISTRATOR role, but other roles are supported. For more information, see the Role-Based Access Control section of JBoss EAP's Security Architecture . Create a user and assign the ADMINISTRATOR role to them. Select Users and click Add user . Enter jboss in the Username field and click Save . Select the Credentials tab and set a password for this user. Select the Role Mappings tab, select ADMINISTRATOR and click Add selected to add the role to this user. Install the Red Hat Single Sign-On Client Adapter on JBoss EAP Download the Red Hat Single Sign-On client adapter for JBoss EAP 7 from the software downloads page . Unzip this file into the root directory of your JBoss EAP installation. Execute the adapter-elytron-install-offline.cli script to configure your JBoss EAP installation. Important This script adds the keycloak subsystem and other required resources in the elytron and undertow subsystems to standalone.xml . If you need to use a different configuration file, modify the script as needed. Configure JBoss EAP to Use Red Hat Single Sign-On In the EAP_HOME /bin/ directory, create a file called protect-eap-mgmt-services.cli with the following contents. # Create a realm for both JBoss EAP console and mgmt interface /subsystem=keycloak/realm=wildfly-infra:add(auth-server-url=http://localhost:8180/auth,realm-public-key= REALM_PUBLIC_KEY ) # Create a secure-deployment in order to protect mgmt interface /subsystem=keycloak/secure-deployment=wildfly-management:add(realm=wildfly-infra,resource=wildfly-management,principal-attribute=preferred_username,bearer-only=true,ssl-required=EXTERNAL) # Protect HTTP mgmt interface with Keycloak adapter /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm) /subsystem=elytron/http-authentication-factory=keycloak-mgmt-http-authentication:add(security-domain=KeycloakDomain,http-server-mechanism-factory=wildfly-management,mechanism-configurations=[{mechanism-name=KEYCLOAK,mechanism-realm-configurations=[{realm-name=KeycloakOIDCRealm,realm-mapper=keycloak-oidc-realm-mapper}]}]) /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory,value=keycloak-mgmt-http-authentication) /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade, value={enabled=true, sasl-authentication-factory=management-sasl-authentication}) # Enable RBAC where roles are obtained from the identity /core-service=management/access=authorization:write-attribute(name=provider,value=rbac) /core-service=management/access=authorization:write-attribute(name=use-identity-roles,value=true) # Create a secure-server in order to publish the JBoss EAP console configuration via mgmt interface /subsystem=keycloak/secure-server=wildfly-console:add(realm=wildfly-infra,resource=wildfly-console,public-client=true) # reload reload In this file, replace REALM_PUBLIC_KEY with the value of the public key. To obtain this value, log in to the Red Hat Single Sign-On administration console, select the wildfly-infra realm, navigate to Realm Settings Keys and click Public key . Start JBoss EAP. Important If you modified the adapter-elytron-install-offline.cli script when installing the Red Hat Single Sign-On client adapter to use a configuration file other than standalone.xml , be sure to start the JBoss EAP using that configuration. Execute the protect-eap-mgmt-services.cli script. Now, when you access the JBoss EAP management console at http://localhost:9990/console/ , you are redirected to Red Hat Single Sign-On to log in, and then redirected back to the JBoss EAP management console upon successful authentication. 1.3. Configuring security auditing for a legacy security domain You can use an audit module to monitor the events in the security subsystem. Auditing uses provider modules, custom implementations, or both to monitor events. After monitoring events, the audit module writes a log file, reads email notifications, or uses other measurable auditing mechanisms. Use the management console to configure security auditing settings for a security domain. Procedure Click on the Configuration tab. Navigate to Subsystems Security (Legacy) . Select an editable security domain and click View . Select the Audit tab and press Add to add a new audit module. Set a name for the module and fill in the Code field with the class name of the provider module. Optional: Add module options by editing the module and adding key/value pairs in the Module Options field. Press Enter to add a new value and press Backspace to remove an existing value. 1.4. Security auditing with Elytron You can use Elytron to complete security audits on triggering events. Security auditing refers to triggering events, such as writing to a log, in response to an authorization or authentication attempt. The type of security audit performed on events depends on your security realm configuration. 1.4.1. Elytron audit logging After you enable audit logging with the elytron subsystem, you can log Elytron authentication and authorization events within the application server. Elytron stores audit log entries in either JSON for storing individual events or SIMPLE for human readable text format. Elytron audit logging differs from other types of audit logging, such as audit logging for the JBoss EAP management interfaces. Elytron disables audit logging by default. You can enable audit logging by configuring any of the following log handlers for Elytron. You can add a log handler to a security domain. File audit logging Periodic rotating file audit logging Size rotating file audit logging syslog audit logging Custom audit logging You can use the aggregate-security-event-listener resource to send security events to more destinations, such as loggers. The aggregate-security-event-listener resource delivers all events to all listeners specified in the aggregate listener definition. You can use an audit module to monitor events for a legacy security domain. You can use the management console to configure security auditing settings for a legacy security domain. Additional resources For information about configuring auditing with the legacy security system, see Configuring security auditing for a legacy security domain . For more information about management interface audit logging options, see Management audit logging in the Configuration Guide . For more information about file audit logging, see Enabling file audit logging . For more information about periodic rotating file audit logging, see Periodic Rotating File Audit Logging . For more information about size rotating file audit logging, see Size rotating file audit logging . For more information about syslog audit logging, see syslog audit logging . For more information about custom audit logging, see Using custom security event listeners in Elytron . 1.4.2. Enabling file audit logging You can use the elytron subsystem to enable file audit logging for your standalone server or a server in a managed domain. File audit logging stores audit log messages in a single file within your file system. By default, Elytron specifies local-audit as the file audit logger. You must enable local-audit so that it can write Elytron audit logs to EAP_HOME/standalone/log/audit.log on a standalone server or EAP_HOME/domain/log/audit.log for a managed domain. Procedure Create a file audit log. Example of creating a file audit log by using the elytron subsystem: Add the file audit log to a security domain. Example command adding file audit log to a security domain Additional resources For more information about file audit logger attributes, see File audit logger attributes . 1.4.3. Enabling periodic rotating file audit logging You can use the elytron subsystem to enable periodic rotating file audit logging for your standalone server or a server in a domain domain. Periodic rotating file audit logging automatically rotates audit log files based on your configured schedule. Periodic rotating file audit logging is similar to default file audit logger, but periodic rotating file audit logging contains an additional attribute: suffix . The value of the suffix attribute is a date specified using the java.time.format.DateTimeFormatter format, such as .yyyy-MM-dd . Elytron automatically calculates the period of the rotation from the value provided with the suffix. The elytron subsystem appends the suffix to the end of a log file name. Procedure Create a periodic rotating file audit log. Example of creating periodic rotating file audit log in the elytron subsystem Add the periodic rotating file audit logger to a security domain. Example adding a periodic rotating file audit logger to a security domain Additional resources For information about periodic rotating file audit logger attributes, see the periodic-rotating-file-audit-log Attributes table. 1.4.4. Enabling size rotating file audit logging You can use the elytron subsystem to enable size rotating file audit logging for your standalone server or a server in a domain managed. Size rotating file audit logging automatically rotates audit log files when the log file reaches a configured file size. Size rotating file audit logging is similar to default file audit logger, but the size rotating file audit logging contains additional attributes. When the log file size exceeds the limit defined by the rotate-size attribute, Elytron appends the suffix .1 to the end of the current file, and Elytron creates a new log file. Elytron increments a suffix by one for existing log files. For example, Elytron renames audit_log.1 to audit_log.2 . Elytron continues the increments until a log file amount reaches the maximum number of log files, defined by max-backup-index . When a log files exceed the max-backup-index value, Elytron removes the file, for example audit_log.99 , that is the file that is over limit. Procedure Create a size rotating file audit log. Example of creating a size rotating file audit log by using the elytron subsystem: Add the size rotating audit logger to a security domain. Example of enabling a size rotating file audit log by using the elytron subsystem: Additional resources For information about size rotating file audit logging attributes, see the Size rotating file audit logging attributes table. 1.4.5. Enabling syslog audit logging You can use the elytron subsystem to enable syslog audit logging for your standalone server or a server in a domain managed. When you use syslog audit logging, you send the logging results to a syslog server, which provides more security options than logging to a local file. The syslog handler specify parameters used to connect to a syslog server, such as the syslog server's host name and the port on which the syslog server listens. You can define multiple syslog handlers and activate them simultaneously. Supported log formats include RFC5424 and RFC3164 . Supported transmission protocols include UDP, TCP, and TCP with SSL. When you define a syslog for the first instance, the logger sends an INFORMATIONAL priority event to syslog server containing the message as demonstrated in the following example: <format> refers to the RFC format configured for the audit logging handler, which defaults to RFC5424 value Procedure Add a syslog handler. Example of adding a syslog handler by using the elytron subsystem: You can also send logs to a syslog server over TLS: Example syslog configuration to send logs over TLS Add the syslog audit logger to a security domain. Example of adding a syslog audit logger to a security domain Additional resources For information about syslog-audit-log attributes, see the syslog-audit-log Attributes table. For more information enabling support for TLS by setting the ssl-context configuration, see Using a client-ssl-context . For more information about RFC5424 , see The Syslog Protocol . For more information about RFC3164 , see The BSD syslog Protocol . 1.4.6. Using custom security event listeners in Elytron You can use Elytron to define a custom event listener. A custom event listener manages the processing incoming security events. You can use the event listener for custom audit logging purposes, or you can use the event listener to authenticate users against your internal identity storage. Important Using the module management CLI command to add and remove modules is provided as a Technology Preview feature only. The module command is not appropriate for use in a managed domain or when connecting with a remote management CLI. You must manually add add or remove modules in a production environment. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. See Technology Preview Features Support Scope on the Red Hat Customer Portal for information about the support scope for Technology Preview features. Procedure Create a class that implements the java.util.function.Consumer<org.wildfly.security.auth.server.event.SecurityEvent> interface. For example, the following prints a message whenever a user succeeds or fails authentication. Example of creating a Java class that uses the specified interface: The Java class in the example prints a message whenever a user succeeds or fails authentication. Add the JAR that provides the custom event listener as a module to JBoss EAP, The following is an example of the management CLI command that adds a custom event listener as a module to Elytron. Example of using the module command to add a custom event listener as a module to Elytron: Reference the custom event listener in the security domain. Example of referencing a custom event listener in ApplicationDomain : Restart the server. The event listener receives security events from the specified security domain. Additional resources For information about manually adding or removing modules in a production environment, see Create a Custom Module Manually and Remove a Custom Module Manually in the Configuration Guide . For information about adding a custom event listener as a module, see Add a Custom Component to Elytron . 1.5. Configure One-way and Two-way SSL/TLS for Applications 1.5.1. Automatic Self-signed Certificate Creation for Applications When using the legacy security realms, JBoss EAP provides automatic generation of self-signed certificate for development purposes. Example: Server Log Showing Self-signed Certificate Creation This certificate is created for testing purposes and is assigned to the HTTPS interface used by applications. The keystore containing the certificate will be generated if the file does not exist the first time the HTTPS interface is accessed. Example: Default ApplicationRealm Using the Self-signed Certificate <security-realm name="ApplicationRealm"> <server-identities> <ssl> <keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/> </ssl> </server-identities> ... </security-realm> Example: Default HTTPS Interface Configuration <subsystem xmlns="urn:jboss:domain:undertow:10.0"> ... <server name="default-server"> ... <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/> <host name="default-host" alias="localhost"> ... Note If you want to disable the self-signed certificate creation, you will need to remove the generate-self-signed-certificate-host="localhost" from the server keystore configuration. The generate-self-signed-certificate-host attribute holds the host name for which the self-signed certificate should be generated. Warning This self-signed certificate is intended for testing purposes only and is not intended for use in production environments. For more information on configuring SSL/TLS for applications with Elytron, see the Enable One-way SSL/TLS for Applications using the Elytron Subsystem and Enable Two-way SSL/TLS for Applications using the Elytron Subsystem sections. For more information on configuring SSL/TLS for applications with legacy security, see the Enable One-way SSL/TLS for Applications Using Legacy Security Realms and Enable Two-way SSL/TLS for Applications Using Legacy Security Realms sections. 1.5.2. Using Elytron 1.5.2.1. Enable One-way SSL/TLS for Applications Using the Elytron Subsystem In JBoss EAP, you can enable one-way SSL/TLS for the for deployed applications using the JBoss EAP management CLI or the management console. In the management CLI, one-way SSL/TLS can be enabled in two ways: Using security command . Using elytron subsystem commands . Using a Security Command The security enable-ssl-http-server command can be used to enable one-way SSL/TLS for deployed applications. Example: Wizard Usage security enable-ssl-http-server --interactive Please provide required pieces of information to enable SSL: Key-store file name (default default-server.keystore): keystore.jks Password (blank generated): secret What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: What is the name of your organization? [Unknown]: What is the name of your City or Locality? [Unknown]: What is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]? Validity (in days, blank default): 365 Alias (blank generated): localhost Enable SSL Mutual Authentication y/n (blank n): n SSL options: key store file: keystore.jks distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown password: secret validity: 365 alias: localhost Server keystore file keystore.jks, certificate file keystore.pem and keystore.csr file will be generated in server configuration directory. Do you confirm y/n: y Note Once the command is executed, the management CLI will reload the server. One-way SSL/TLS is now enabled for applications. Using Elytron Subsystem Commands In JBoss EAP, you can use the elytron subsystem, along with the undertow subsystem, to enable one-way SSL/TLS for deployed applications. Configure a key-store in JBoss EAP. If the keystore file does not exist yet, the following commands can be used to generate an example key pair: Configure a key-manager that references your key-store . Important Red Hat did not specify the algorithm attribute in the command, because the Elytron subsystem uses KeyManagerFactory.getDefaultAlgorithm() to determine an algorithm by default. However, you can specify the algorithm attribute. To specify the algorithm attribute, you need to know what key manager algorithms are provided by the JDK you are using. For example, a JDK that uses SunJSSE provides the PKIX and SunX509 algorithms. In the command you can specify SunX509 as the key manager algorithm attribute. Configure a server-ssl-context that references your key-manager . Important You need to determine what SSL/TLS protocols you want to support. The example command above uses TLSv1.2 . You can use the cipher-suite-filter argument to specify which cipher suites are allowed, and the use-cipher-suites-order argument to honor server cipher suite order. The use-cipher-suites-order attribute by default is set to true . This differs from the legacy security subsystem behavior, which defaults to honoring client cipher suite order. Warning Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages. Check and see if the https-listener is configured to use a legacy security realm for its SSL configuration. The above command shows that the https-listener is configured to use the ApplicationRealm legacy security realm for its SSL configuration. Undertow cannot reference both a legacy security realm and an ssl-context in Elytron at the same time so you must remove the reference to the legacy security realm. Note If the result is undefined , you do not need to remove the reference to the security realm in the step. Remove the reference to the legacy security realm, and update the https-listener to use the ssl-context from Elytron. Note https-listener must always have either a security-realm or ssl-context configured. When changing between the two configurations, the commands must be executed as a single batch, as shown below. Reload the server. One-way SSL/TLS is now enabled for applications. Note You can disable one-way SSL/TLS for deployed applications using the disable-ssl-http-server command. security disable-ssl-http-server This command does not delete the Elytron resources. It configures the system to use the ApplicationRealm legacy security realm for its SSL configuration. Using Management Console You can enable SSL for applications by configuring the undertow subsystem using an SSL wizard in the management console. To access the wizard: Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Web (Undertow) Server . Click the name of the server to configure. Click View . Navigate to Listener HTTPS Listener . Select the listener for which SSL is to be enabled, and click Enable SSL to launch the wizard. The wizard guides you through the following scenarios for enabling SSL: You want to create a certificate store and generate a self-signed certificate. You want to obtain a certificate from Let's Encrypt Certificate Authority. You already have the certificate store on the file system, but no keystore configuration. You already have a keystore configuration that uses a valid certificate store. Using the wizard, you can optionally create a truststore for mutual authentication. 1.5.2.2. Enable Two-way SSL/TLS for Applications Using the Elytron Subsystem Obtain or generate your client keystores: USD keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret Export the client certificate: keytool -exportcert -keystore client.keystore.jks -alias client -keypass secret -storepass secret -file /path/to/client.cer Enable two-way SSL/TLS for deployed applications. In JBoss EAP, two-way SSL/TLS for deployed applications can be enabled either by using a security command or by using the elytron subsystem commands. Using a security command. The security enable-ssl-http-server command can be used to enable two-way SSL/TLS for the deployed applications. Note The following example does not validate the certificate as no chain of trust exists. If you are using a trusted certificate, then the client certificate can be validated without issue. Example: Wizard Usage security enable-ssl-http-server --interactive Please provide required pieces of information to enable SSL: Key-store file name (default default-server.keystore): server.keystore.jks Password (blank generated): secret What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: What is the name of your organization? [Unknown]: What is the name of your City or Locality? [Unknown]: What is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]? Validity (in days, blank default): 365 Alias (blank generated): localhost Enable SSL Mutual Authentication y/n (blank n): y Client certificate (path to pem file): /path/to/client.cer Validate certificate y/n (blank y): n Trust-store file name (management.truststore): server.truststore.jks Password (blank generated): secret SSL options: key store file: server.keystore.jks distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown password: secret validity: 365 alias: localhost client certificate: /path/to/client.cer trust store file: server.trustore.jks trust store password: secret Server keystore file server.keystore.jks, certificate file server.pem and server.csr file will be generated in server configuration directory. Server truststore file server.trustore.jks will be generated in server configuration directory. Do you confirm y/n: y Note Once the command is executed, the management CLI will reload the server. To complete the two-way SSL/TLS authentication, you need to import the server certificate into the client truststore and configure your client to present the client certificate. Using elytron subsystem commands. In JBoss EAP, you can also use the elytron subsystem, along with the undertow subsystem, to enable two-way SSL/TLS for deployed applications. Obtain or generate your keystore. Before enabling two-way SSL/TLS in JBoss EAP, you must obtain or generate the keystores, truststores and certificates you plan on using. Create a server keystore: Note The command above uses an absolute path to the keystore. Alternatively you can use the relative-to attribute to specify the base directory variable and path specify a relative path. Export the server certificate: Create a keystore for the server truststore and import the client certificate into the server truststore. Note The following example does not validate the certificate as no chain of trust exists. If you are using a trusted certificate, then the client certificate can be validated without issue. Configure a key-manager that references your keystore key-store . Important Red Hat did not specify the algorithm attribute in the command, because the Elytron subsystem uses KeyManagerFactory.getDefaultAlgorithm() to determine an algorithm by default. However, you can specify the algorithm attribute. To specify the algorithm attribute, you need to know what key manager algorithms are provided by the JDK you are using. For example, a JDK that uses SunJSSE provides the PKIX and SunX509 algorithms. In command you can specify SunX509 as the key manager algorithm attribute. Configure a trust-manager that references your truststore key-store . Important Red Hat did not specify the algorithm attribute in the command, because the Elytron subsystem uses TrustManagerFactory.getDefaultAlgorithm() to determine an algorithm by default. However, you can specify the algorithm attribute. To specify the algorithm attribute, you need to know what trust manager algorithms are provided by the JDK you are using. For example, a JDK that uses SunJSSE provides the PKIX and SunX509 algorithms. In the command you can specify PKIX as the trust manager algorithm attribute. Configure a server-ssl-context that references your key-manager , trust-manager , and enables client authentication: Important You need to determine what SSL/TLS protocols you want to support. The example command above uses TLSv1.2 . You can use the cipher-suite-filter argument to specify which cipher suites are allowed, and the use-cipher-suites-order argument to honor server cipher suite order. The use-cipher-suites-order attribute by default is set to true . This differs from the legacy security subsystem behavior, which defaults to honoring client cipher suite order. Warning Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages. Check and see if the https-listener is configured to use a legacy security realm for its SSL configuration. The above command shows that the https-listener is configured to use the ApplicationRealm legacy security realm for its SSL configuration. Undertow cannot reference both a legacy security realm and an ssl-context in the elytron subsystem at the same time. So you must remove the reference to the legacy security realm. Note If the result is undefined , you do not need to remove the reference to the security realm in the step. Remove the reference to the legacy security realm, and update the https-listener to use the ssl-context from Elytron. Note https-listener must always have either a security-realm or ssl-context configured. When changing between the two configurations, the commands must be executed as a single batch, as shown below. Reload the server. Note To complete the two-way SSL/TLS authentication, you need to import the server certificate into the client truststore and configure your client to present the client certificate. Configure your client to use the client certificate. You need to configure your client to present the trusted client certificate to the server to complete the two-way SSL/TLS authentication. For example, if using a browser, you need to import the trusted certificate into the browser's trust store. This procedure forces a two-way SSL/TLS but it does not change the original authentication method of the application. If you want to change the original authentication method, see Configure Authentication with Certificates in How to Configure Identity Management for JBoss EAP. Two-way SSL/TLS is now enabled for applications. Note You can disable two-way SSL/TLS for deployed applications using the disable-ssl-http-server command. security disable-ssl-http-server This command does not delete the Elytron resources. It configures the system to use the ApplicationRealm legacy security realm for its SSL configuration. 1.5.3. Configuring Certificate Revocation Using CRL in Elytron Configure the trust manager used for enabling two-way SSL/TLS to use Certificate Revocation List (CRL) for certificate revocation in Elytron. Prerequisites The trust manager is configured to use two-way SSL/TLS. The trust manager contains the certificate chain to be checked for revocation. Procedure Configure the trust manager to use CRLs obtained from distribution points referenced in your certificates. Override the CRL obtained from distribution points referenced in your certificates. Configure trust-manager to use CRL for certificate revocation. If an OCSP responder is also configured for certificate revocation, add attribute ocsp.prefer-crls with the value true in the trust manager to use CRL for certificate revocation: If no OCSP responder is configured for certificate revocation, the configuration is complete. Additional Information For a complete list of CRL attributes, see trust-manager Attributes . 1.5.4. Configuring Certification Revocation Using OCSP in Elytron Configure the trust manager used for enabling two-way SSL/TLS to use an Online Certificate Status Protocol (OCSP) responder for certificate revocation. OCSP is defined in RFC6960 . When both OCSP responder and CRL are configured for certificate revocation, the OCSP responder is invoked by default. Prerequisites The trust manager is configured to use two-way SSL/TLS. Procedure Configure the trust manager to use the OCSP responder defined in the certificate for certificate revocation. Override OCSP responder defined in the certificate. Additional Information For a complete list of attributes, see online-certificate-status Attributes . 1.5.5. Using Legacy Security Realms Important As a prerequisite, an SSL/TLS encryption key and certificate should be created and placed in an accessible directory. Additionally, relevant information, such as keystore aliases and passwords, desired cipher suites, should also be accessible. For examples on generating SSL/TLS Keys and Certificates, see the first two steps in the Setting up Two-way SSL/TLS for the Management Interfaces section. For more information about the HTTPS listener, including cipher suites, see the HTTPS Listener Reference section. 1.5.5.1. Enable One-way SSL/TLS for Applications Using Legacy Security Realms This example assumes that the keystore, identity.jks , has been copied to the server configuration directory and configured with the given properties. Administrators should substitute their own values for the example ones. Note The management CLI commands shown assume that you are running a JBoss EAP standalone server. For more details on using the management CLI for a JBoss EAP managed domain, see the JBoss EAP Management CLI Guide . Add and configure an HTTPS security realm first. Once the HTTPS security realm has been configured, configure an https-listener in the undertow subsystem that references the security realm: Warning Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages. Restart the JBoss EAP instance for the changes to take effect. 1.5.5.2. Enable Two-way SSL/TLS for Applications Using Legacy Security Realms Setting up two-way SSL/TLS for applications follows many of the same procedures outlined in Setting up Two-way SSL/TLS for the Management Interfaces . To set up two-way SSL/TLS for applications, you need to do the following: Generate the stores for both the client and server Export the certificates for both the client and server Import the certificates into the opposing truststores Define a security realm, for example CertificateRealm , on the server that uses the server's keystore and truststore Update the undertow subsystem to use the security realm and require client verification The first four steps are covered in Setting up Two-way SSL/TLS for the Management Interfaces . Important If the server has not been reloaded since the new security realm has been added, you must reload the server before performing the step. Update the Undertow Subsystem Once the keystores, certificates, truststores, and security realms have been created and configured, you need to add an HTTPS listener to the undertow subsystem, use the security realm you created, and require client verification: Important You must reload the server for these changes to take effect. Important Any client connecting to a JBoss EAP instance with two-way SSL/TLS enabled for applications must have access to a client certificate or keystore, in other words a client keystore whose certificate is included in the server's truststore. If the client is using a browser to connect to the JBoss EAP instance, you need to import that certificate or keystore into the browser's certificate manager. Note More details on using certificate-based authentication in applications, in addition to two-way SSL/TLS with applications, can be found in the Configuring a Security Domain to Use Certificate-based Authentication section of the JBoss EAP How to Configure Identity Management Guide . 1.6. Enable HTTP authentication for applications using the CLI security command In JBoss EAP, HTTP authentication, using an elytron HTTP authentication factory, can be enabled for the undertow security domain with the security enable-http-auth-http-server command. By default this command associates the application HTTP factory to the specified security domain. Example: Enable HTTP Authentication on the Undertow Security Domain Note Once the command is executed, the management CLI will reload the server and reconnect to it. If an HTTP factory already exists, then the factory is updated to use the mechanism defined by the --mechanism argument. 1.6.1. Disabling HTTP authentication for the management interfaces This procedure describe how to disable HTTP authentication for the management interfaces. Procedure To remove the active HTTP authentication factory use the following command. Alternatively, you can use the following command to remove specific mechanisms from the active SASL authentication factory. 1.7. SASL Authentication Mechanisms Simple Authentication and Security Layer (SASL) authentication mechanisms are used for defining the mechanisms for authenticating connections to a JBoss EAP server using the elytron subsystem, and for clients connecting to servers. Clients can be other JBoss EAP instances, or Elytron Client. SASL authentication mechanisms in JBoss EAP are also significantly used in Elytron Integration with the Remoting Subsystem . 1.7.1. Choosing SASL Authentication Mechanisms Note Although JBoss EAP and Elytron Client work with a variety of SASL authentication mechanisms, you must ensure that the mechanisms you use are supported. See this list for the support levels for SASL authentication mechanisms . The authentication mechanisms you use depends on your environment and desired authentication method. The following list summarizes the use of some of the supported SASL authentication mechanisms : ANONYMOUS Unauthenticated guest access. DIGEST-MD5 Uses HTTP digest authentication as a SASL mechanism. EXTERNAL Uses authentication credentials that are implied in the context of the request. For example, IPsec or TLS authentication. Mechanisms beginning with GS Authentication using Kerberos. JBOSS-LOCAL-USER Provides authentication by testing that the client has the same file access as the local user that is running the JBoss EAP server. This is useful for other JBoss EAP instances running on the same machine. OAUTHBEARER Uses authentication provided by OAuth as a SASL mechanism. PLAIN Plain text username and password authentication. Mechanisms beginning with SCRAM Salted Challenge Response Authentication Mechanism (SCRAM) that uses a specified hashing function. Mechanisms ending with -PLUS Indicates a channel binding variant of a particular authentication mechanism. You should use these variants when the underlying connection uses SSL/TLS. For more information on individual SASL authentication mechanisms, see the IANA SASL mechanism list and individual mechanism memos . 1.7.2. Configuring SASL Authentication Mechanisms on the Server Side Configuring SASL authentication mechanisms on the server side is done using SASL authentication factories. There are two levels of configuration required: A sasl-authentication-factory , where you specify authentication mechanisms. A configurable-sasl-server-factory that aggregates one or more of sasl-authentication-factory , and configures mechanism properties as well as optionally applying filters to enable or disable certain authentication mechanisms. The following example demonstrates creating a new configurable-sasl-server-factory , and a sasl-authentication-factory that uses DIGEST-MD5 as a SASL authentication mechanism for application clients. 1.7.3. Specifying SASL Authentication Mechanisms on the Client Side SASL authentication mechanisms used by a client are specified using a sasl-mechanism-selector . You can specify any supported SASL authentication mechanisms that are exposed by the server that the client is connecting to. A sasl-mechanism-selector is defined in Elytron configurations where authentication is configured: In the elytron subsystem, this is an attribute of an authentication-configuration . For example: An example of using an authentication-configuration with a sasl-mechanism-selector can be seen in Configuring SSL or TLS with elytron . For Elytron Client, it is specified under the configuration element of authentication-configurations in the client configuration file, usually named wildfly-config.xml . For example: <configuration> <authentication-client xmlns="urn:elytron:client:1.2"> <authentication-rules> <rule use-configuration="default" /> </authentication-rules> <authentication-configurations> <configuration name="default"> <sasl-mechanism-selector selector="#ALL" /> ... </configuration> </authentication-configurations> </authentication-client> </configuration> See How to Configure Identity Management for more information on configuring client authentication with Elytron Client . sasl-mechanism-selector Grammar The selector string for sasl-mechanism-selector has a specific grammar. In a simple form, individual mechanisms are specified by listing their names in order, separated by a spaces. For example, to specify DIGEST-MD5, SCRAM-SHA-1, and SCRAM-SHA-256 as allowed authentication mechanisms, use the following string: DIGEST-MD5 SCRAM-SHA-1 SCRAM-SHA-256 . More advanced usage of the grammar can use the following special tokens: #ALL : All mechanisms. #FAMILY( NAME ) : Mechanisms belonging to the specified mechanism family. For example, the family could be DIGEST, EAP, GS2, SCRAM, or IEC-ISO-9798. #PLUS : Mechanisms that use channel binding. For example, SCRAM-SHA- XXX -PLUS or GS2- XXX -PLUS. #MUTUAL : Mechanisms that authenticate the server in some way, for example making the server prove that the server knows the password. #MUTUAL includes families such as #FAMILY(SCRAM) and #FAMILY(GS2) . #HASH( ALGORITHM ) : Mechanisms that use the specified hash algorithm. For example, the algorithm could be MD5, SHA-1, SHA-256, SHA-384, or SHA-512. The above tokens and names can also be used with the following operations and predicates: - : Forbids ! : Inverts && : And || : Or == : Equals ? : If #TLS : Is true when TLS is active, otherwise false. Below are some examples of sasl-mechanism-selector strings and their meaning: #TLS && !#MUTUAL : When TLS is active, all mechanisms without mutual authentication. #ALL -ANONYMOUS : All mechanisms, except for ANONYMOUS. SCRAM-SHA-1 SCRAM-SHA-256 : Adds those two mechanisms in that order. (SCRAM-SHA-1 || SCRAM-SHA-256) : Adds the two mechanisms in the order that the provider or server presents them. !#HASH(MD5) : Any mechanism that does not use the MD5 hashing algorithm. #FAMILY(DIGEST) : Any digest mechanism. 1.7.4. Configuring SASL Authentication Mechanism Properties You can configure authentication mechanism properties on both the server side and on the client side. On the server side, you define authentication mechanism properties in the configurable-sasl-server-factory . The following example defines the com.sun.security.sasl.digest.utf8 property with a value of false . On the client side, you define authentication mechanisms properties in the client's authentication configuration: In the elytron subsystem, define the authentication mechanism properties in your authentication-configuration . The following example defines the wildfly.sasl.local-user.quiet-auth property with a value of true . For Elytron Client, authentication mechanism properties are specified under the configuration element of authentication-configurations in the client configuration file, usually named wildfly-config.xml . For example: ... <authentication-configurations> <configuration name="default"> <sasl-mechanism-selector selector="#ALL" /> <set-mechanism-properties> <property key="wildfly.sasl.local-user.quiet-auth" value="true" /> </set-mechanism-properties> ... </configuration> </authentication-configurations> ... You can see a list of standard Java SASL authentication mechanism properties in the Java documentation . Other JBoss EAP-specific SASL authentication mechanism properties are listed in the Authentication Mechanisms Reference . 1.8. Elytron Integration with the ModCluster Subsystem One of the security capabilities exposed by elytron subsystem is a client ssl-context that can be used to configure the modcluster subsystem to communicate with a load balancer using SSL/TLS. When protecting the communication between the application server and the load balancer, you need to define a client ssl-context in order to: Define a truststore holding the certificate chain that will be used to validate load balancer's certificate. Define a trust manager to perform validations against the load balancer's certificate. 1.8.1. Defining a Client SSL Context and Configuring ModCluster Subsystem The following procedure requires that a truststore and trust manager be configured. For information on creating these see Create an Elytron Truststore and Create an Elytron Trust Manager . Create the client SSL context. This SSL context is going to be used by the modcluster subsystem when connecting to the load balancer using SSL/TLS: Reference the newly created client SSL context using one of the following options. Configure the modcluster subsystem by setting the ssl-context . Configure the undertow subsystem by defining the ssl-context attribute of the mod-cluster filter. Reload the server. For configuring the modcluster subsystem and using two-way authentication , along with the trust manager, the key manager also needs to be configured. Create the keystore. Configure the key manager. Create the client SSL context. Note If you already have an existing client SSL context, you can add the key-manager to it as follows: Reload the server. 1.9. Elytron Integration with the JGroups Subsystem Components in the elytron subsystem may be referenced when defining authorization or encryption protocols in the jgroups subsystem. Full instructions on configuring these protocols are found in the Securing a Cluster section of the Configuration Guide . 1.10. Elytron Integration with the Remoting Subsystem 1.10.1. Elytron integration with remoting connectors A remoting connector is specified by a SASL authentication factory, a socket binding, and an optional SSL context. In particular, the attributes for a connector are as follows: sasl-authentication-factory A reference to the SASL authentication factory to use for authenticating requests to this connector. For more information on creating this factory, see Create an Elytron Authentication Factory . socket-binding A reference to the socket binding, detailing the interface and port where the connector should listen for incoming requests. ssl-context An optional reference to the server-side SSL Context to use for this connector. The SSL Context contains the server key manager and trust manager to be used, and should be defined in instances where SSL is desired. For example, a connector can be added as follows, where SASL_FACTORY_NAME is an already defined authentication factory and SOCKET_BINDING_NAME is an existing socket binding. If SSL is desired, a preconfigured server-ssl-context may be referenced using the ssl-context attribute, as seen below. 1.10.1.1. Enabling one-way SSL/TLS for remoting connectors using the elytron subsystem The following SASL mechanisms support channel binding to external secure channels, such as SSL/TLS: GS2-KRB5-PLUS SCRAM-SHA-1-PLUS SCRAM-SHA-256-PLUS SCRAM-SHA-384-PLUS SCRAM-SHA-512-PLUS To use any of these mechanisms, you can configure a custom SASL factory , or modify one of the predefined SASL authentication factories. A SASL mechanism selector can be used on the client to specify the appropriate SASL mechanism. Prerequisites A key-store is configured. A key-manager is configured. A server-ssl-context is configured that references the defined key-manager Procedure Create a socket-binding for the connector. The following command defines the oneWayBinding binding that listens on port 11199 . Create a connector that references the SASL authentication factory, the previously created socket binding, and the SSL context. Important In cases where you have both a security-realm and ssl-context defined, JBoss EAP will use the SSL/TLS configuration provided by ssl-context . Configure the client to trust the server certificate. A generic example client is found at Elytron Client Side One Way Example . This example configures an ssl-context using the client trust-store . Additional resources key-store key-manager server-ssl-context 1.10.1.2. Enabling two-way SSL/TLS for remoting connectors using the elytron subsystem The following SASL mechanisms support channel binding to external secure channels, such as SSL/TLS: GS2-KRB5-PLUS SCRAM-SHA-1-PLUS SCRAM-SHA-256-PLUS SCRAM-SHA-384-PLUS SCRAM-SHA-512-PLUS To use any of these mechanisms, you can configure a custom SASL factory , or modify one of the predefined SASL authentication factories to offer any of these mechanisms. A SASL mechanism selector can be used on the client to specify the appropriate SASL mechanism. Prerequisites Separate key-store components for the client and server certificates are configured. A key-manager for the server key-store is configured. A trust-manager for the server trust-store is configured. A server-ssl-context that references the defined key-manager and trust-manager is configured. Procedure Create a socket-binding for the connector. The following command defines the twoWayBinding binding that listens on port 11199 . Create a connector that references the SASL authentication factory, the previously created socket binding, and the SSL context. Important In cases where you have both a security-realm and ssl-context defined, JBoss EAP will use the SSL/TLS configuration provided by ssl-context . Configure your client to trust the server certificate, and to present its certificate to the server. You need to configure your client to present the trusted client certificate to the server to complete the two-way SSL/TLS authentication. For example, if using a browser, you need to import the trusted certificate into the browser's truststore. A generic example client is found at Elytron Client Side Two Way Example . This example configures an ssl-context using the client trust-store and key-store . Two-way SSL/TLS is now enabled on the remoting connector. Additional resources key-store key-manager trust-manager trust-store server-ssl-context SASL mechanism selector 1.10.2. Elytron integration with remoting HTTP connectors A remote HTTP connection is specified by referencing a connector in the undertow subsystem and a SASL authentication factory defined in the elytron subsystem. The HTTP connector provides the configuration for the HTTP upgrade-based remoting connector, and connects to an HTTP listener specified by the connector-ref attribute. The attributes for a http-connector are as follows: connector-ref A reference to a predefined undertow listener. sasl-authentication-factory A reference to the SASL authentication factory to use for authenticating requests to this connector. For more information on creating this factory, see Create an Elytron Authentication Factory . For example, a http-connector can be added as follows, where CONNECTOR_NAME references the undertow listener, and SASL_FACTORY_NAME is an already defined authentication factory in the elytron subsystem. 1.10.2.1. Enabling one-way SSL on the remoting HTTP connector The following SASL mechanisms support channel binding to external secure channels, such as SSL/TLS: GS2-KRB5-PLUS SCRAM-SHA-1-PLUS SCRAM-SHA-256-PLUS SCRAM-SHA-384-PLUS SCRAM-SHA-512-PLUS To use any of the above mechanisms, a custom SASL factory can be configured, or one of the predefined SASL authentication factories can be modified to offer any of these mechanisms. A SASL mechanism selector can be used on the client to specify the appropriate SASL mechanism. Prerequisites A key-store is configured. A key-manager is configured. A server-ssl-context is configured that references the defined key-manager . Procedure Check whether the https-listener is configured to use a legacy security realm for its SSL configuration. The above command shows that the https-listener is configured to use the ApplicationRealm legacy security realm for its SSL configuration. Undertow cannot reference both a legacy security realm and an ssl-context in Elytron at the same time so you must remove the reference to the legacy security realm. Note If the result is undefined , you do not need to remove the reference to the security realm in the step. Remove the reference to the legacy security realm, and update the https-listener to use the ssl-context from Elytron. Note https-listener must always have either a security-realm or ssl-context configured. When changing between the two configurations, the commands must be executed as a single batch, as shown below. Create an HTTP connector that references the HTTPS listener and the SASL authentication factory. Reload the server. Configure the client to trust the server certificate. For example, if using a browser, you need to import the trusted certificate into the browser's truststore. Additional resources key-store key-manager server-ssl-context custom SASL factory 1.10.2.2. Enabling two-way SSL/TLS on the remoting HTTP connectors The following SASL mechanisms support channel binding to external secure channels, such as SSL/TLS: GS2-KRB5-PLUS SCRAM-SHA-1-PLUS SCRAM-SHA-256-PLUS SCRAM-SHA-384-PLUS SCRAM-SHA-512-PLUS To use any of the above mechanisms, a custom SASL factory can be configured, or one of the predefined SASL authentication factories can be modified to offer any of these mechanisms. A SASL mechanism selector can be used on the client to specify the appropriate SASL mechanism. Prerequisites Separate key-store components for the client and server certificates are configured. A key-manager for the server key-store is configured. A trust-manager for the server trust-store is configured. A server-ssl-context that references the defined key-manager and trust-manager is configured. Procedure Check whether the https-listener is configured to use a legacy security realm for its SSL configuration. The above command shows that the https-listener is configured to use the ApplicationRealm legacy security realm for its SSL configuration. Undertow cannot reference both a legacy security realm and an ssl-context in Elytron at the same time so you must remove the reference to the legacy security realm. Note If the result is undefined , you do not need to remove the reference to the security realm in the step. Remove the reference to the legacy security realm, and update the https-listener to use the ssl-context from Elytron. Note https-listener must always have either a security-realm or ssl-context configured. When changing between the two configurations, the commands must be executed as a single batch, as shown below. Create an HTTP connector that references the HTTPS listener and the SASL authentication factory. Reload the server. Configure your client to trust the server certificate, and to present its certificate to the server. Complete the two-way SSL/TLS authentication by configuring your client to present the trusted client certificate to the server. For example, if using a browser, you need to import the trusted certificate into the browser's truststore. Two-way SSL/TLS is now enabled on the remoting HTTP connector. Important In cases where you have both a security-realm and ssl-context defined, JBoss EAP will use the SSL/TLS configuration provided by ssl-context . Additional resources key-store key-manager trust-manager trust-store server-ssl-context custom SASL factory 1.10.3. Elytron integration with remoting outbound connectors A remote outbound connection is specified by an outbound socket binding and an authentication context. The authentication context provides all of the security information that is needed for the connection. In particular, the attributes for a remote-outbound-connection are as follows: outbound-socket-binding-ref - The name of the outbound socket binding, which is used to determine the destination address and port for the connection. authentication-context - A reference to the authentication context, which contains the authentication configuration and the defined SSL context, if one exists, required for the connection. For information on defining an authentication context, see Creating an Authentication Context . For example, a remote-outbound-connection can be added as follows, where OUTBOUND_SOCKET_BINDING_NAME is an already defined outbound-socket-binding and AUTHENTICATION_CONTEXT_NAME is an authentication-context that has already been defined in the elytron subsystem configuration. Additional resources Creating an Authentication Context 1.11. Additional Elytron Components for SSL/TLS The basic concepts behind configuring one-way SSL/TLS and two-way SSL/TLS are covered in the following: Enable One-way SSL/TLS for Applications Using the Elytron Subsystem Enable Two-way SSL/TLS for Applications Using the Elytron Subsystem Enable One-way SSL/TLS for the Management Interfaces Using the Elytron Subsystem Enable Two-way SSL/TLS for the Management Interfaces Using the Elytron Subsystem Elytron also offers some additional components for configuring SSL/TLS. 1.11.1. Using an ldap-key-store An ldap-key-store allows you to use a keystore stored in an LDAP server. You can use an ldap-key-store in the same way as you use a key-store . Note It is not possible to use a Jakarta Management ObjectName to decrypt the LDAP credentials. Instead, credentials can be secured by using a credential store. For information about credential stores, see Credential store in Elytron . To create and use an ldap-key-store : Configure a dir-context . To connect to the LDAP server from JBoss EAP, you need to configure a dir-context that provides the URL as well as the principal used to connect to the server. Example: dir-context Configure an ldap-key-store . When you configure an ldap-key-store , you need to specify both the dir-context used to connect to the LDAP server as well as how to locate the keystore stored in the LDAP server. At a minimum, this requires you to specify a search-path . Example: ldap-key-store Use the ldap-key-store . Once you have defined your ldap-key-store , you can use it in the same places where a key-store could be used. For example, you could use an ldap-key-store when configuring One-way SSL/TLS and Two-way SSL/TLS for applications. For the full list of attributes for ldap-key-store as well as other Elytron components, see Elytron Subsystem Components Reference . 1.11.2. Using a filtering-key-store A filtering-key-store allows you to expose a subset of aliases from an existing key-store , and use it in the same places you could use a key-store . For example, if a keystore contained alias1 , alias2 , and alias3 , but you only wanted to expose alias1 and alias3 , a filtering-key-store provides you several ways to do that. To create a filtering-key-store : Configure a key-store . Configure a filtering-key-store . When you configure a filtering-key-store , you specify which key-store you want to filter and the alias-filter for filtering aliases from the key-store . The filter can be specified in one of the following formats: alias1,alias3 , which is a comma-delimited list of aliases to expose. ALL:-alias2 , which exposes all aliases in the keystore except the ones listed. NONE:+alias1:+alias3 , which exposes no aliases in the keystore except the ones listed. This example uses a comma-delimted list to expose alias1 and alias3 . Note The alias-filter attribute is case sensitive. Because the use of mixed-case or uppercase aliases, such as elytronAppServer , might not be recognized by some keystore providers, it is recommended to use lowercase aliases, such as elytronappserver . Use the filtering-key-store . Once you have defined your filtering-key-store , you can use it in the same places where a key-store could be used. For example, you could use a filtering-key-store when configuring One-way SSL/TLS and Two-way SSL/TLS for applications. For the full list of attributes for filtering-key-store as well as other Elytron components, see Elytron Subsystem Components Reference . 1.11.3. Reload a Keystore You can reload a keystore configured in JBoss EAP from the management CLI. This is useful in cases where you have made changes to certificates referenced by a keystore. To reload a keystore: 1.11.4. Reinitialize a Key Manager You can reinitialize a key-manager configured in JBoss EAP from the management CLI. This is useful in cases where you have made changes in certificates provided by keystore resource and you want to apply this change to new SSL connections without restarting the server. Note If the key-store is file based then it must be loaded first. To reinitialize a key-manager : 1.11.5. Reinitialize a Trust Manager You can reinitialize a trust-manager configured in JBoss EAP from the management CLI or the management console. This is useful when you have made changes to certificates provided by a keystore resource and want to apply the changes to the new SSL connections without restarting the server. Reinitializing a Trust Manager from the management CLI Note If the key-store is file based then it must be loaded first. To reinitialize a trust-manager : Reinitializing a Trust Manager from the management console Navigate to the management console and click the Runtime tab. In the Monitor column, click Security (Elytron) . In the Security column, click SSL View . On the navigation pane, click Trust Manager . Click Initialize on the top right corner of the screen to reinitialize a trust-manager . 1.11.6. Keystore Alias The alias denotes the stored secret or credential in the store. If you add a keystore to the elytron subsystem using the key-store component, you can check the keystore's contents using the alias related key-store operations. The different operations for alias manipulation are: read-alias - Read an alias from a keystore. read-aliases - Read aliases from a keystore. remove-alias - Remove an alias from a keystore. For example, to read an alias: 1.11.7. Using a client-ssl-context A client-ssl-context is used for providing an SSL context when the JBoss EAP instance creates an SSL connection as a client, such as using SSL in remoting. To create a client-ssl-context : Create key-store , key-manager , and trust-manager components as needed. If establishing a two-way SSL/TLS connection, you need to create separate key-store components for the client and server certificates, a key-manager for the client key-store , and a trust-manager for the server key-store . Alternatively, if you are doing a one-way SSL/TLS connection, you need to create a key-store for the server certificate and a trust-manager that references it. Examples on creating keystores and truststores are available in the Enable Two-way SSL/TLS for Applications using the Elytron Subsystem section. Create a client-ssl-context . Create a client-ssl-context referencing keystores, truststores, as well as any other necessary configuration options. Example: client-ssl-context Reference the client-ssl-context . For the full list of attributes for client-ssl-context as well as other Elytron components, see Elytron Subsystem Components Reference . 1.11.8. Using a server-ssl-context A server-ssl-context is used for providing a server-side SSL context. In addition to the usual configuration for an SSL context, it is possible to configure additional items such as cipher suites and protocols. The SSL context will wrap any additional items that are configured. Create key-store , key-manager , and trust-manager components as needed. If establishing a two-way SSL/TLS connection, you need to create separate key-store components for the client and server certificates, a key-manager for the server key-store , and a trust-manager for the server trust-store . Alternatively, if you are doing a one-way SSL/TLS connection, you need to create a key-store for the server certificate and a key-manager that references it. Examples on creating keystores and truststores are available in the Enable Two-way SSL/TLS for Applications Using the Elytron Subsystem section. Create a server-ssl-context . Create a server-ssl-context that references the key manager, trust manager, or any other desired configuration options using one of the options outlined below. Add a Server SSL Context Using the Management CLI Important You need to determine what HTTPS protocols will be supported. The example commands above use TLSv1.2 . You can use the cipher-suite-filter argument to specify which cipher suites are allowed, and the use-cipher-suites-order argument to honor server cipher suite order. The use-cipher-suites-order attribute by default is set to true . This differs from the legacy security subsystem behavior, which defaults to honoring client cipher suite order. Add a Server SSL Context Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Other Settings and click View . Click on SSL Server SSL Context and click Add to configure a new server SSL context. For the full list of attributes for server-ssl-context as well as other Elytron components, see Elytron Subsystem Components Reference . 1.11.9. Using a server-ssl-sni-context A server-ssl-sni-context is used for providing a server-side SNI matching. It provides matching rules to correlate host names to SSL contexts, along with a default in case none of the provided host names are matched. The SSL SNI contexts can be used in place of a standard server SSL context, such as when defining a context in the undertow subsystem. Create key-store , key-manager , trust-manager , and server-ssl-context components as needed. There must be a server SSL context defined to create the server-ssl-sni-context . Create a server-ssl-sni-context that provides matching information for the server-ssl-context elements. A default SSL context must be specified, using the default-ssl-context attribute, which will be used if no matching host names are found. The host-context-map accepts a comma-separated list of host names to match to the various SSL contexts. The following would be used to define a server-ssl-sni-context that defaults to the serverSSL SSL context, and matches incoming requests for www.example.com to the exampleSSL context. Note The attribute value for host matching works as a regular expression, so be sure to escape any periods (.) used to delimit the domain name. Configure server-ssl-sni-context Using the Management Console Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Configuration Subsystems Security (Elytron) Other Settings and click View . Click SSL Server SSL SNI Context to configure the required ssl-sni-context . For the complete list of attributes for Elytron components, see Elytron Subsystem Components Reference . 1.11.10. Custom SSL Components When configuring SSL/TLS in the elytron subsystem, you can provide and use custom implementations of the following components: key-store key-manager trust-manager client-ssl-context server-ssl-context Warning It is not recommended to provide custom implementations of any component outside of the trust-manager without an intimate knowledge of the Java Secure Socket Extension (JSSE). Important When using FIPS it is not possible to utilize a custom trust manager or key manager, as FIPS requires these managers be embedded in the JDK for security reasons. Similar behavior can be accomplished by implementing a SecurityRealm that validates X509 evidences. When creating custom implementations of Elytron components, they must present the appropriate capabilities and requirements. For more details on capabilities and requirements, see the Capabilities and Requirements section of the JBoss EAP Security Architecture guide. Implementation details for each component are provided by the JDK vendor. 1.11.10.1. Add a Custom Component to Elytron The following steps describe adding a custom component within Elytron. Add the JAR containing the provider for the custom component as a module into JBoss EAP, declaring any required dependencies, such as javax.api : Important Using the module management CLI command to add and remove modules is provided as Technology Preview only. This command is not appropriate for use in a managed domain or when connecting to the management CLI remotely. Modules should be added and removed manually in a production environment. For more information, see the Create a Custom Module Manually and Remove a Custom Module Manually sections of the JBoss EAP Configuration Guide . Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. See Technology Preview Features Support Scope on the Red Hat Customer Portal for information about the support scope for Technology Preview features. When the component is added to the elytron subsystem the java.util.ServiceLoader will be used to discover the provider. Alternatively, a reference to the provider can be provided by defining a provider-loader . There are two methods of creating the loader, and only one should be implemented for each component. Reference the provider directly when defining the provider-loader : Include a reference to the provider in META-INF/services/java.security.Provider . This reference is automatically created when using the @MetaInfServices annotation in org.kohsuke.metainf-services . When using this method only the module needs to be referenced by the provider-loader , as seen below: Add the custom component into Elytron's configuration, using the appropriate element for the type to be added and referencing any defined providers. For instance, to define a trust manager, the trust-manager element would be used, as seen in the following command: Example: Adding a Custom Trust Manager Once defined, the component can be referenced from other elements. Additional resources For more information see modules and dependencies . 1.11.10.2. Including Arguments in a Custom Elytron Component You can include arguments within a custom component if your class implements the initialize method, as seen below. void initialize(final Map<String, String> configuration); This method allows the custom class to receive a set of configuration strings when defined. These are passed in using the configuration attribute when defining the component. For instance, the following example defines an attribute named myAttribute with a value of myValue . 1.11.10.3. Using Custom Trust Managers with Elytron By implementing a custom trust manager, it is possible to extend the validation of certificates when using HTTPS in Undertow, LDAPS in a dir-context , or any place where Elytron is used for SSL connections. This component is responsible for making trust decisions for the server, and it is strongly recommended that these be implemented if a custom trust manager is used. Important When using FIPS it is not possible to utilize a custom trust manager, as FIPS requires this manager be embedded in the JDK for security reasons. Similar behavior can be accomplished by implementing a SecurityRealm that validates X509 evidences. Requirements for Implementing a Custom Trust Manager When using a custom trust manager, the following must be implemented: A trust manager that implements the X509ExtendedTrustManager interface. A trust manager factory that extends TrustManagerFactorySpi . The provider of the trust manager factory. The provider must be included in the JAR file to be added into JBoss EAP. Any implemented classes must be included in JBoss EAP as a module. Classes are not required to be in one module, and can be loaded from module dependencies. Example Implementations The following example demonstrates a provider that registers the custom trust manager factory as a service. Example: Provider import org.kohsuke.MetaInfServices; import javax.net.ssl.TrustManagerFactory; import java.security.Provider; import java.util.Collections; import java.util.List; import java.util.Map; @MetaInfServices(Provider.class) public class CustomProvider extends Provider { public CustomProvider() { super("CustomProvider", 1.0, "Demo provider"); System.out.println("CustomProvider initialization."); final List<String> emptyList = Collections.emptyList(); final Map<String, String> emptyMap = Collections.emptyMap(); putService(new Service(this, TrustManagerFactory.class.getSimpleName(),"CustomAlgorithm", CustomTrustManagerFactorySpi.class.getName(), emptyList, emptyMap)); } } The following example demonstrates a custom trust manager. This trust manager contains overloaded methods on checking if a client or server is trusted. Example: TrustManager import javax.net.ssl.SSLEngine; import javax.net.ssl.X509ExtendedTrustManager; import java.net.Socket; import java.security.cert.CertificateException; import java.security.cert.X509Certificate; public class CustomTrustManager extends X509ExtendedTrustManager { public void checkClientTrusted(X509Certificate[] x509Certificates, String s, Socket socket) throws CertificateException { // Insert your code here } public void checkServerTrusted(X509Certificate[] x509Certificates, String s, Socket socket) throws CertificateException { // Insert your code here } public void checkClientTrusted(X509Certificate[] x509Certificates, String s, SSLEngine sslEngine) throws CertificateException { // Insert your code here } public void checkServerTrusted(X509Certificate[] x509Certificates, String s, SSLEngine sslEngine) throws CertificateException { // Insert your code here } public void checkClientTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException { // Insert your code here } public void checkServerTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException { // Insert your code here } public X509Certificate[] getAcceptedIssuers() { // Insert your code here } } The following example is a factory used to return instances of the trust manager. Example: TrustManagerFactorySpi import javax.net.ssl.ManagerFactoryParameters; import javax.net.ssl.TrustManager; import javax.net.ssl.TrustManagerFactorySpi; import java.security.InvalidAlgorithmParameterException; import java.security.KeyStore; import java.security.KeyStoreException; public class CustomTrustManagerFactorySpi extends TrustManagerFactorySpi { protected void engineInit(KeyStore keyStore) throws KeyStoreException { // Insert your code here } protected void engineInit(ManagerFactoryParameters managerFactoryParameters) throws InvalidAlgorithmParameterException { // Insert your code here } protected CustomTrustManager[] engineGetTrustManagers() { // Insert your code here } } Adding the Custom Trust Manager Once the provider and trust manager have been created, add them to the elytron subsystem by using the steps outlined in Add a Custom Component to Elytron . 1.11.11. Default SSLContext Many libraries used within deployments might require SSL configuration for connections they establish. These libraries tend to be configurable by the caller. If no configuration is provided, they use the default SSLContext for the process. The default SSLContext is available using the following method call: javax.net.ssl.SSLContext.getDefault(); By default this SSLContext is configured using system properties. However, within the elytron subsystem, it is possible to specify which one of the configured contexts should be associated and used as the default. To make use of this feature, configure your SSLContext as normal. The following command can then be used to specify which SSLContext should be used as the default. As existing services and deployments could have cached the default SSLContext prior to this being set, a reload is required to ensure that the default gets set before the deployments are activated. If the default-ssl-context attribute is subsequently undefined , the standard APIs do not provide any mechanism to revert the default. In this situation, the Java process would need be restarted. 1.11.12. Using a Certificate Revocation List If you want to validate a certificate against a certificate revocation list (CRL), you can configure this using the certificate-revocation-list attribute for a trust manager in the elytron subsystem. For example: For more information on the available attributes for a trust manager, see the trust-manager attributes table table. Note Your truststore must contain the certificate chain in order to check the validity of both the certification revocation list and the certificate. The truststore should not contain end-entity certificates, just certificate authority and intermediate certificates. You can instruct the trust manager to reload the certificate revocation list by using the reload-certificate-revocation-list operation. 1.11.13. Using a Certificate Authority to Manage Signed Certificates You can obtain and manage signed certificates using the JBoss EAP management CLI and the management console. This allows you to create a signed certificate directly from the CLI or the console and then import it into the required keystore. Note Many of the commands in this section have an optional staging parameter that indicates whether the certificate authority's staging URL should be used. This value defaults to false , and is designed to assist in testing purposes. This parameter should never be enabled in a production environment. Configure a Let's Encrypt Account As of JBoss EAP 7.4, Let's Encrypt is the only supported certificate authority. To manage signed certificates an account must be created with the certificate authority, and the following information provided: A keystore to contain the alias of the certificate authority account key. The alias of the certificate authority. If the provided alias does not exist in the given keystore, then one will be created and stored as a private key entry. An optional list of URLs, such as email addresses, that the certificate authority can contact in the result of any issues. Create an Account with the Certificate Authority Once an account has been configured it may be created with the certificate authority by agreeing to their terms of service. Update an Account with the Certificate Authority The certificate authority account options can be updated using the update-account command. Change the Account Key Associated with the Certificate Authority The key associated with the certificate authority account can be changed by using the change-account-key command. Deactivate the Account with the Certificate Authority If the account is no longer desired, then it may be deactivated by using the deactivate-account command. Get the Metadata Associated with the Certificate Authority The metadata for the account can be queried with the get-metadata command. This provides the following information: A URL to the terms of service. A URL to the certificate authority website. A list of the certificate authority accounts. Whether or not an external account is required. Configure a Let's Encrypt Account Using Management Console To configure a Let's Encrypt account using the management console: Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Runtime Host Security (Elytron) SSL and click View . Click Certificate Auth... to open the Certificate Authority Account page. You can perform the following configurations for the selected alias by clicking the buttons with the labels: Create Create an account with a certificate authority. Deactivate Deactivate the selected certificate authority account. Update Update the selected account with the certificate authority. Get Metadata View the following information about the certificate authority account: Associated alias Certificate authority name Contact details Keystore name Certificate authority details Change Account Key Change the associated key with the certificate authority. 1.11.14. Keystore Manipulation Operations You can perform various keystore manipulation operations on an Elytron key-store resource using the management CLI and the management console. Keystore Manipulation Operations Using the Management CLI Using the management CLI, you can perform the following keystore manipulation operations: Generate a key pair. The generate-key-pair command generates a key pair and wraps the resulting public key in a self-signed X.509 certificate. The generated private key and self-signed certificate will be added to the keystore. Generate a certificate signing request. The generate-certificate-signing-request command generates a PKCS #10 certificate signing request using a PrivateKeyEntry from the keystore. The generated certificate signing request will be written to a file. Import a certificate or certificate chain. The import-certificate command imports a certificate or certificate chain from a file into an entry in the keystore. Export a certificate. The export-certificate command exports a certificate from an entry in the keystore to a file. Change an alias. The change-alias command moves an existing keystore entry to a new alias. Store changes made to keystores. The store command persists any changes that have been made to the file that backs the keystore. Keystore Manipulation Operations Using the Management Console To perform the operations using the management console: Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Runtime Security (Elytron) Stores and click View . Click Key Store to open the keystore definitions page. Click the required keystore name. You can perform the following operations for the selected keystore by clicking the buttons with the labels: Load Load or reload the keystore. Store Persist changes made to the file backing the keystore. Generate Key Pair Generate a key pair, wrap the public key in a self-signed X.509 certificate, and add the private key and the certificate to the keystore. Import Certificate Import a certificate chain to the keystore from a file. Obtain Obtain a signed certificate from a Certificate Authority and store it in the keystore. 1.11.14.1. Keystore Certificate Authority Operations You can perform the following operations on the keystore after you Configure a Let's Encrypt Account . Note Many of the commands in this section have an optional staging parameter that indicates whether the certificate authority's staging URL should be used. This value defaults to false , and is designed to assist in testing purposes. This parameter should never be enabled in a production environment. Keystore Certificate Authority Operations Using the Management CLI Using the management CLI, you can perform the following keystore certificate authority operations: Obtain a Signed Certificate. Once a certificate authority account has been defined for the keystore, you can use the obtain-certificate command to obtain a signed certificate and store it in the keystore. If an account with the certificate authority does not exist, then it will be automatically created. Revoke a signed certificate. The revoke-certificate command revokes a certificate that was issued by the certificate authority. Check if a signed certificate is due for renewal. The should-renew-certificate command determines if a certificate is due for renewal. The command returns true if the certificate expires in less than the given number of days, and false otherwise. The following command determines if the certificate expires in the 7 days. Keystore Certificate Authority Operations Using the Management Console To perform the operations using the management console: Access the management console. For more information, see the Management Console section in the JBoss EAP Configuration Guide . Navigate to Runtime Security (Elytron) Stores and click View . Click Key Store to open the keystore definitions page. Click Aliases to the required keystore name. Click the required alias name. You can perform the following operations for the selected alias by clicking on the buttons with the labels: Change Alias Change the alias for the entry. Export Certificate Export a certificate from a keystore entry to a file. Generate CSR Generate a certificate signing request. Remove Alias Remove the selected alias from the keystore. Details View the details of the certificate associated with the alias. Revoke Revoke the certificate associated with the alias. Verify Renew Determine if the associated certificate is due for renewal. 1.11.15. Configuring Evidence Decoder for X.509 Certificate with Subject Alternative Name Extension By default, the principal associated with an X.509 certificate in Elytron is the subject name in the certificate and the principal associated with an X.509 certificate chain is the subject name in the first certificate in a certificate chain. You can configure an X509-subject-alt-name-evidence-decoder to use subject alternative name extension in an X.509 certificate as the principal. The subject alternative name extension specification for an X.509 certificate and an X.509 certificate chain is defined in RFC 5280 . Prerequisites You know the expected format of a client certificate, or you have a client certificate available locally. Procedure Identify which subject alternative name extension to use. If you have the client certificate locally, the subject alternative name extension can be viewed using the keytool command: The subject alternative name extension is listed as: Create an x509-subject-alt-name-evidence-decoder to use the identified subject alternative name: To use the evidence decoder, reference it in a security-domain: Additional resources x509-subject-alternative-name-evidence-decoder Attributes 1.11.16. Configuring an Aggregate Evidence Decoder You can configure an aggregate evidence decoder to combine two or more evidence decoders. The evidence decoders are applied in the configured order until an evidence decoder returns a non-null principal or until there are no more evidence decoders left to try. Prerequisites The evidence decoders to be aggregated are configured. For information about configuring evidence decoder, see Configuring Evidence Decoder for X.509 Certificate with Subject Alternative Name Extension . Procedure Create an aggregate evidence decoder from existing the evidence decoders: To use the evidence decoder, reference it in a security domain: 1.11.17. Configuring X.500 Subject Evidence Decoder Configure x500-subject-evidence-decoder to extract the subject from the first certificate in a certificate chain. Procedure Create an x.500 subject evidence decoder: 1.11.18. Using Custom Evidence Decoder Implementation You can use a custom org.wildfly.security.auth.server.EvidenceDecoder implementation in Elytron by adding it as a module to JBoss EAP. Procedure Package the custom implementation class as a Java Archive (JAR). Add a module to JBoss EAP containing the JAR. For information about adding modules to JBoss EAP, see Create a Custom Module section in the Configuration Guide . Add the custom evidence decoder to Elytron:

Commands:
<interfaces> <interface name="management"> <inet-address value="USD{jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="USD{jboss.bind.address:127.0.0.1}"/> </interface> </interfaces>
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="USD{jboss.socket.binding.port-offset:0}"> <socket-binding name="management-http" interface="management" port="USD{jboss.management.http.port:9990}"/> <socket-binding name="management-https" interface="management" port="USD{jboss.management.https.port:9993}"/> <socket-binding name="ajp" port="USD{jboss.ajp.port:8009}"/> <socket-binding name="http" port="USD{jboss.http.port:8080}"/> <socket-binding name="https" port="USD{jboss.https.port:8443}"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group>
EAP_HOME /bin/jboss-cli.sh --file=EAP_HOME/docs/examples/enable-elytron.cli
/subsystem=elytron/security-domain=domainName:add(realms=[{realm=realmName,role-decoder=roleDecoderName}],default-realm=realmName,permission-mapper=permissionMapperName,role-mapper=roleMapperName,...)
/subsystem=elytron/type-of-realm=realmName:add(....)
/subsystem=elytron/ROLE-DECODER-TYPE=roleDeoderName:add(....)
/subsystem=elytron/source-address-role-decoder=decoder1:add(source-address="10.10.10.10", roles=["Administrator"])
/subsystem=elytron/security-domain=domainName:add(role-decoder=decoder1,default-realm=realmName,realms=[{realm=realmName}])
/subsystem=elytron/aggregate-role-decoder=aggregateDecoder:add(role-decoders=[decoder1, decoder2])
/subsystem=elytron/ROLE-MAPPER-TYPE=roleMapperName:add(...)
/subsystem=elytron/permission-set=PermissionSetName:add(permissions=[{class-name="...", module="...", target-name="...", action="..."}...])
/subsystem=elytron/simple-permission-mapper=PermissionMapperName:add(...)
/subsystem=elytron/authentication-configuration= AUTHENTICATION_CONFIGURATION_NAME :add(authentication-name= AUTHENTICATION_NAME , credential-reference={clear-text= PASSWORD })
/subsystem=elytron/authentication-context= AUTHENTICATION_CONTEXT_NAME :add()
/subsystem=elytron/authentication-context= AUTHENTICATION_CONTEXT_NAME :add(match-rules=[{authentication-configuration= AUTHENTICATION_CONFIGURATION_NAME , match-host=localhost}])
/subsystem=elytron/AUTH-FACTORY-TYPE=authFactoryName:add(....)
keytool -genkeypair -alias localhost -keyalg RSA -keysize 1024 -validity 365 -keystore keystore.jks -dname "CN=localhost" -keypass secret -storepass secret
/subsystem=elytron/key-store=newKeyStore:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-manager=newKeyManager:add(key-store= KEY_STORE ,credential-reference={clear-text=secret})
/subsystem=elytron/key-store=default-trust-store:add(type=JKS, relative-to=jboss.server.config.dir, path=application.truststore, credential-reference={clear-text=password})
/subsystem=elytron/trust-manager=default-trust-manager:add(key-store=TRUST-STORE-NAME)
/extension=org.wildfly.extension.elytron:add()
/subsystem=elytron:add reload
/subsystem=elytron:remove reload
/subsystem=security:remove
/subsystem=security:add
<security-realms> <security-realm name="ManagementRealm"> <authentication> <local default-user="USDlocal" skip-group-loading="true"/> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization map-groups-to-roles="false"> <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm> <security-realm name="ApplicationRealm"> <authentication> <local default-user="USDlocal" allowed-users="*" skip-group-loading="true"/> <properties path="application-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm> </security-realms>
/core-service=management/security-realm= <new_realm_name> :add()
[standalone@localhost:9990 /] /core-service=management:read-resource(recursive=true) { "outcome" => "success", "result" => { "access" => {...}, "ldap-connection" => undefined, "management-interface" => {"http-interface" => { "allowed-origins" => undefined, "console-enabled" => true, "http-authentication-factory" => "management-http-authentication", "http-upgrade" => { "enabled" => true, "sasl-authentication-factory" => "management-sasl-authentication" }, "http-upgrade-enabled" => true, "sasl-protocol" => "remote", "secure-socket-binding" => undefined, "security-realm" => undefined, "server-name" => undefined, "socket-binding" => "management-http", "ssl-context" => undefined }}, "security-realm" => {...}, "service" => undefined } }
/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
/subsystem=jmx/remoting-connector=jmx/:remove
[standalone@localhost:9990 /] /subsystem=elytron/sasl-authentication-factory=managenet-sasl-authentication:read-resource { "outcome" => "success", "result" => { "mechanism-configurations" => [ { "mechanism-name" => "JBOSS-LOCAL-USER", "realm-mapper" => "local" }, { "mechanism-name" => "DIGEST-MD5", "mechanism-realm-configurations" => [{"realm-name" => "ManagementRealm"}] } ], "sasl-server-factory" => "configured", "security-domain" => "ManagementDomain" } } [standalone@localhost:9990 /] /subsystem=elytron/sasl-authentication-factory=managenet-sasl-authentication:list-remove(name=mechanism-configurations, index=0) [standalone@localhost:9990 /] reload
/core-service=management/security-realm= <realm_name> /authentication=local:remove
security enable-ssl-management --interactive Please provide required pieces of information to enable SSL: Key-store file name (default management.keystore): keystore.jks Password (blank generated): secret What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: What is the name of your organization? [Unknown]: What is the name of your City or Locality? [Unknown]: What is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]? Validity (in days, blank default): 365 Alias (blank generated): localhost Enable SSL Mutual Authentication y/n (blank n): n SSL options: key store file: keystore.jks distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown password: secret validity: 365 alias: localhost Server keystore file keystore.jks, certificate file keystore.pem and keystore.csr file will be generated in server configuration directory. Do you confirm y/n :y
security disable-ssl-management
/subsystem=elytron/key-store=httpsKS:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-store=httpsKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost") /subsystem=elytron/key-store=httpsKS:store()
/subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,credential-reference={clear-text=secret}) /subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM,protocols=["TLSv1.2"])
/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=httpsSSC) /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
reload
keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret
keytool -exportcert -keystore client.keystore.jks -alias client -keypass secret -storepass secret -file /path/to/client.cer
security enable-ssl-management --interactive Please provide required pieces of information to enable SSL: Key-store file name (default management.keystore): server.keystore.jks Password (blank generated): secret What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: What is the name of your organization? [Unknown]: What is the name of your City or Locality? [Unknown]: What is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]? Validity (in days, blank default): 365 Alias (blank generated): localhost Enable SSL Mutual Authentication y/n (blank n): y Client certificate (path to pem file): /path/to/client.cer Validate certificate y/n (blank y): n Trust-store file name (management.truststore): server.truststore.jks Password (blank generated): secret SSL options: key store file: server.keystore.jks distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown password: secret validity: 365 alias: localhost client certificate: /path/to/client.cer trust store file: server.trustore.jks trust store password: secret Server keystore file server.keystore.jks, certificate file server.pem and server.csr file will be generated in server configuration directory. Server truststore file server.trustore.jks will be generated in server configuration directory. Do you confirm y/n: y
security disable-ssl-management
/subsystem=elytron/key-store=twoWayKS:add(path=server.keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS) /subsystem=elytron/key-store=twoWayKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost") /subsystem=elytron/key-store=twoWayKS:store()
/subsystem=elytron/key-store=twoWayKS:export-certificate(alias=localhost,path=/path/to/server.cer,pem=true)
/subsystem=elytron/key-store=twoWayTS:add(path=server.truststore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS) /subsystem=elytron/key-store=twoWayTS:import-certificate(alias=client,path=/path/to/client.cer,credential-reference={clear-text=secret},trust-cacerts=true,validate=false) /subsystem=elytron/key-store=twoWayTS:store()
/subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS,credential-reference={clear-text=secret}) /subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS) /subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM,protocols=["TLSv1.2"],trust-manager=twoWayTM,want-client-auth=true,need-client-auth=true)
/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=twoWaySSC) /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
reload
security enable-sasl-management Server reloaded. Command success. Authentication configured for management http-interface sasl authentication-factory=management-sasl-authentication security-domain=ManagementDomain
security disable-sasl-management
security disable-sasl-management --mechanism= MECHANISM
security reorder-sasl-management --mechanisms-order= MECHANISM1 , MECHANISM2 ,
security enable-http-auth-management Server reloaded. Command success. Authentication configured for management http-interface http authentication-factory=management-http-authentication security-domain=ManagementDomain
security disable-http-auth-management
security disable-http-auth-management --mechanism= MECHANISM
keytool -genkeypair -alias appserver -storetype jks -keyalg RSA -keysize 2048 -keypass password1 -keystore EAP_HOME /standalone/configuration/identity.jks -storepass password1 -dname "CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US" -validity 730 -v
/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https) /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)
/host=master/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9993) /host=master/core-service=management/management-interface=http-interface:undefine-attribute(name=port)
/socket-binding-group=standard-sockets/socket-binding=management-https:read-resource(recursive=true) { "outcome" => "success", "result" => { "client-mappings" => undefined, "fixed-port" => false, "interface" => "management", "multicast-address" => undefined, "multicast-port" => undefined, "name" => "management-https", "port" => expression "USD{jboss.management.https.port:9993}" } }
touch EAP_HOME /standalone/configuration/https-mgmt-users.properties
/core-service=management/security-realm=ManagementRealmHTTPS:add /core-service=management/security-realm=ManagementRealmHTTPS/authentication=properties:add(path=https-mgmt-users.properties,relative-to=jboss.server.config.dir)
EAP_HOME /bin/add-user.sh -up EAP_HOME /standalone/configuration/https-mgmt-users.properties -r ManagementRealmHTTPS Enter the details of the new user to add. Using realm 'ManagementRealmHTTPS' as specified on the command line. Username : httpUser Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file. - The password must not be one of the following restricted values {root, admin, administrator} - The password must contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s) - The password must be different from the username Password : Re-enter Password : About to add user 'httpUser' for realm 'ManagementRealmHTTPS' Is this correct yes/no? yes .. Added user 'httpUser' to file 'EAP_HOME/configuration/https-mgmt-users.properties' Is this new user going to be used for one AS process to connect to another AS process? e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls. yes/no? no
/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=ManagementRealmHTTPS)
/core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:add(keystore-path=identity.jks,keystore-relative-to=jboss.server.config.dir,keystore-password=password1, alias=appserver)
/core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:write-attribute(name=keystore-password,value=newpassword)
reload
13:50:54,160 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0061: Http management interface listening on https://127.0.0.1:9993/management 13:50:54,162 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0052: Admin console listening on https://127.0.0.1:9993
<jboss-cli xmlns="urn:jboss:cli:2.0"> <default-protocol use-legacy-override="true">https-remoting</default-protocol> <!-- The default controller to connect to when 'connect' command is executed w/o arguments --> <default-controller> <protocol>https-remoting</protocol> <host>localhost</host> <port>9993</port> </default-controller>
./jboss-cli.sh -c Unable to connect due to unrecognised server certificate Subject - CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US Issuer - CN=appserver, OU=Sales, O=Systems Inc, L=Raleigh, ST=NC, C=US Valid From - Tue Jun 28 13:38:48 CDT 2016 Valid To - Thu Jun 28 13:38:48 CDT 2018 MD5 : 76:f4:81:8b:7e:c3:be:6d:ee:63:c1:7a:b7:b8:f0:fb SHA1 : ea:e3:f1:eb:53:90:69:d0:c9:69:4a:5a:a3:20:8f:76:c1:e6:66:b6 Accept certificate? [N]o, [T]emporarily, [P]ermenantly : p Authenticating against security realm: ManagementRealmHTTPS Username: httpUser Password: [standalone@localhost:9993 /]
keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secret keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret
keytool -exportcert -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer keytool -exportcert -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer
keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer
/core-service=management/security-realm=CertificateRealm:add() /core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks, keystore-password=secret,alias=HOST1_alias) /core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)
/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)
<ssl> <alias>HOST2_alias</alias> <key-store>/path/to/HOST2.keystore.jks</key-store> <key-store-password>secret</key-store-password> <trust-store>/path/to/HOST2.truststore.jks</trust-store> <trust-store-password>secret</trust-store-password> <modify-trust-store>true</modify-trust-store> </ssl>
<ssl> <vault> <vault-option name="KEYSTORE_URL" value="path-to/vault/vault.keystore"/> <vault-option name="KEYSTORE_PASSWORD" value="MASK-5WNXs8oEbrs"/> <vault-option name="KEYSTORE_ALIAS" value="vault"/> <vault-option name="SALT" value="12345678"/> <vault-option name="ITERATION_COUNT" value="50"/> <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/> </vault> <alias>HOST2_alias</alias> <key-store>/path/to/HOST2.keystore.jks</key-store> <key-store-password>VAULT::VB::cli_pass::1</key-store-password> <key-password>VAULT::VB::cli_pass::1</key-password> <trust-store>/path/to/HOST2.truststore.jks</trust-store> <trust-store-password>VAULT::VB::cli_pass::1</trust-store-password> <modify-trust-store>true</modify-trust-store> </ssl>
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enabled-cipher-suites,value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA")
/subsystem=elytron:undefine-attribute(name=final-providers) reload
/subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers)
/subsystem=elytron/server-ssl-context=serverSSC:write-attribute(name=providers,value=openssl) reload
/subsystem=elytron/server-ssl-context=serverSSC:write-attribute(name=protocols,value=[TLSv1.3])
/subsystem=elytron/server-ssl-context=serverSSC:write-attribute(name=cipher-suite-names,value=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256)
reload
curl -v https:// <ip_address> : <ssl_port>
SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=localhost * start date: Oct 6 14:58:16 2020 GMT * expire date: Nov 5 15:58:16 2020 GMT * issuer: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=localhost * SSL certificate verify result: self signed certificate (18), continuing anyway.
mkdir -p /usr/share/jboss-as/nssdb chown jboss /usr/share/jboss-as/nssdb modutil -create -dbdir /usr/share/jboss-as/nssdb
name = nss-fips nssLibraryDirectory=/usr/lib64 nssSecmodDirectory=/usr/share/jboss-as/nssdb nssDbMode = readOnly nssModule = fips
security.provider.1=sun.security.pkcs11.SunPKCS11 /usr/share/jboss-as/nss_pkcsll_fips.cfg
security.provider.5=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-nss-fips
modutil -fips true -dbdir /usr/share/jboss-as/nssdb
modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /usr/share/jboss-as/nssdb
certutil -S -k rsa -n undertow -t "u,u,u" -x -s "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /usr/share/jboss-as/nssdb
keytool -list -storetype pkcs11
10:16:13,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.server.controller.management.security_realm.ApplicationRealm.key-manager: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.ApplicationRealm.key-manager: WFLYDM0018: Unable to start service at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:85) at org.jboss.msc.service.ServiceControllerImplUSDStartTask.startService(ServiceControllerImpl.java:1963) at org.jboss.msc.service.ServiceControllerImplUSDStartTask.run(ServiceControllerImpl.java:1896) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutorUSDWorker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.security.KeyStoreException: FIPS mode: KeyStore must be from provider SunPKCS11-nss-fips at sun.security.ssl.KeyManagerFactoryImplUSDSunX509.engineInit(KeyManagerFactoryImpl.java:67) at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256) at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:130) at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:83) ... 5 more
JAVA_OPTS="USDJAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11" JAVA_OPTS="USDJAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=P@ssword123"
<configuration> <authentication-client xmlns="urn:elytron:client:1.2"> <key-stores> <key-store name="truststore" type="PKCS11"> <key-store-clear-password password="P@ssword123"/> </key-store> </key-stores> <ssl-contexts> <ssl-context name="client-cli-context"> <trust-store key-store-name="truststore"/> <cipher-suite selector="USD{cipher.suite.filter}"/> <protocol names="TLSv1.1"/> </ssl-context> </ssl-contexts> <ssl-context-rules> <rule use-ssl-context="client-cli-context"/> </ssl-context-rules> </authentication-client> </configuration>
jboss-cli.sh -Dwildfly.config.url=cli-wildfly-config.xml
/subsystem=elytron/key-store=fipsKS:add(type=PKCS11,provider-name="SunPKCS11-nss-fips",credential-reference={clear-text="P@ssword123"}) /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS,algorithm="SunX509",provider-name=SunPKCS11-nss-fips,credential-reference={clear-text="P@ssword123"}) /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM,protocols=["TLSv1.1"])
batch /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm) /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=fipsSSC) run-batch reload
batch /core-service=management/security-realm=HTTPSRealm:add /core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="strongP@ssword1") /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=HTTPSRealm, enabled-protocols="TLSv1.1") run-batch
SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enabled-cipher-suites,value="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,TLS_ECDH_anon_WITH_AES_256_CBC_SHA")
/core-service=management/security-realm=HTTPSRealm/server-identity=ssl:write-attribute(name=enabled-cipher-suites, value=[SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA])
keytool -genkeypair -alias ALIAS -keyalg RSA -keysize 2048 -keypass PASSWORD -keystore KEYSTORE -storetype BCFKS -storepass STORE_PASSWORD
<configuration> <authentication-client xmlns="urn:elytron:client:1.2"> <key-stores> <key-store name="truststore" type="BCFKS"> <file name="USD{truststore.location}" /> <key-store-clear-password password="USD{password}" /> </key-store> <key-store name="keystore" type="BCFKS"> <file name="USD{keystore.location}" /> <key-store-clear-password password="USD{password}" /> </key-store> </key-stores> <ssl-contexts> <ssl-context name="client-cli-context"> <key-store-ssl-certificate algorithm="PKIX" key-store-name="keystore"> <key-store-clear-password password="USD{password"} /> </key-store-ssl-certificate> <trust-store key-store-name="truststore"/> <trust-manager algorithm="PKIX"> </trust-manager> <cipher-suite selector="TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CCM,TLS_RSA_WITH_AES_128_CCM"/> <protocol names="TLSv1.2"/> </ssl-context> </ssl-contexts> <ssl-context-rules> <rule use-ssl-context="client-cli-context"/> </ssl-context-rules> </authentication-client> </configuration>
jboss-cli.sh -Dwildfly.config.url=cli-wildfly-config.xml
/subsystem=elytron/key-store=fipsKS:add(path= KEYSTORE ,relative-to=jboss.server.config.dir,credential-reference={clear-text= STORE_PASSWORD },type="BCFKS") /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS,algorithm="PKIX",credential-reference={clear-text= PASSWORD }) /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM,protocols=["TLSv1.2"],cipher-suite-filter="TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CCM,TLS_RSA_WITH_AES_128_CCM")
batch /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm) /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=fipsSSC) run-batch reload
keytool -list -storetype JCEKS -keystore mystore.jck -storepass mystorepass -providerClass com.ibm.crypto.fips.provider.IBMJCEFIPS
<configuration> <authentication-client xmlns="urn:elytron:client:1.2"> <key-stores> <key-store name="truststore" type="JKS"> <file name="/path/to/truststore"/> <key-store-clear-password password="P@ssword123"/> </key-store> </key-stores> <ssl-contexts> <ssl-context name="client-cli-context"> <trust-store key-store-name="truststore"/> <cipher-suite selector="USD{cipher.suite.filter}"/> <protocol names="TLSv1"/> </ssl-context> </ssl-contexts> <ssl-context-rules> <rule use-ssl-context="client-cli-context"/> </ssl-context-rules> </authentication-client> </configuration>
04:22:45,685 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using MessageDigest SHA from provider IBMJCEFIPS version 1.7 04:22:45,689 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyPairGenerator from provider from init IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using KeyFactory DiffieHellman from provider IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using KeyAgreement DiffieHellman from provider IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyAgreement from provider IBMJCEFIPS version 1.7 04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyAgreement from provider from initIBMJCEFIPS version 1.7
<security-realm name="HTTPSRealm"> <server-identities> <ssl> <engine enabled-protocols="TLSv1.1"/> <keystore provider="PKCS11" keystore-password="strongP@ssword1"/> </ssl> </server-identities> <authentication> <local default-user="\USDlocal"/> <properties path="https-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> </security-realm>
<security-realm name="HTTPSRealm"> <authentication> <truststore provider="PKCS11" keystore-password="strongP@ssword1"/> </authentication> </security-realm>
<management-interfaces> <http-interface security-realm="HTTPSRealm"> <http-upgrade enabled="true"/> <socket interface="management" port="USD{jboss.management.http.port:9990}"/> </http-interface> </management-interfaces>
<domain-controller> <remote security-realm="HTTPSRealm"> <discovery-options> <static-discovery name="primary" protocol="USD{jboss.domain.master.protocol:remote}" host="USD{jboss.domain.master.address}" port="USD{jboss.domain.master.port:9990}"/> </discovery-options> </remote> </domain-controller>
<server name="my-server" group="my-server-group"> <ssl ssl-protocol="TLS" trust-manager-algorithm="PKIX" truststore-type="PKCS11" truststore-password="strongP@ssword1"/> </server>
/host=master/core-service=management/security-realm=HTTPSRealm/authentication=truststore:add(keystore-provider="PKCS11",keystore-password="strongP@ssword1") reload --host=master
/host=host1/core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="strongP@ssword1",enabled-protocols=["TLSv1.1"]) reload --host=host1
RHSSO_HOME /bin/standalone.sh -Djboss.socket.binding.port-offset=100
EAP_HOME /bin/jboss-cli.sh --file=adapter-elytron-install-offline.cli
Create a realm for both JBoss EAP console and mgmt interface /subsystem=keycloak/realm=wildfly-infra:add(auth-server-url=http://localhost:8180/auth,realm-public-key= REALM_PUBLIC_KEY ) Create a secure-deployment in order to protect mgmt interface /subsystem=keycloak/secure-deployment=wildfly-management:add(realm=wildfly-infra,resource=wildfly-management,principal-attribute=preferred_username,bearer-only=true,ssl-required=EXTERNAL) Protect HTTP mgmt interface with Keycloak adapter /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm) /subsystem=elytron/http-authentication-factory=keycloak-mgmt-http-authentication:add(security-domain=KeycloakDomain,http-server-mechanism-factory=wildfly-management,mechanism-configurations=[{mechanism-name=KEYCLOAK,mechanism-realm-configurations=[{realm-name=KeycloakOIDCRealm,realm-mapper=keycloak-oidc-realm-mapper}]}]) /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory,value=keycloak-mgmt-http-authentication) /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade, value={enabled=true, sasl-authentication-factory=management-sasl-authentication}) Enable RBAC where roles are obtained from the identity /core-service=management/access=authorization:write-attribute(name=provider,value=rbac) /core-service=management/access=authorization:write-attribute(name=use-identity-roles,value=true) Create a secure-server in order to publish the JBoss EAP console configuration via mgmt interface /subsystem=keycloak/secure-server=wildfly-console:add(realm=wildfly-infra,resource=wildfly-console,public-client=true) reload reload
EAP_HOME /bin/standalone.sh
EAP_HOME /bin/jboss-cli.sh --connect --file=protect-eap-mgmt-services.cli
/subsystem=elytron/file-audit-log= <audit_log_name> :add(path=" <path_to_log_file> ", relative-to=" <base_for_path_to_log_file> ", format= <format_type> , synchronized= <whether_to_log_immediately> )
/subsystem=elytron/security-domain= <security_domain_name> :write-attribute(name=security-event-listener , value= <audit_log_name> )
/subsystem=elytron/periodic-rotating-file-audit-log= <periodic_audit_log_name> :add(path=" <periodic_audit_log_filename> ", relative-to=" <path_to_audit_log_directory> ", format= <record_format> , synchronized= <whether_to_log_immediately> ,suffix=" <suffix_in_DateTimeFormatter_format> ")
/subsystem=elytron/security-domain= <security_domain_name> :write-attribute(name=security-event-listener, value= <periodic_audit_log_name> )
/subsystem=elytron/size-rotating-file-audit-log= <audit_log_name> :add(path="<path_to_log_file>",relative-to="<base_for_path_to_log_file>",format= <record_format> ,synchronized= <whether_to_log_immediately> ,rotate-size=" <max_file_size_before_rotation> ",max-backup-index= <max_number_of_backup_files> )
/subsystem=elytron/security-domain= <domain_size_logger> :write-attribute(name=security-event-listener, value= <audit_log_name> )
"Elytron audit logging enabled with RFC format: <format>"
/subsystem=elytron/syslog-audit-log= <syslog_audit_log_name> :add(host-name= <record_host_name> , port= <syslog_server_port_number> , server-address= <syslog_server_address> , format= <record_format> , transport= <transport_layer_protocol> )
/subsystem=elytron/syslog-audit-log= <syslog_audit_log_name> :add(transport=SSL_TCP,server-address= <syslog_server_address> ,port= <syslog_server_port_number> ,host-name= <record_host_name> ,ssl-context= <client_ssl_context> )
/subsystem=elytron/security-domain= <security_domain_name> :write-attribute(name=security-event-listener, value= <syslog_audit_log_name> )
public class MySecurityEventListener implements Consumer<SecurityEvent> { public void accept(SecurityEvent securityEvent) { if (securityEvent instanceof SecurityAuthenticationSuccessfulEvent) { System.err.printf("Authenticated user \"%s\"\n", securityEvent.getSecurityIdentity().getPrincipal()); } else if (securityEvent instanceof SecurityAuthenticationFailedEvent) { System.err.printf("Failed authentication as user \"%s\"\n", ((SecurityAuthenticationFailedEvent)securityEvent).getPrincipal()); } } }
/subsystem=elytron/custom-security-event-listener= <listener_name> :add(module= <module_name> , class-name= <class_name> )
/subsystem=elytron/security-domain= <domain_name> :write-attribute(name=security-event-listener, value= <listener_name> )
reload
15:26:09,031 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-7) WFLYDM0111: Keystore /path/to/jboss/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost 15:26:10,076 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0113: Generated self signed certificate at /path/to/jboss/configuration/application.keystore. Please note that self signed certificates are not secure, and should only be used for testing purposes. Do not use this self signed certificate in production. SHA-1 fingerprint of the generated key is 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33 SHA-256 fingerprint of the generated key is 00:11:22:33:44:55:66:77:88:99:00:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee
<security-realm name="ApplicationRealm"> <server-identities> <ssl> <keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/> </ssl> </server-identities> </security-realm>
<subsystem xmlns="urn:jboss:domain:undertow:10.0"> <server name="default-server"> <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/> <host name="default-host" alias="localhost">
security enable-ssl-http-server --interactive Please provide required pieces of information to enable SSL: Key-store file name (default default-server.keystore): keystore.jks Password (blank generated): secret What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: What is the name of your organization? [Unknown]: What is the name of your City or Locality? [Unknown]: What is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]? Validity (in days, blank default): 365 Alias (blank generated): localhost Enable SSL Mutual Authentication y/n (blank n): n SSL options: key store file: keystore.jks distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown password: secret validity: 365 alias: localhost Server keystore file keystore.jks, certificate file keystore.pem and keystore.csr file will be generated in server configuration directory. Do you confirm y/n: y
/subsystem=elytron/key-store=httpsKS:add(path=/path/to/keystore.jks, credential-reference={clear-text=secret}, type=JKS)
/subsystem=elytron/key-store=httpsKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost") /subsystem=elytron/key-store=httpsKS:store()
/subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,credential-reference={clear-text=secret})
/subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM, protocols=["TLSv1.2"])
/subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm) { "outcome" => "success", "result" => "ApplicationRealm" }
batch /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm) /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=httpsSSC) run-batch
reload
security disable-ssl-http-server
keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret
keytool -exportcert -keystore client.keystore.jks -alias client -keypass secret -storepass secret -file /path/to/client.cer
security enable-ssl-http-server --interactive Please provide required pieces of information to enable SSL: Key-store file name (default default-server.keystore): server.keystore.jks Password (blank generated): secret What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: What is the name of your organization? [Unknown]: What is the name of your City or Locality? [Unknown]: What is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]? Validity (in days, blank default): 365 Alias (blank generated): localhost Enable SSL Mutual Authentication y/n (blank n): y Client certificate (path to pem file): /path/to/client.cer Validate certificate y/n (blank y): n Trust-store file name (management.truststore): server.truststore.jks Password (blank generated): secret SSL options: key store file: server.keystore.jks distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown password: secret validity: 365 alias: localhost client certificate: /path/to/client.cer trust store file: server.trustore.jks trust store password: secret Server keystore file server.keystore.jks, certificate file server.pem and server.csr file will be generated in server configuration directory. Server truststore file server.trustore.jks will be generated in server configuration directory. Do you confirm y/n: y
/subsystem=elytron/key-store=twoWayKS:add(path= /PATH/TO /server.keystore.jks,credential-reference={clear-text=secret},type=JKS) /subsystem=elytron/key-store=twoWayKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost") /subsystem=elytron/key-store=twoWayKS:store()
/subsystem=elytron/key-store=twoWayKS:add(path=server.keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-store=twoWayKS:export-certificate(alias=localhost,path=/path/to/server.cer,pem=true)
/subsystem=elytron/key-store=twoWayTS:add(path=/path/to/server.truststore.jks,credential-reference={clear-text=secret},type=JKS) /subsystem=elytron/key-store=twoWayTS:import-certificate(alias=client,path=/path/to/client.cer,credential-reference={clear-text=secret},trust-cacerts=true,validate=false) /subsystem=elytron/key-store=twoWayTS:store()
/subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS, credential-reference={clear-text=secret})
/subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS)
/subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM, protocols=["TLSv1.2"], trust-manager=twoWayTM, need-client-auth=true)
/subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm) { "outcome" => "success", "result" => "ApplicationRealm" }
batch /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm) /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=twoWaySSC) run-batch
reload
keytool -importcert -keystore client.truststore.jks -storepass secret -alias localhost -trustcacerts -file /path/to/server.cer
security disable-ssl-http-server
/subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=certificate-revocation-list,value={})
/subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=certificate-revocation-list.path, value=intermediate.crl.pem)
/subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=ocsp.prefer-crls,value="true")
/subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=ocsp,value={})
/subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=ocsp.responder,value="http://example.com/ocsp-responder")
batch /core-service=management/security-realm=HTTPSRealm:add /core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-path=identity.jks, keystore-relative-to=jboss.server.config.dir, keystore-password=password1, alias=appserver) /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=security-realm, value=HTTPSRealm) run-batch
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=security-realm, value=CertificateRealm) /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=verify-client, value=REQUIRED)
security enable-http-auth-http-server --security-domain= SECURITY_DOMAIN Server reloaded. Command success. Authentication configured for security domain SECURITY_DOMAIN http authentication-factory=application-http-authentication security-domain= SECURITY_DOMAIN
security disable-http-auth-http-server --security-domain= SECURITY_DOMAIN
security disable-http-auth-http-server --mechanism= MECHANISM --security-domain= SECURITY_DOMAIN
/subsystem=elytron/configurable-sasl-server-factory=mySASLServerFactory:add(sasl-server-factory=elytron) /subsystem=elytron/sasl-authentication-factory=mySASLAuthFactory:add(sasl-server-factory=mySASLServerFactory,security-domain=ApplicationDomain,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=ApplicationRealm}]}])
/subsystem=elytron/authentication-configuration=myAuthConfig:write-attribute(name=sasl-mechanism-selector,value="DIGEST-MD5")
<configuration> <authentication-client xmlns="urn:elytron:client:1.2"> <authentication-rules> <rule use-configuration="default" /> </authentication-rules> <authentication-configurations> <configuration name="default"> <sasl-mechanism-selector selector="#ALL" /> </configuration> </authentication-configurations> </authentication-client> </configuration>
/subsystem=elytron/configurable-sasl-server-factory=mySASLServerFactory:map-put(name=properties,key=com.sun.security.sasl.digest.utf8,value=false)
/subsystem=elytron/authentication-configuration=myAuthConfig:map-put(name=mechanism-properties,key=wildfly.sasl.local-user.quiet-auth,value=true)
<authentication-configurations> <configuration name="default"> <sasl-mechanism-selector selector="#ALL" /> <set-mechanism-properties> <property key="wildfly.sasl.local-user.quiet-auth" value="true" /> </set-mechanism-properties> </configuration> </authentication-configurations>
/subsystem=elytron/client-ssl-context=modcluster-client-ssl-context:add(trust-manager=default-trust-manager)
/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=ssl-context, value=modcluster-client-ssl-context)
/subsystem=undertow/configuration=filter/mod-cluster=modcluster:write-attribute(name=ssl-context,value=modcluster-client-ssl-context)
reload
/subsystem=elytron/key-store=twoWayKS:add(path=/path/to/client.keystore.jks, credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS, algorithm="SunX509", credential-reference={clear-text=secret})
/subsystem=elytron/client-ssl-context=modcluster-client-ssl-context:add(trust-manager=default-trust-manager, key-manager=twoWayKM)
/subsystem=elytron/client-ssl-context=modcluster-client-ssl-context:write-attribute(name=key-manager, value=twoWayKM)
reload
/subsystem=remoting/connector= CONNECTOR_NAME :add(sasl-authentication-factory= SASL_FACTORY_NAME ,socket-binding= SOCKET_BINDING_NAME )
/subsystem=remoting/connector= CONNECTOR_NAME :add(sasl-authentication-factory= SASL_FACTORY_NAME ,socket-binding= SOCKET_BINDING_NAME ,ssl-context= SSL_CONTEXT_NAME )
/socket-binding-group=standard-sockets/socket-binding=oneWayBinding:add(port=11199)
/subsystem=remoting/connector=oneWayConnector:add(sasl-authentication-factory= SASL_FACTORY ,socket-binding=oneWayBinding,ssl-context= SSL_CONTEXT )
/socket-binding-group=standard-sockets/socket-binding=twoWayBinding:add(port=11199)
/subsystem=remoting/connector=twoWayConnector:add(sasl-authentication-factory= SASL_FACTORY ,socket-binding=twoWayBinding,ssl-context= SSL_CONTEXT )
/subsystem=remoting/http-connector= HTTP_CONNECTOR_NAME :add(connector-ref= CONNECTOR_NAME ,sasl-authentication-factory= SASL_FACTORY_NAME )
/subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm) { "outcome" => "success", "result" => "ApplicationRealm" }
batch /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm) /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value= SERVER_SSL_CONTEXT ) run-batch
/subsystem=remoting/http-connector=ssl-http-connector:add(connector-ref=https,sasl-authentication-factory= SASL_FACTORY )
reload
/subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm) { "outcome" => "success", "result" => "ApplicationRealm" }
batch /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm) /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value= SERVER_SSL_CONTEXT ) run-batch
/subsystem=remoting/http-connector=ssl-http-connector:add(connector-ref=https,sasl-authentication-factory= SASL_FACTORY )
reload
/subsystem=remoting/remote-outbound-connection= OUTBOUND_CONNECTION_NAME :add(authentication-context= AUTHENTICATION_CONTEXT_NAME , outbound-socket-binding-ref= OUTBOUND_SOCKET_BINDING_NAME )
/subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389", principal="uid=admin,ou=system", credential-reference={clear-text="secret"})
/subsystem=elytron/ldap-key-store=ldapKS:add(dir-context=exampleDC, search-path="ou=Keystores,dc=wildfly,dc=org")
/subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
/subsystem=elytron/filtering-key-store=filterKS:add(key-store=myKS, alias-filter="alias1,alias3")
/subsystem=elytron/key-store=httpsKS:load
/subsystem=elytron/key-store=httpsKS:load()
/subsystem=elytron/key-manager=httpsKM:init()
/subsystem=elytron/key-store=httpsKS:load()
/subsystem=elytron/trust-manager=httpsTM:init()
/subsystem=elytron/key-store=httpsKS/:read-alias(alias=localhost)
/subsystem=elytron/client-ssl-context=exampleCSC:add(key-manager=clientKM, trust-manager=clientTM, protocols=["TLSv1.2"])
/subsystem=elytron/server-ssl-context=newServerSSLContext:add(key-manager= KEY_MANAGER ,protocols=["TLSv1.2"])
/subsystem=elytron/server-ssl-sni-context= SERVER_SSL_SNI_CONTEXT :add(default-ssl-context= DEFAULT_SERVER_SSL_CONTEXT ,host-context-map={ HOSTNAME = SERVER_SSL_CONTEXT ,...})
/subsystem=elytron/server-ssl-sni-context=exampleSNIContext:add(default-ssl-context=serverSSL,host-context-map={www\\.example\\.com=exampleSSL})
module add --name= MODULE_NAME --resources= FACTORY_JAR --dependencies=javax.api, DEPENDENCY_LIST
/subsystem=elytron/provider-loader= LOADER_NAME :add(class-names=[ CLASS_NAME ],module= MODULE_NAME )
/subsystem=elytron/provider-loader= LOADER_NAME :add(module= MODULE_NAME )
/subsystem=elytron/ COMPONENT_NAME = NEW_COMPONENT :add(providers= LOADER_NAME ,...)
/subsystem=elytron/trust-manager=newTrustManager:add(algorithm=MyX509,providers=customProvider,key-store=sampleKeystore)
void initialize(final Map<String, String> configuration);
/subsystem=elytron/ COMPONENT_NAME = NEW_COMPONENT :add(class-name= CLASS_NAME ,module= MODULE_NAME ,configuration={myAttribute="myValue"}
import org.kohsuke.MetaInfServices; import javax.net.ssl.TrustManagerFactory; import java.security.Provider; import java.util.Collections; import java.util.List; import java.util.Map; @MetaInfServices(Provider.class) public class CustomProvider extends Provider { public CustomProvider() { super("CustomProvider", 1.0, "Demo provider"); System.out.println("CustomProvider initialization."); final List<String> emptyList = Collections.emptyList(); final Map<String, String> emptyMap = Collections.emptyMap(); putService(new Service(this, TrustManagerFactory.class.getSimpleName(),"CustomAlgorithm", CustomTrustManagerFactorySpi.class.getName(), emptyList, emptyMap)); } }
import javax.net.ssl.SSLEngine; import javax.net.ssl.X509ExtendedTrustManager; import java.net.Socket; import java.security.cert.CertificateException; import java.security.cert.X509Certificate; public class CustomTrustManager extends X509ExtendedTrustManager { public void checkClientTrusted(X509Certificate[] x509Certificates, String s, Socket socket) throws CertificateException { // Insert your code here } public void checkServerTrusted(X509Certificate[] x509Certificates, String s, Socket socket) throws CertificateException { // Insert your code here } public void checkClientTrusted(X509Certificate[] x509Certificates, String s, SSLEngine sslEngine) throws CertificateException { // Insert your code here } public void checkServerTrusted(X509Certificate[] x509Certificates, String s, SSLEngine sslEngine) throws CertificateException { // Insert your code here } public void checkClientTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException { // Insert your code here } public void checkServerTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException { // Insert your code here } public X509Certificate[] getAcceptedIssuers() { // Insert your code here } }
import javax.net.ssl.ManagerFactoryParameters; import javax.net.ssl.TrustManager; import javax.net.ssl.TrustManagerFactorySpi; import java.security.InvalidAlgorithmParameterException; import java.security.KeyStore; import java.security.KeyStoreException; public class CustomTrustManagerFactorySpi extends TrustManagerFactorySpi { protected void engineInit(KeyStore keyStore) throws KeyStoreException { // Insert your code here } protected void engineInit(ManagerFactoryParameters managerFactoryParameters) throws InvalidAlgorithmParameterException { // Insert your code here } protected CustomTrustManager[] engineGetTrustManagers() { // Insert your code here } }
javax.net.ssl.SSLContext.getDefault();
/subsystem=elytron:write-attribute(name=default-ssl-context, value=client-context)
:reload
/subsystem=elytron:undefine-attribute(name=default-ssl-context) { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } }
/subsystem=elytron/trust-manager= TRUST_MANAGER :write-attribute(name=certificate-revocation-list,value={path= /path/to/CRL_FILE .crl.pem}
/subsystem=elytron/trust-manager= TRUST_MANAGER :reload-certificate-revocation-list
/subsystem=elytron/certificate-authority-account= CERTIFICATE_ACCOUNT :add(key-store= KEYSTORE ,alias= ALIAS ,contact-urls=[mailto: EMAIL_ADDRESS ])
/subsystem=elytron/certificate-authority-account= CERTIFICATE_ACCOUNT :create-account(agree-to-terms-of-service=true)
/subsystem=elytron/certificate-authority-account= CERTIFICATE_ACCOUNT :update-account(agree-to-terms-of-service=true)
/subsystem=elytron/certificate-authority-account= CERTIFICATE_ACCOUNT :change-account-key()
/subsystem=elytron/certificate-authority-account= CERTIFICATE_ACCOUNT :deactivate-account()
/subsystem=elytron/certificate-authority-account= CERTIFICATE_ACCOUNT :get-metadata()
/subsystem=elytron/key-store=httpsKS:add(path=/path/to/server.keystore.jks,credential-reference={clear-text=secret},type=JKS) /subsystem=elytron/key-store=httpsKS:generate-key-pair(alias=example,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=www.example.com")
/subsystem=elytron/key-store=httpsKS:generate-certificate-signing-request(alias=example,path=server.csr,relative-to=jboss.server.config.dir,distinguished-name="CN=www.example.com",extensions=[{critical=false,name=KeyUsage,value=digitalSignature}],credential-reference={clear-text=secret})
/subsystem=elytron/key-store=httpsKS:import-certificate(alias=example,path=/path/to/certificate_or_chain/file,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},trust-cacerts=true)
/subsystem=elytron/key-store=httpsKS:export-certificate(alias=example,path=serverCert.cer,relative-to=jboss.server.config.dir,pem=true)
/subsystem=elytron/key-store=httpsKS:change-alias(alias=example,new-alias=newExample,credential-reference={clear-text=secret})
/subsystem=elytron/key-store=httpsKS:store()
/subsystem=elytron/key-store= KEYSTORE :obtain-certificate(alias= ALIAS ,domain-names=[ DOMAIN_NAME ],certificate-authority-account= CERTIFICATE_ACCOUNT ,agree-to-terms-of-service=true,algorithm=RSA,credential-reference={clear-text=secret})
/subsystem=elytron/key-store= KEYSTORE :revoke-certificate(alias= ALIAS ,certificate-authority-account= CERTIFICATE_ACCOUNT )
/subsystem=elytron/key-store= KEYSTORE :should-renew-certificate(alias= ALIAS ,expiration=7)
keytool -printcert -file /path/to/certificate/certificate.cert
SubjectAlternativeName [ DNS:one.example.org IP Address:127.0.0.1 ]
/subsystem=elytron/x509-subject-alt-name-evidence-decoder=exampleDnsDecoder:add(alt-name-type=__EXTENSION_TO_USE__)
/subsystem=elytron/security-domain=__Security_Domain_Name__:write-attribute(name="evidence-decoder",value="exampleDnsDecoder")
/subsystem=elytron/aggregate-evidence-decoder=aggregateDecoder:add(evidence-decoders=[__DECODER_1__,__DECODER_2__,...,__DECODER_N__])
/subsystem=elytron/security-domain=__SECURITY_DOMAIN__:write-attribute(name="evidence-decoder",value="aggregateDecoder")
/subsystem=elytron/x500-subject-evidence-decoder=exampleSubjectDecoder:add()
/subsystem=elytron/custom-evidence-decoder=myCustomEvidenceDecoder:add(module=__MODULE_NAME__, class-name=__FULLY_QUALIFIED_CLASS_NAME__)