Chapter 9. Migrating to Elytron JBoss EAP 7.1 introduced Elytron, which provides a single unified framework that can manage and configure access for both standalone servers and managed domains. It can also be used to configure security access for applications deployed to JBoss EAP servers. Starting with JBoss EAP 8.0, you must use Elytron as the legacy security subsystem is not available for migrating your application. 9.1. Overview of Elytron Important The architectures of Elytron and the legacy security subsystem that is based on PicketBox are very different. With Elytron, an attempt was made to create a solution that allows you to operate in the same security environments in which you currently operate; however, this does not mean that every PicketBox configuration option has an equivalent configuration option in Elytron. If you are not able to find information in the documentation to help you achieve similar functionality using Elytron that you had when using the legacy security implementation, you can find help in one of the following ways. If you have a Red Hat Development subscription , you have access to Support Cases , Solutions , and Knowledge Articles on the Red Hat Customer Portal. You can also open a case with Technical Support and get help from the WildFly community as described below. If you do not have a Red Hat Development subscription, you can still access Knowledge Articles on the Red Hat Customer Portal. You can also join the user forums and live chat to ask questions of the WildFly community. The WildFly community offerings are actively monitored by the Elytron engineering team. For an overview of the new resources that are available in the elytron subsystem, see Resources in the Elytron Subsystem in the JBoss EAP 7.4 Security Architecture . 9.2. Migrate Secure Vaults and Properties To use Elytron, you must migrate secure vaults to secure credential storage and migrate legacy security properties to Elytron security properties. 9.2.1. Migrate Secure Vaults to Secure Credential Storage The secure vault used to store plain text string encryption in the legacy security subsystem in JBoss EAP 7.0 is not compatible with Elytron in JBoss EAP 7.1 or later. JBoss EAP 7.1 or later uses a credential store to store strings. Credential stores encrypt credentials in a storage file outside of the JBoss EAP configuration files. You can use the implementation provided by Elytron or you can customize the configuration using the credential store APIs and SPIs. Each JBoss EAP server can contain multiple credential stores. Note If you previously used vault expressions to parameterize nonsensitive data, you must replace the data with Elytron security properties. For more information about Elytron security properties, see Elytron security properties . For more information about credential stores, see Credential Stores in the JBoss EAP 7.4 How to Configure Server Security . 9.2.1.1. Migrate vault data using the WildFly Elytron tool The WildFly Elytron Tool that ships with JBoss EAP provides a vault command to help you migrate vault content to credential stores. To execute the vault command, run the elytron-tool script in the EAP_HOME /bin directory. You can use the following command to get a description of all of the available arguments. Important Credential stores are only used for securing passwords. The vault expression feature used in the management model is not supported. For more information, see Creating an encrypted expression in Elytron Choose one of the following migration options: Migrating an Individual Security Vault to a Credential Store Migrating multiple security vaults to a credential store in bulk Note The WildFly Elytron Tool cannot handle the first version of the security vault data files. You can enter the --keystore-password argument in the masked format, as shown in the following example to migrate a single vault, or in clear text. The --salt and --iteration arguments are provided to supply information to decrypt the masked password or to generate a masked password in the output. If the --salt and --iteration arguments are omitted, default values are used. The --summary argument produces formatted management CLI commands that can be used to add the converted credential stores to the JBoss EAP configuration. Plain text passwords are masked in the summary output. 9.2.1.1.1. Migrating an Individual Security Vault to a Credential Store Migrate individual security vaults to a credential store using the following example: Example: Converting a single security vault to a credential store command This command converts the security vault to a credential store and prints the summary of the management CLI commands that were used to convert it in the output. 9.2.1.1.2. Migrating multiple security vaults to a credential store in bulk You can convert multiple vaults to a credential store using the --bulk-convert argument and pointing to a bulk conversion descriptor file. Prerequisites The examples in this section use the following bulk conversion descriptor file. Example: bulk-vault-conversion-descriptor.txt File A new conversion starts when each new keystore: line is encountered. All options are mandatory except for salt , iteration , and properties . Procedure To perform the bulk conversion and generate output that formats the management CLI commands, execute the following command. This command converts all of the security vaults specified in the file to a credential store and prints the summary of the management CLI commands that were used to convert them in the output. 9.2.2. Migrating Security Properties to Elytron The following examples assume that the group.name and encoding.algorithm security properties are defined as security-properties in the legacy security subsystem. Security Properties Defined in the security Subsystem: <subsystem xmlns="urn:jboss:domain:security:2.0"> ... <security-properties> <property name="group.name" value="engineering-group" /> <property name="encoding.algorithm" value="BASE64" /> </security-properties> </subsystem> To define these security properties in the elytron subsystem, set the security-properties attribute of the elytron subsystem using the following management CLI command: This defines the security-properties in the elytron subsystem in the server configuration file. <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <security-properties> <security-property name="group.name" value="engineering-group"/> <security-property name="encoding.algorithm" value="BASE64"/> </security-properties> ... </subsystem> The write-attribute operation in the command overwrites the existing properties. To add or change a security property without impacting other security properties, use the map operation in the management CLI command: In a similar manner, you can remove a specific security property by using the map-remove operation: 9.3. Migrate Authentication Configuration This section provides information on migration of properties-based authentication and authorization to Elytron. In addition, it also includes information for migration of LDAP authentication, database authentication configuration, kerberos authentication, composite stores, JACC security, and security domains that use caching to Elytron. 9.3.1. Migrate PicketBox Properties-based Configuration to Elytron Migrate PicketBox properties-based authentication to Elytron using the following example. Example: PicketBox Properties-based Configuration Commands This results in the following server configuration. Example: PicketBox Properties-based Security Domain Configuration <security-domain name="application-security"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="usersProperties" value="file://USD{jboss.server.config.dir}/example-users.properties"/> <module-option name="rolesProperties" value="file://USD{jboss.server.config.dir}/example-roles.properties"/> </login-module> </authentication> </security-domain> 9.3.1.1. Migrating Properties-based Authentication to Elytron Follow these steps to migrate the PicketBox properties-based authentication to Elytron. Prerequisite The deployed web application you plan to migrate must be configured to require form-based authentication. The application is referencing a PicketBox security domain and is using the UsersRolesLoginModule to load user information from the example-users.properties and example-roles.properties files. This procedure also assumes that the security domain is defined in the legacy security subsystem using the following management CLI commands. Ensure that you are starting with the PicketBox properties-based authentication configured. Procedure Define a new security realm in the elytron subsystem that references the PicketBox properties files. Define a security domain subsystem in the elytron subsystem. This results in the following elytron subsystem configuration in the server configuration file. <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> ... <security-domains> ... <security-domain name="application-security" default-realm="application-properties" permission-mapper="default-permission-mapper"> <realm name="application-properties"/> </security-domain> </security-domains> <security-realms> ... <properties-realm name="application-properties" groups-attribute="Roles"> <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/> <groups-properties path="example-roles.properties" relative-to="jboss.server.config.dir"/> </properties-realm> </security-realms> ... </subsystem> Map the application security domain referenced by the deployment to the newly defined HTTP authentication factory in the undertow subsystem. This results in the following undertow subsystem configuration in the server configuration file. <subsystem xmlns="urn:jboss:domain:undertow:12.0"> ... <application-security-domains> <application-security-domain name="application-security" security-domain="application-security"/> </application-security-domains> ... </subsystem> You must reload the server or redeploy the application for the new application security domain mapping to take effect. Authentication is now configured to be equivalent to the PicketBox configuration. 9.3.2. Migrating legacy security realm properties-based configuration to Elytron This section describes how to migrate a legacy security realm that loads user, password, and group information from properties files to Elytron in JBoss EAP 7.4 and earlier. This type of legacy security realm was typically used to secure either the management interfaces or remoting connectors. In JBoss EAP 8.0, filesystem-realm is preferred over properties-realm. Prerequisites The deployed web application you plan to migrate must be configured to require form-based authentication. The application is referencing a PicketBox security domain and is using the UsersRolesLoginModule to load user information from the example-users.properties and example-roles.properties files. This procedure also assumes that the security domain is defined in the legacy security subsystem using the following management CLI commands. Example: Legacy Security Realm Commands This results in the following server configuration. Example: Legacy Security Realm Configuration <security-realm name="ApplicationSecurity"> <authentication> <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/> </authentication> <authorization> <properties path="example-roles.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm> One of the reasons for adding the Elytron security to the application server was to allow a consistent security solution to be used across the server. The initial steps to migrate a properties-based legacy security realm to Elytron are similar to those used to migrate a PicketBox properties-based authentication to Elytron. Follow these steps to migrate a properties-based legacy security realm to Elytron. Procedure Define a new security realm in the elytron subsystem that references the properties files. Define a security domain subsystem in the elytron subsystem. This results in the following Elytron configuration. <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> ... <security-domains> ... <security-domain name="application-security" default-realm="application-properties" permission-mapper="default-permission-mapper"> <realm name="application-properties"/> </security-domain> </security-domains> <security-realms> ... <properties-realm name="application-properties" groups-attribute="Roles"> <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/> <groups-properties path="example-roles.properties" relative-to="jboss.server.config.dir"/> </properties-realm> </security-realms> ... </subsystem> Define a sasl-authentication-factory so that the legacy security realm can also be used for Simple Authentication Security Layer (SASL) authentication. This results in the following Elytron configuration. <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> ... <sasl> ... <sasl-authentication-factory name="application-security-sasl" sasl-server-factory="elytron" security-domain="application-security"> <mechanism-configuration> <mechanism mechanism-name="PLAIN"/> </mechanism-configuration> </sasl-authentication-factory> ... </sasl> </subsystem> Configure a remoting connector for the SASL authentication and remove the association with the legacy security realm. This results in the following configuration in the remoting subsystem of the server configuration file. <subsystem xmlns="urn:jboss:domain:remoting:4.0"> ... <http-connector name="http-remoting-connector" connector-ref="default" sasl-authentication-factory="application-security-sasl"/> </subsystem> Add the two authentication factories to secure the http-interface with Elytron. This results in the following configuration. <management-interfaces> <http-interface http-authentication-factory="application-security-http"> <http-upgrade enabled="true" sasl-authentication-factory="application-security-sasl"/> <socket-binding http="management-http"/> </http-interface> </management-interfaces> Note You should replace the names with those used in these examples when securing management interfaces. The migration of the legacy properties-based configuration to Elytron is now complete. 9.3.3. Migrating to Filesystem-based Security Realm Using the filesystem-realm Command Migrate the legacy properties-based security realm to a filesystem-based realm in Elytron using the filesystem-realm command of the elytron.sh tool. A filesystem-based realm is a filesystem-based identity store used by Elytron for storing user identities. The filesystem-realm command converts the properties-realm files to filesystem-realm . It also generates commands for adding this realm and a security domain to the elytron subsystem. Procedure Migrate the properties file. You can migrate a single user-properties file at a time, or migrate the properties files in bulk. The following examples illustrate the procedures for both types of migration. To migrate a single properties file, do this. The following example converts a single users-properties file with the associated roles-properties file to filesystem-realm . The example assumes that the legacy security domain has the following user-properties and role-properties files: Example: Single user-property file migration This creates filesystem-realm files and a script containing management CLI commands. The script is stored in the realms/example directory. To migrate multiple properties files do. The following example converts the users-properties files with the associated roles-properties files in bulk to filesystem-realm . The example assumes that the legacy security domain has the following properties files: To convert users-roles files in bulk, you must create a descriptor file to use with the filesystem-realm command. For this example, a descriptor file example-descriptor-file located in the /bin directory is created with the following content: Example: descriptor file A blank line in the descriptor file is used to separate the operations for each users-properties file. The following example converts two users-properties files with the associated roles-properties file using a descriptor file to filesystem-realm . Example: Bulk migration This creates the filesystem-realm files and scripts containing the management CLI commands. The scripts are stored in directories specified in the descriptor file's output-location attribute. Add the new security realm and the security domain to the elytron subsystem using the CLI commands generated by the Elytron tool. Example: Adding the filesystem-realm 9.3.4. Migrating LDAP Authentication Configuration to Elytron Migrate legacy LDAP authentication to Elytron so that it can manage the information as identity attributes. Prerequisites Before you migrate legacy LDAP authentication to Elytron, you must read the content in the Migrate Properties-based Authentication and Authorization to Elytron section applies, which is also applicable here. You must focus on regarding how to define security domains and authentication factories, and how to map them to be used for authentication. This section does not repeat those instructions, so ensure that you read through that section before you continue. The following examples assume that group or role information is loaded directly from LDAP and that the legacy LDAP authentication is configured as follows. Procedure The LDAP server contains the following user and group entries. Example: LDAP Server User Entries Example: LDAP Server Group Entries For authentication purposes the user name is matched against the uid attribute and the resulting group name is taken from the uid attribute of the group entry. The connection to the LDAP server and related security realm is defined using the following management CLI commands. Example: LDAP Security Realm Configuration Commands This results in the following server configuration. Example: LDAP Security Realm Configuration <management> <security-realms> ... <security-realm name="LDAPRealm"> <authentication> <ldap connection="MyLdapConnection" base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org"> <username-filter attribute="uid"/> </ldap> </authentication> <authorization> <ldap connection="MyLdapConnection"> <username-to-dn> <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/> </username-to-dn> <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid"> <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true"> <membership-filter principal-attribute="uniqueMember"/> </group-to-principal> </group-search> </ldap> </authorization> </security-realm> </security-realms> <outbound-connections> <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/> </outbound-connections> ... </management> The following management CLI commands are used to configure a PicketBox security domain, which uses the LdapExtLoginModule to verify a user name and password. Example: Security Domain Configuration Commands This results in the following server configuration. Example: Security Domain Configuration <subsystem xmlns="urn:jboss:domain:security:2.0"> ... <security-domains> ... <security-domain name="application-security"> <authentication> <login-module code="LdapExtended" flag="required"> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/> <module-option name="java.naming.security.authentication" value="simple"/> <module-option name="bindDN" value="uid=admin,ou=system"/> <module-option name="bindCredential" value="secret"/> <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="baseFilter" value="(uid={0})"/> <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="roleFilter" value="(uniqueMember={1})"/> <module-option name="roleAttributeID" value="uid"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem> 9.3.4.1. Migrating the Legacy LDAP Authentication to Elytron Follow these steps to migrate the LDAP authentication example configuration to Elytron in JBoss EAP 7.4 and earlier. This section applies to the migration of a legacy security LDAP realm as well as a PicketBox LDAP security domain . Procedure Define a connection to LDAP in the elytron subsystem. Create a security realm to search LDAP and verify the supplied password. These steps result in the following elytron subsystem configuration in the server configuration file. <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> ... <security-realms> ... <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true"> <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org"> <attribute-mapping> <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> </attribute-mapping> </identity-mapping> </ldap-realm> </security-realms> ... <dir-contexts> <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system"> <credential-reference clear-text="secret"/> </dir-context> </dir-contexts> </subsystem> Note By default, if no role-decoder is defined for a given security-domain , the "Roles" identity attribute is mapped to the identity roles. Information loaded from LDAP can now be associated with identities as attributes. These attributes can be mapped to roles, but they can also be loaded and used for other purposes. The newly created security realm can be used in a security domain in the same way as it is described in the Migrate Properties-based Authentication and Authorization to Elytron section of this guide. 9.3.5. Migrate Database Authentication Configuration to Elytron Migrate JDBC datasource-based PicketBox authentication to Elytron. For instructions on defining security domains, authentication factories, and mapping them for authentication, see Migrate Properties-based Authentication and Authorization to Elytron . The following examples assume that the user authentication data is stored in a database table created using syntax similar to the following example. Example: Syntax to Create the Database User Table For authentication purposes the username is matched against data stored in the username column, the password is expected to be stored as a hex-encoded MD5 hash in the password column, and the user role for authorization purposes is stored in the role column. The PicketBox security domain is configured to use a JBDC datasource to retrieve data from the database table, and then use it to verify the username and password, and to assign roles. Assume the PicketBox security domain is configured using the following management CLI commands. Example: PicketBox Database LoginModule Configuration Commands This results in the following login-module configuration in the legacy security subsystem. Example: PicketBox LoginModule Configuration <subsystem xmlns="urn:jboss:domain:security:2.0"> <security-domains> ... <security-domain name="application-security"> <authentication> <login-module code="Database" flag="required"> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/> <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/> <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/> <module-option name="hashAlgorithm" value="MD5"/> <module-option name="hashEncoding" value="base64"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem> 9.3.5.1. Migrating the legacy database authentication to Elytron For JBoss EAP 7.4 and earlier releases, you must define a JDBC realm to enable JDBC datasource access by Elytron to migrate the database authentication example configuration to Elytron. Procedure Use the following management command to define the jdbc-realm . This results in the following jdbc-realm configuration in the elytron subsystem of the server configuration file. <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> ... <security-realms> ... <jdbc-realm name="jdbc-realm"> <principal-query sql="SELECT role, password FROM User WHERE username = ?" data-source="ExampleDS"> <attribute-mapping> <attribute to="Roles" index="1"/> </attribute-mapping> <simple-digest-mapper password-index="2"/> </principal-query> </jdbc-realm> ... </security-realms> ... </subsystem> Elytron now manages the database authentication using the JDBC realm configuration. Elytron is more efficient than PicketBox because it uses one SQL query to obtain all of the user attributes and credentials, and then extracts data from the SQL results and creates a mapping of the attributes to use for authentication. 9.3.6. Migrate Kerberos Authentication to Elytron When working with a Kerberos configuration, the JBoss EAP server can rely on configuration information from the environment, or the key configuration can be specified using system properties. These system properties are applicable to both the legacy configuration and the migrated Elytron configuration. Example: Kerberos System Properties Management CLI Commands Example: Kerberos System Properties Server Configuration <system-properties> <property name="sun.security.krb5.debug" value="true"/> <property name="java.security.krb5.realm" value="ELYTRON.ORG"/> <property name="java.security.krb5.kdc" value="kdc.elytron.org"/> </system-properties> Depending on your authentication mechanisms, choose one of the following migration options: Migrate Kerberos HTTP Authentication Migrate Kerberos Remoting SASL Authentication 9.3.6.1. Migrating Kerberos HTTP Authentication In legacy security configurations, you can define a security realm to enable SPNEGO authentication for the HTTP management interface as follows. Prerequisite The examples that follow assume that Kerberos is configured using the system properties. Example: Enable SPNEGO authentication for the HTTP management interface Example: Kerberos Security Realm Configuration <security-realms> ... <security-realm name="Kerberos"> <server-identities> <kerberos> <keytab principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path=" /path/to/ test-server.keytab" debug="true"/> </kerberos> </server-identities> <authentication> <kerberos remove-realm="true"/> </authentication> </security-realm> </security-realms> You can also define a pair of legacy security domains to allow applications to use Kerberos HTTP authentication. Example: Define Multiple Security Domains Example: Configuration Using a Pair of Security Domains <subsystem xmlns="urn:jboss:domain:security:2.0"> <security-domains> ... <security-domain name="host"> <authentication> <login-module name="1" code="Kerberos" flag="required"> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="principal" value="HTTP/test-server.elytron.org@ELYTRON.ORG"/> <module-option name="keyTab" value=" /path/to/ test-server.keytab"/> <module-option name="debug" value="true"/> </login-module> </authentication> </security-domain> <security-domain name="SPNEGO"> <authentication> <login-module name="1" code="SPNEGO" flag="requisite" module="org.jboss.security.negotiation"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="serverSecurityDomain" value="host"/> </login-module> <login-module name="2" code="UsersRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value=" path/to /kerberos/spnego-users.properties"/> <module-option name="rolesProperties" value=" / path/to / kerberos/spnego-roles.properties"/> <module-option name="defaultUsersProperties" value=" / path/to / kerberos/spnego-users.properties"/> <module-option name="defaultRolesProperties" value=" / path/to / kerberos/spnego-roles.properties"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem> The legacy applications are then deployed referencing the SPNEGO security domain and secured with the SPNEGO mechanism. 9.3.6.1.1. Migrate the Kerberos HTTP Authentication to Elytron Secure the management interface and applications in Elytron by using a security realm and a Kerberos security factory. Prerequisite The examples that follow assume that Kerberos is configured using the system properties. Procedure Define a security realm to be used to load identity information. Define a Kerberos security factory that allows the server to load its own Kerberos identity. Define a security domain to pull together the policy as well as an HTTP authentication factory for the authentication policy. This results in the following configuration in the elytron subsystem of the server configuration file. Example: Migrated Elytron Configuration <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> ... <security-domains> ... <security-domain name="SPNEGODomain" default-realm="spnego-properties" permission-mapper="default-permission-mapper"> <realm name="spnego-properties" role-decoder="groups-to-roles"/> </security-domain> </security-domains> <security-realms> ... <properties-realm name="spnego-properties"> <users-properties path=" path/to/ spnego-users.properties" digest-realm-name="ELYTRON.ORG" plain-text="true"/> <groups-properties path=" path/to/ spnego-roles.properties"/> </properties-realm> </security-realms> <credential-security-factories> <kerberos-security-factory name="test-server" principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path=" path/to/ test-server.keytab" debug="true"/> </credential-security-factories> ... <http> ... <http-authentication-factory name="spnego-http-authentication" http-server-mechanism-factory="global" security-domain="SPNEGODomain"> <mechanism-configuration> <mechanism mechanism-name="SPNEGO" credential-security-factory="test-server"/> </mechanism-configuration> </http-authentication-factory> ... </http> ... </subsystem> To secure the application, define an application security domain in the undertow subsystem to map security domains to this http-authentication-factory . The HTTP management interface can be updated to reference the http-authentication-factory defined in this configuration. This process is documented in the Migrate Properties-based Authentication and Authorization to Elytron . 9.3.6.2. Migrating Kerberos Remoting SASL Authentication Migrate Kerberos remoting SASL authentication using the following information. Procedure Define a legacy security realm for Kerberos / GSSAPI SASL authentication to be used for remoting authentication, such as the native management interface. Example: Kerberos Authentication for Remoting Management CLI Commands Example: Kerberos Remoting Security Realm Configuration <management> <security-realms> ... <security-realm name="Kerberos"> <server-identities> <kerberos> <keytab principal="remote/test-server.elytron.org@ELYTRON.ORG" path=" path/to /remote-test-server.keytab" debug="true"/> </kerberos> </server-identities> <authentication> <kerberos remove-realm="true"/> </authentication> </security-realm> </security-realms> ... </management> 9.3.6.2.1. Migrate the Kerberos Remoting SASL Authentication to Elytron Migrate the Kerberos remoting SASL authentication to Elytron using the following steps. Procedure Define a security realm to be used to load identity information. Define the Kerberos security factory for the server's identity. Define the security domain and a SASL authentication factory. This results in the following configuration in the elytron subsystem of the server configuration file. <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> ... <security-domains> ... <security-domain name="KerberosDomain" default-realm="kerberos-properties" permission-mapper="default-permission-mapper"> <realm name="kerberos-properties" role-decoder="groups-to-roles"/> </security-domain> </security-domains> <security-realms> ... <properties-realm name="kerberos-properties"> <users-properties path="kerberos-users.properties" relative-to="kerberos" digest-realm-name="ELYTRON.ORG"/> <groups-properties path="kerberos-groups.properties" relative-to="kerberos"/> </properties-realm> </security-realms> <credential-security-factories> <kerberos-security-factory name="test-server" principal="remote/test-server.elytron.org@ELYTRON.ORG" path="remote-test-server.keytab" relative-to="kerberos"/> </credential-security-factories> ... <sasl> ... <sasl-authentication-factory name="gssapi-authentication-factory" sasl-server-factory="elytron" security-domain="KerberosDomain"> <mechanism-configuration> <mechanism mechanism-name="GSSAPI" credential-security-factory="test-server"/> </mechanism-configuration> </sasl-authentication-factory> ... </sasl> </subsystem> Verification The management interface or remoting connectors can now be updated to reference the SASL authentication factory. The two Elytron examples defined here could also be combined to use a shared security domain and security realm and just use protocol-specific authentication factories each referencing their own Kerberos security factory. Additional resources These steps to define the equivalent Elytron configuration are very similar to those described in Migrate Kerberos HTTP Authentication . 9.3.7. Migrate Composite Stores to Elytron This section describes how to migrate a PicketBox or legacy security realm configuration that uses multiple identity stores to Elytron Aggregate Security Realm Configuration . When using either PicketBox or the legacy security realms, it is possible to define a configuration where authentication is performed against one identity store while the information used for authorization is loaded from a different store. When migrating to Elytron, this can be achieved by using an aggregate security realm. The following examples perform user authentication using the example-users.properties properties file, and then query LDAP to load the group and role information. Note The configurations shown are based on the examples in the following sections, which provide additional background information: Migrate PicketBox Properties-based Configuration to Elytron Migrate LDAP Authentication Configuration to Elytron 9.3.7.1. PicketBox Composite Store Configuration The PicketBox security domain for this scenario is configured using the following management CLI commands. Example: PicketBox Configuration Commands This results in the following server configuration. Example: PicketBox Security Domain Configuration <security-domain name="application-security"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value="file://USD{jboss.server.config.dir}/example-users.properties"/> </login-module> <login-module code="LdapExtended" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/> <module-option name="java.naming.security.authentication" value="simple"/> <module-option name="bindDN" value="uid=admin,ou=system"/> <module-option name="bindCredential" value="secret"/> <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="baseFilter" value="(uid={0})"/> <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="roleFilter" value="(uniqueMember={1})"/> <module-option name="roleAttributeID" value="uid"/> </login-module> </authentication> </security-domain> For more information, see Elytron Aggregate Security Realm Configuration for how to configure an aggregate security realm. 9.3.7.2. Legacy Security Realm Composite Store Configuration For JBoss EAP 7.4 and earlier releses, the legacy security realm configuration is configured using the following management CLI commands. Note As the legacy security commands are not applicable in JBoss EAP 8, these commands are only applicable in JBoss EAP 7.4 and earlier releases. Example: Legacy Security Realm Configuration Commands This results in the following server configuration. Example: Legacy Security Realm Configuration <security-realms> ... <security-realm name="ApplicationSecurity"> <authentication> <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/> </authentication> <authorization> <ldap connection="MyLdapConnection"> <username-to-dn> <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/> </username-to-dn> <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid"> <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true"> <membership-filter principal-attribute="uniqueMember"/> </group-to-principal> </group-search> </ldap> </authorization> </security-realm> </security-realms> <outbound-connections> <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/> </outbound-connections> See Elytron Aggregate Security Realm Configuration for how to configure an aggregate security realm in the elytron subsystem to accomplish this. 9.3.7.3. Elytron Aggregate Security Realm Configuration The equivalent Elytron configuration for this scenario is configured using the following management CLI commands. Example: Elytron Configuration Commands This results in the following server configuration. Example: Elytron Configuration <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> ... <security-domains> ... <security-domain name="application-security" default-realm="combined-realm" permission-mapper="default-permission-mapper"> <realm name="combined-realm"/> </security-domain> </security-domains> <security-realms> <aggregate-realm name="combined-realm" authentication-realm="application-properties" authorization-realm="ldap-realm"/> ... <properties-realm name="application-properties"> <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/> </properties-realm> <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true"> <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org"> <attribute-mapping> <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> </attribute-mapping> </identity-mapping> </ldap-realm> </security-realms> ... <http> ... <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security"> <mechanism-configuration> <mechanism mechanism-name="BASIC"/> </mechanism-configuration> </http-authentication-factory> ... </http> ... <dir-contexts> <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system"> <credential-reference clear-text="secret"/> </dir-context> </dir-contexts> </subsystem> In the elytron subsystem, an aggregate-realm has been defined that specifies which security realms to use for authentication and which to use for authorization decisions. 9.3.8. Migrate security domains that use caching to Elytron When using PicketBox, it was possible to define a security domain and enable in-memory caching for its access. This allowed you to access the identity data in memory and avoid additional direct access to the identity store. It is possible to achieve a similar configuration with Elytron. This section shows an example PicketBox configuration and equivalent security domain caching configuration when using Elytron. 9.3.8.1. PicketBox Cached Security Domain Configuration The following commands show PicketBox security domain configuration to enable caching in JBoss EAP 7.4 and earlier. Example: PicketBox Cached Security Domain Commands This results in the following server configuration. Example: PicketBox Cached Security Domain Configuration <subsystem xmlns="urn:jboss:domain:security:2.0"> <security-domains> ... <security-domain name="application-security" cache-type="default"> <authentication> <login-module code="LdapExtended" flag="required"> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/> <module-option name="java.naming.security.authentication" value="simple"/> <module-option name="bindDN" value="uid=admin,ou=system"/> <module-option name="bindCredential" value="secret"/> <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="baseFilter" value="(uid={0})"/> <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="roleFilter" value="(uniqueMember={1})"/> <module-option name="roleAttributeID" value="uid"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem> Note This command and resulting configuration is similar to the example shown in Migrate LDAP Authentication Configuration to Elytron ; however, here the attribute cache-type is defined with a value of default . The default cache type is an in-memory cache. When using PicketBox, you can also specify a cache-type of infinispan , however this type is not supported with Elytron. 9.3.8.2. Configuring an Elytron cached security domain Follow the steps below to create a similar configuration that caches a security domain when using Elytron. Procedure Define a security realm and wrap the security realm in a caching realm. The caching realm can then be used in a security domain and subsequently in an authentication factory. Example: Elytron Security Realm Configuration Commands Define a security domain and an HTTP authentication factory that use the cached-ldap realm defined in the step. Example: Elytron Security Domain and Authentication Factory Configuration Commands Note You must reference the caching-realm instead of the original realm. Otherwise, caching is bypassed. These commands result in the following additions to the server configuration. Example: Elytron Cached Security Domain Configuration <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> ... <security-domains> ... <security-domain name="application-security" default-realm="cached-ldap" permission-mapper="default-permission-mapper"> <realm name="cached-ldap"/> </security-domain> </security-domains> ... <security-realms> .... <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true"> <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org"> <attribute-mapping> <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> </attribute-mapping> </identity-mapping> </ldap-realm> <caching-realm name="cached-ldap" realm="ldap-realm"/> </security-realms> ... <http> ... <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security"> <mechanism-configuration> <mechanism mechanism-name="BASIC"/> </mechanism-configuration> </http-authentication-factory> ... </http> ... <dir-contexts> <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system"> <credential-reference clear-text="secret"/> </dir-context> </dir-contexts> ... 9.3.9. Migrate Jakarta authorization security to Elytron By default, JBoss EAP 7.4 and earlier uses the legacy security subsystem to configure the Jakarta Authorization policy provider and factory. The default configuration maps to implementations from PicketBox. The elytron subsystem provides a built-in policy provider based on the Java Authorization Contract for Containers (JACC) specification. For information about how to enable and define a Java Authorization Contract for Containers policy provider in the elytron subsystem, see Define a Jakarta Authentication Policy Provider in the JBoss EAP 7.4 Development Guide . 9.4. Migrate Application Clients This section provides information on how to migrate client applications to Elytron. Migrate a Naming Client Configuration to Elytron This section describes how to migrate a client application that performs a remote JNDI lookup using an org.jboss.naming.remote.client.InitialContext class, which is backed by an org.jboss.naming.remote.client.InitialContextFactory class, to Elytron. The following example assumes that the InitialContextFactory class is created by specifying properties for the user credentials and for the URL of the naming provider that it connects to. Example: InitialContext Code Used in the Release Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory"); properties.put(Context.PROVIDER_URL,"http-remoting://127.0.0.1:8080"); properties.put(Context.SECURITY_PRINCIPAL, "bob"); properties.put(Context.SECURITY_CREDENTIALS, "secret"); InitialContext context = new InitialContext(properties); Bar bar = (Bar) context.lookup("foo/bar"); ... You can choose from one of the following migration approaches: Migrate the Naming Client Using the Configuration File Approach Migrate the Naming Client Using the Programmatic Approach 9.4.1. Migrating the Naming Client Using the Configuration File Approach Migrate your naming client to Elytron using the configuration approach. Procedure Create a wildfly-config.xml file in the client application META-INF/ directory. The file should contain the user credentials that are to be used when establishing a connection to the naming provider. Example: wildfly-config.xml File <configuration> <authentication-client xmlns="urn:elytron:client:1.7"> <authentication-rules> <rule use-configuration="namingConfig"> <match-host name="127.0.0.1"/> </rule> </authentication-rules> <authentication-configurations> <configuration name="namingConfig"> <set-user-name name="bob"/> <credentials> <clear-password password="secret"/> </credentials> </configuration> </authentication-configurations> </authentication-client> </configuration> Create an InitialContext as in the following example. Note that the InitialContext is backed by the org.wildfly.naming.client.WildFlyInitialContextFactory class. Example: InitialContext Code Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory"); properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080"); InitialContext context = new InitialContext(properties); Bar bar = (Bar) context.lookup("foo/bar"); ... 9.4.2. Migrating the Naming Client Using the Programmatic Approach Using this approach, you provide the user credentials that are used to establish a connection to the naming provider directly in the application code. Example: Code Using the Programmatic Approach // Create the authentication configuration AuthenticationConfiguration namingConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret"); // Create the authentication context AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), namingConfig); // Create a callable that creates and uses an InitialContext Callable<Void> callable = () -> { Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory"); properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080"); InitialContext context = new InitialContext(properties); Bar bar = (Bar) context.lookup("foo/bar"); ... return null; }; // Use the authentication context to run the callable context.runCallable(callable); 9.4.3. Migrate a Jakarta Enterprise Beans client to Elytron This migration example assumes that the client application is configured to invoke an Jakarta Enterprise Beans deployed to a remote server using a jboss-ejb-client.properties file. This file, which is located in the client application META-INF/ directory, contains the following information needed to connect to the remote server. Example: jboss-ejb-client.properties file The client looks up the Jakarta Enterprise Beans and calls one of its methods using code similar to the following example. Example: Client code that calls a remote Jakarta Enterprise Beans // Create an InitialContext Properties properties = new Properties(); properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); InitialContext context = new InitialContext(properties); // Look up the Jakarta Enterprise Beans and invoke one of its methods RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup( "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName()); int sum = statelessRemoteCalculator.add(101, 202); You can choose from one of the following migration approaches: Migrate the Jakarta Enterprise Beans client using a configuration file Migrate the Jakarta Enterprise Beans client programmatically 9.4.3.1. Migrate the Jakarta Enterprise Beans client using a configuration file Follow these steps to migrate your naming client to Elytron using the configuration approach. Procedure Configure a wildfly-config.xml file in the client application META-INF/ directory. The file should contain the user credentials that are to be used when establishing a connection to the naming provider. Example: wildfly-config.xml file <configuration> <authentication-client xmlns="urn:elytron:client:1.7"> <authentication-rules> <rule use-configuration="ejbConfig"> <match-host name="127.0.0.1"/> </rule> </authentication-rules> <authentication-configurations> <configuration name="ejbConfig"> <set-user-name name="bob"/> <credentials> <clear-password password="secret"/> </credentials> </configuration> </authentication-configurations> </authentication-client> <jboss-ejb-client xmlns="urn:jboss:wildfly-client-ejb:3.0"> <connections> <connection uri="remote+http://127.0.0.1:8080" /> </connections> </jboss-ejb-client> </configuration> Create an InitialContext as in the following example. Note that the InitialContext is backed by the org.wildfly.naming.client.WildFlyInitialContextFactory class. Example: InitialContext code // Create an InitialContext Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory"); InitialContext context = new InitialContext(properties); // Look up an Jakarta Enterprise Beans and invoke one of its methods // Note that this code is the same as before RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup( "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName()); int sum = statelessRemoteCalculator.add(101, 202);---- You can now delete the obsolete jboss-ejb-client.properties file as that file is no longer needed. 9.4.3.2. Migrate the Jakarta Enterprise Beans client programmatically Migrate the Jakarta Enterprise Beans client programmatically using the following step. Procedure Provide the information needed to connect to the remote server directly in the application code. Example: Code using the programmatic approach // Create the authentication configuration AuthenticationConfiguration ejbConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret"); // Create the authentication context AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), ejbConfig); // Create a callable that invokes the Jakarta Enterprise Beans Callable<Void> callable = () -> { // Create an InitialContext Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory"); properties.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080"); InitialContext context = new InitialContext(properties); // Look up the Jakarta Enterprise Beans and invoke one of its methods // Note that this code is the same as before RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup( "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName()); int sum = statelessRemoteCalculator.add(101, 202); ... return null; }; // Use the authentication context to run the callable context.runCallable(callable); You can now delete the obsolete jboss-ejb-client.properties file as that file is no longer needed. 9.5. Migrate SSL Configurations Migrate SSL configurations in your applications to use Elytron with the following information. Migrate a Simple SSL Configuration to Elytron If you secured HTTP connections to the JBoss EAP server using a security realm, migrate the SSL configuration to Elytron using the information provided in this section. Prerequisites Have secured HTTP connections to the JBoss EAP server using a security realm. The following examples assume you have the following keystore configured in the security-realm . Example: SSL Configuration Using a Security Realm Keystore <security-realm name="ApplicationRealm"> <server-identities> <ssl> <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" /> </ssl> </server-identities> </security-realm> Complete the following steps to achieve the same configuration using Elytron. Procedure Create a key-store in the elytron subsystem that specifies the location of the keystore and the password by which it is encrypted. This command assumes the keystore was generated using the keytool command and its type is JKS . Create a key-manager in the elytron subsystem that specifies the key-store defined in the step, the alias, and password of the key. Create a server-ssl-context in the elytron subsystem that references the key-manager that was defined in the step. Switch the https-listener from the legacy security-realm to the newly created Elytron ssl-context . Reload the server. This results in the following elytron subsystem configuration in the server configuration file. <subsystem xmlns="urn:wildfly:elytron:4.0" ...> ... <tls> <key-stores> <key-store name="LocalhostKeyStore"> <credential-reference clear-text="keystore_password"/> <implementation type="JKS"/> <file path="server.keystore" relative-to="jboss.server.config.dir"/> </key-store> </key-stores> <key-managers> <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore" alias-filter="server"> <credential-reference clear-text="key_password"/> </key-manager> </key-managers> <server-ssl-contexts> <server-ssl-context name="LocalhostSslContext" key-manager="LocalhostKeyManager"/> </server-ssl-contexts> </tls> </subsystem> This results in the following undertow subsystem configuration in the server configuration file. <https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/> For more information, see Elytron Subsystem and How to Secure the Management Interfaces in the JBoss EAP 7.4 How to Configure Server Security . 9.5.1. Migrate CLIENT-CERT SSL Authentication to Elytron To enable CLIENT-CERT SSL authentication, add a truststore element to the authentication element. <security-realm name="ManagementRealm"> <server-identities> <ssl> <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password=" KEYSTORE_PASSWORD " alias="server" key-password="key_password" /> </ssl> </server-identities> <authentication> <truststore path="server.truststore" relative-to="jboss.server.config.dir" keystore-password=" TRUSTSTORE_PASSWORD " /> <local default-user="USDlocal"/> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/> </authentication> </security-realm> Note With this configuration if the CLIENT-CERT authentication does not occur, clients can fall back to use either the local mechanism or the username/password authentication mechanism. To make CLIENT-CERT based authentication mandatory, remove the local and properties elements. A legacy truststore can be used in two ways: Legacy truststore containing only CA Legacy truststore containing client's certificate 9.5.1.1. Legacy truststore Containing Only CA Follow these steps to configure the server to prevent users without a valid certificate and private key from accessing the server using Elytron. Procedure Create a key-store in the elytron subsystem that specifies the location of the keystore and the password by which it is encrypted. This command assumes the keystore was generated using the keytool command and its type is JKS . Create a key-store in the elytron subsystem that specifies the location of the truststore and the password by which it is encrypted. This command assumes the keystore was generated using the keytool command and its type is JKS . Create a key-manager in the elytron subsystem that specifies the previously defined LocalhostKeyStore keystore, the alias, and password of the key. Create a trust-manager in the elytron subsystem that specifies the key-store of the previously created truststore. Create a server-ssl-context in the elytron subsystem that references the previously defined key-manager , sets the trust-manager attribute, and enables client authentication. Update the https-listener to the newly created Elytron ssl-context . Reload the server. This results in the following elytron subsystem configuration in the server configuration file. <subsystem xmlns="urn:wildfly:elytron:4.0"...> ... <tls> <key-stores> <key-store name="LocalhostKeyStore"> <credential-reference clear-text="keystore_password"/> <implementation type="JKS"/> <file path="server.keystore" relative-to="jboss.server.config.dir"/> </key-store> <key-store name="TrustStore"> <credential-reference clear-text="truststore_password"/> <implementation type="JKS"/> <file path="server.truststore" relative-to="jboss.server.config.dir"/> </key-store> </key-stores> <key-managers> <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore" alias-filter="server"> <credential-reference clear-text="key_password"/> </key-manager> </key-managers> <trust-managers> <trust-manager name="TrustManager" key-store="TrustStore"/> </trust-managers> <server-ssl-contexts> <server-ssl-context name="LocalhostSslContext" need-client-auth="true" key-manager="LocalhostKeyManager" trust-manager="TrustManager"/> </server-ssl-contexts> </tls> </subsystem> This results in the following undertow subsystem configuration in the server configuration file. <subsystem xmlns="urn:jboss:domain:undertow:14.0"> ... <https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/> ... </subsystem> 9.5.1.2. Security Realms and Domains The security realm is used in two situations: When certificate authentication fails, the security realm is used in password fallback case. When authorization is done for password as well as certificate, the realm provides the roles of individual users. To allow using the predefined Elytron ManagementDomain security domain and ManagementRealm security realm, users are stored in standard properties files. <security-domains> <security-domain name="ManagementDomain" default-realm="ManagementRealm" permission-mapper="default-permission-mapper"> <realm name="ManagementRealm" role-decoder="groups-to-roles"/> <realm name="local"/> </security-domain> </security-domains> <security-realms> <properties-realm name="ManagementRealm"> <users-properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ManagementRealm"/> <groups-properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/> </properties-realm> </security-realms> Thus, for any client certificate, a user must exist in the security realm. 9.5.1.3. Principal Decoder When certificate authentication is used and the security realm accepts user names to resolve an identity, there has to be a defined way to obtain the username from a client certificate. In this case the CN attribute is used in the certificate subject. 9.5.1.4. HTTP Authentication Factory For the HTTP connections, an HTTP authentication factory is defined, using the previously defined resources. It is configured to support CLIENT_CERT and DIGEST authentication. Since a properties realm only verifies passwords and is not able to verify client certificates, you need to first add a configuring mechanism factory. This disables certificate verification against the security realm. The HTTP authentication can be created as: The above command results in: <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> ... <http> ... <http-authentication-factory name="client-cert-digest" http-server-mechanism-factory="configured-cert" security-domain="ManagementDomain"> <mechanism-configuration> <mechanism mechanism-name="CLIENT_CERT" pre-realm-principal-transformer="x500-decoder"/> <mechanism mechanism-name="DIGEST"> <mechanism-realm realm-name="ManagementRealm"/> </mechanism> </mechanism-configuration> </http-authentication-factory> ... <configurable-http-server-mechanism-factory name="configured-cert" http-server-mechanism-factory="configured-cert"> <properties> <property name="org.wildfly.security.http.skip-certificate-verification" value="true"/> </properties> </configurable-http-server-mechanism-factory> ... </http> ... </subsystem> 9.6. Legacy security behavior changes in LDAP With Red Hat JBoss Enterprise Application Platform 8.0, there are significant changes to LDAP. These changes include HTTP status change for unreachable LDAP realms, enabling LDAP security realm for role parsing from a DN, and changes in sending the JBoss EAP SSL certificate to an LDAP server. In JBoss EAP 8.0, which utilizes the Elytron subsystem, a "500 Internal Error" is returned when an LDAP realm is unreachable, indicating a HTTP status change for unreachable realms. In JBoss EAP 8.0, you can enable the LDAP security realm to parse roles from a DN. By loading information from LDAP as attributes associated with the identity, these attributes can subsequently be mapped to roles using the attribute-mapping element. Example configuration <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true"> <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org"> <attribute-mapping> <attribute from="dn" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> </attribute-mapping> </identity-mapping> </ldap-realm> In JBoss EAP 8.0, you have the option to configure the outbound LDAP connection to utilize two-way or mutual TLS for sending the JBoss EAP SSL certificate to an LDAP server. For more information, see Enabling two-way SSL/TLS for management interfaces and applications .

Commands:
EAP_HOME /bin/elytron-tool.sh vault VAULT_ARGUMENTS
EAP_HOME /bin/elytron-tool.sh vault --help
EAP_HOME /bin/elytron-tool.sh vault --enc-dir vault_data/ --keystore vault-jceks.keystore --keystore-password MASK-2hKo56F1a3jYGnJwhPmiF5 --iteration 34 --salt 12345678 --alias test --location cs-v1.store --summary
Vault (enc-dir="vault_data/";keystore="vault-jceks.keystore") converted to credential store "cs-v1.store" Vault Conversion summary: -------------------------------------- Vault Conversion Successful CLI command to add new credential store: /subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="cs-v1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
keystore:vault-v1/vault-jceks.keystore keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5 enc-dir:vault-v1/vault_data/ salt:12345678 iteration:34 location:v1-cs-1.store alias:test keystore:vault-v1/vault-jceks.keystore keystore-password:secretsecret enc-dir:vault-v1/vault_data/ location:v1-cs-2.store alias:test different vault vault-v1-more keystore:vault-v1-more/vault-jceks.keystore keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5 enc-dir:vault-v1-more/vault_data/ salt:12345678 iteration:34 location:v1-cs-more.store alias:test
EAP_HOME /bin/elytron-tool.sh vault --bulk-convert path/to/ bulk-vault-conversion-descriptor.txt --summary
Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-1.store" Vault Conversion summary: -------------------------------------- Vault Conversion Successful CLI command to add new credential store: /subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"}) -------------------------------------- Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-2.store" Vault Conversion summary: -------------------------------------- Vault Conversion Successful CLI command to add new credential store: /subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-2.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="secretsecret"}) -------------------------------------- Vault (enc-dir="vault-v1-more/vault_data/";keystore="vault-v1-more/vault-jceks.keystore") converted to credential store "v1-cs-more.store" Vault Conversion summary: -------------------------------------- Vault Conversion Successful CLI command to add new credential store: /subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-more.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"}) --------------------------------------
<subsystem xmlns="urn:jboss:domain:security:2.0"> <security-properties> <property name="group.name" value="engineering-group" /> <property name="encoding.algorithm" value="BASE64" /> </security-properties> </subsystem>
/subsystem=elytron:write-attribute(name=security-properties, value={ group.name = "engineering-group", encoding.algorithm = "BASE64" })
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <security-properties> <security-property name="group.name" value="engineering-group"/> <security-property name="encoding.algorithm" value="BASE64"/> </security-properties> </subsystem>
/subsystem=elytron:map-put(name=security-properties, key=group.name, value=technical-support)
/subsystem=elytron:map-remove(name=security-properties, key=group.name)
/subsystem=security/security-domain=application-security:add /subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=UsersRoles, flag=Required, module-options={usersProperties=file://USD{jboss.server.config.dir}/example-users.properties, rolesProperties=file://USD{jboss.server.config.dir}/example-roles.properties}}])
<security-domain name="application-security"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="usersProperties" value="file://USD{jboss.server.config.dir}/example-users.properties"/> <module-option name="rolesProperties" value="file://USD{jboss.server.config.dir}/example-roles.properties"/> </login-module> </authentication> </security-domain>
/subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"}, groups-properties={path=example-roles.properties, relative-to=jboss.server.config.dir}, groups-attribute=Roles)
/subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-properties}], default-realm=application-properties, permission-mapper=default-permission-mapper)
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <security-domains> <security-domain name="application-security" default-realm="application-properties" permission-mapper="default-permission-mapper"> <realm name="application-properties"/> </security-domain> </security-domains> <security-realms> <properties-realm name="application-properties" groups-attribute="Roles"> <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/> <groups-properties path="example-roles.properties" relative-to="jboss.server.config.dir"/> </properties-realm> </security-realms> </subsystem>
/subsystem=undertow/application-security-domain=application-security:add(security-domain=application-security)
<subsystem xmlns="urn:jboss:domain:undertow:12.0"> <application-security-domains> <application-security-domain name="application-security" security-domain="application-security"/> </application-security-domains> </subsystem>
/core-service=management/security-realm=ApplicationSecurity:add /core-service=management/security-realm=ApplicationSecurity/authentication=properties:add(relative-to=jboss.server.config.dir, path=example-users.properties, plain-text=true) /core-service=management/security-realm=ApplicationSecurity/authorization=properties:add(relative-to=jboss.server.config.dir, path=example-roles.properties)
<security-realm name="ApplicationSecurity"> <authentication> <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/> </authentication> <authorization> <properties path="example-roles.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm>
/subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"}, groups-properties={path=example-roles.properties, relative-to=jboss.server.config.dir}, groups-attribute=Roles)
/subsystem=elytron/security-domain=application-security:add(realms=[{realm=application-properties}], default-realm=application-properties, permission-mapper=default-permission-mapper)
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <security-domains> <security-domain name="application-security" default-realm="application-properties" permission-mapper="default-permission-mapper"> <realm name="application-properties"/> </security-domain> </security-domains> <security-realms> <properties-realm name="application-properties" groups-attribute="Roles"> <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/> <groups-properties path="example-roles.properties" relative-to="jboss.server.config.dir"/> </properties-realm> </security-realms> </subsystem>
/subsystem=elytron/sasl-authentication-factory=application-security-sasl:add(sasl-server-factory=elytron, security-domain=application-security, mechanism-configurations=[{mechanism-name=PLAIN}])
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <sasl> <sasl-authentication-factory name="application-security-sasl" sasl-server-factory="elytron" security-domain="application-security"> <mechanism-configuration> <mechanism mechanism-name="PLAIN"/> </mechanism-configuration> </sasl-authentication-factory> </sasl> </subsystem>
/subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=sasl-authentication-factory, value=application-security-sasl)
<subsystem xmlns="urn:jboss:domain:remoting:4.0"> <http-connector name="http-remoting-connector" connector-ref="default" sasl-authentication-factory="application-security-sasl"/> </subsystem>
/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}]) /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-security-sasl)
<management-interfaces> <http-interface http-authentication-factory="application-security-http"> <http-upgrade enabled="true" sasl-authentication-factory="application-security-sasl"/> <socket-binding http="management-http"/> </http-interface> </management-interfaces>
example-users.properties example-roles.properties
USD./bin/elytron-tool.sh filesystem-realm --users-file example-users.properties --roles-file example-roles.properties --output-location realms/example
users-1.properties users-2.properties roles-1.properties roles-2.properties
users-file:/full/path/to/users-1.properties roles-file:/full/path/to/roles-1.properties output-location:./realms/bulk-1-example filesystem-realm-name:exampleFileSystemRealm1 security-domain-name:exampleSecurityDomain1 users-file:/full/path/to/users-2.properties roles-file:/full/path/to/roles-2.properties output-location:./realms/bulk-2-example filesystem-realm-name:exampleFileSystemRealm2 security-domain-name:exampleSecurityDomain2
USD./bin/elytron-tool.sh filesystem-realm --bulk-convert example-descriptor-file
/subsystem=elytron/filesystem-realm=converted-properties-filesystem-realm:add(path=/full/path/to/realms/example) /subsystem=elytron/security-domain=converted-properties-security-domain:add(realms=[{realm=converted-properties-filesystem-realm}],default-realm=converted-properties-filesystem-realm,permission-mapper=default-permission-mapper)
dn: uid=TestUserOne,ou=users,dc=group-to-principal,dc=wildfly,dc=org objectClass: top objectClass: inetOrgPerson objectClass: uidObject objectClass: person objectClass: organizationalPerson cn: Test User One sn: Test User One uid: TestUserOne userPassword: {SSHA}UG8ov2rnrnBKakcARVvraZHqTa7mFWJZlWt2HA==
dn: uid=GroupOne,ou=groups,dc=group-to-principal,dc=wildfly,dc=org objectClass: top objectClass: groupOfUniqueNames objectClass: uidObject cn: Group One uid: GroupOne uniqueMember: uid=TestUserOne,ou=users,dc=group-to-principal,dc=wildfly,dc=org
batch /core-service=management/ldap-connection=MyLdapConnection:add(url="ldap://localhost:10389", search-dn="uid=admin,ou=system", search-credential="secret") /core-service=management/security-realm=LDAPRealm:add /core-service=management/security-realm=LDAPRealm/authentication=ldap:add(connection="MyLdapConnection", username-attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org") /core-service=management/security-realm=LDAPRealm/authorization=ldap:add(connection=MyLdapConnection) /core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add(attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org") /core-service=management/security-realm=LDAPRealm/authorization=ldap/group-search=group-to-principal:add(base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", iterative=true, prefer-original-connection=true, principal-attribute=uniqueMember, search-by=DISTINGUISHED_NAME, group-name=SIMPLE, group-name-attribute=uid) run-batch
<management> <security-realms> <security-realm name="LDAPRealm"> <authentication> <ldap connection="MyLdapConnection" base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org"> <username-filter attribute="uid"/> </ldap> </authentication> <authorization> <ldap connection="MyLdapConnection"> <username-to-dn> <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/> </username-to-dn> <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid"> <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true"> <membership-filter principal-attribute="uniqueMember"/> </group-to-principal> </group-search> </ldap> </authorization> </security-realm> </security-realms> <outbound-connections> <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/> </outbound-connections> </management>
/subsystem=security/security-domain=application-security:add /subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=LdapExtended, flag=Required, module-options={ java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])
<subsystem xmlns="urn:jboss:domain:security:2.0"> <security-domains> <security-domain name="application-security"> <authentication> <login-module code="LdapExtended" flag="required"> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/> <module-option name="java.naming.security.authentication" value="simple"/> <module-option name="bindDN" value="uid=admin,ou=system"/> <module-option name="bindCredential" value="secret"/> <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="baseFilter" value="(uid={0})"/> <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="roleFilter" value="(uniqueMember={1})"/> <module-option name="roleAttributeID" value="uid"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem>
/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin, ou=system", credential-reference={clear-text=secret})
/subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users, dc=group-to-principal, dc=wildfly, dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups, dc=group-to-principal, dc=wildfly, dc=org", filter="(uniqueMember={1})", from="uid", to="Roles"}]})
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <security-realms> <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true"> <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org"> <attribute-mapping> <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> </attribute-mapping> </identity-mapping> </ldap-realm> </security-realms> <dir-contexts> <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system"> <credential-reference clear-text="secret"/> </dir-context> </dir-contexts> </subsystem>
CREATE TABLE User ( id BIGINT NOT NULL, username VARCHAR(255), password VARCHAR(255), role ENUM('admin', 'manager', 'user'), PRIMARY KEY (id), UNIQUE (username) )
/subsystem=security/security-domain=application-security:add /subsystem=security/security-domain=application-security/authentication=classic:add( login-modules=[ { code=Database, flag=Required, module-options={ dsJndiName="java:jboss/datasources/ExampleDS", principalsQuery="SELECT password FROM User WHERE username = ?", rolesQuery="SELECT role, 'Roles' FROM User WHERE username = ?", hashAlgorithm=MD5, hashEncoding=base64 } } ] )
<subsystem xmlns="urn:jboss:domain:security:2.0"> <security-domains> <security-domain name="application-security"> <authentication> <login-module code="Database" flag="required"> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/> <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/> <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/> <module-option name="hashAlgorithm" value="MD5"/> <module-option name="hashEncoding" value="base64"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem>
/subsystem=elytron/jdbc-realm=jdbc-realm:add(principal-query=[ { data-source=ExampleDS, sql="SELECT role, password FROM User WHERE username = ?", attribute-mapping=[{index=1, to=Roles } ] simple-digest-mapper={algorithm=simple-digest-md5, password-index=2} } ] )
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <security-realms> <jdbc-realm name="jdbc-realm"> <principal-query sql="SELECT role, password FROM User WHERE username = ?" data-source="ExampleDS"> <attribute-mapping> <attribute to="Roles" index="1"/> </attribute-mapping> <simple-digest-mapper password-index="2"/> </principal-query> </jdbc-realm> </security-realms> </subsystem>
Enable debugging /system-property=sun.security.krb5.debug:add(value=true) Identify the Kerberos realm to use /system-property=java.security.krb5.realm:add(value=ELYTRON.ORG) Identify the address of the KDC /system-property=java.security.krb5.kdc:add(value=kdc.elytron.org)
<system-properties> <property name="sun.security.krb5.debug" value="true"/> <property name="java.security.krb5.realm" value="ELYTRON.ORG"/> <property name="java.security.krb5.kdc" value="kdc.elytron.org"/> </system-properties>
/core-service=management/security-realm=Kerberos:add /core-service=management/security-realm=Kerberos/server-identity=kerberos:add /core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=HTTP\/test-server.elytron.org@ELYTRON.ORG:add(path= /path/to/ test-server.keytab, debug=true) /core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)
<security-realms> <security-realm name="Kerberos"> <server-identities> <kerberos> <keytab principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path=" /path/to/ test-server.keytab" debug="true"/> </kerberos> </server-identities> <authentication> <kerberos remove-realm="true"/> </authentication> </security-realm> </security-realms>
Define the first security domain /subsystem=security/security-domain=host:add /subsystem=security/security-domain=host/authentication=classic:add /subsystem=security/security-domain=host/authentication=classic/login-module=1:add(code=Kerberos, flag=Required, module-options={storeKey=true, useKeyTab=true, principal=HTTP/test-server.elytron.org@ELYTRON.ORG, keyTab= path/to/ test-server.keytab, debug=true} Define the second SPNEGO security domain /subsystem=security/security-domain=SPNEGO:add /subsystem=security/security-domain=SPNEGO/authentication=classic:add /subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:add(code=SPNEGO, flag=requisite, module-options={password-stacking=useFirstPass, serverSecurityDomain=host}) /subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:write-attribute(name=module, value=org.jboss.security.negotiation) /subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=2:add(code=UsersRoles, flag=required, module-options={password-stacking=useFirstPass, usersProperties= /path/to/ kerberos/spnego-users.properties, rolesProperties= /path/to/ kerberos/spnego-roles.properties, defaultUsersProperties= /path/to/ kerberos/spnego-users.properties, defaultRolesProperties= /path/to/ kerberos/spnego-roles.properties})
<subsystem xmlns="urn:jboss:domain:security:2.0"> <security-domains> <security-domain name="host"> <authentication> <login-module name="1" code="Kerberos" flag="required"> <module-option name="storeKey" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="principal" value="HTTP/test-server.elytron.org@ELYTRON.ORG"/> <module-option name="keyTab" value=" /path/to/ test-server.keytab"/> <module-option name="debug" value="true"/> </login-module> </authentication> </security-domain> <security-domain name="SPNEGO"> <authentication> <login-module name="1" code="SPNEGO" flag="requisite" module="org.jboss.security.negotiation"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="serverSecurityDomain" value="host"/> </login-module> <login-module name="2" code="UsersRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value=" path/to /kerberos/spnego-users.properties"/> <module-option name="rolesProperties" value=" / path/to / kerberos/spnego-roles.properties"/> <module-option name="defaultUsersProperties" value=" / path/to / kerberos/spnego-users.properties"/> <module-option name="defaultRolesProperties" value=" / path/to / kerberos/spnego-roles.properties"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem>
/subsystem=elytron/properties-realm=spnego-properties:add(users-properties={path= path/to/ spnego-users.properties, plain-text=true, digest-realm-name=ELYTRON.ORG}, groups-properties={path= path/to/ spnego-roles.properties})
/subsystem=elytron/kerberos-security-factory=test-server:add(path= path/to/ test-server.keytab, principal=HTTP/test-server.elytron.org@ELYTRON.ORG, debug=true)
/subsystem=elytron/security-domain=SPNEGODomain:add(default-realm=spnego-properties, realms=[{realm=spnego-properties, role-decoder=groups-to-roles}], permission-mapper=default-permission-mapper) /subsystem=elytron/http-authentication-factory=spnego-http-authentication:add(security-domain=SPNEGODomain, http-server-mechanism-factory=global,mechanism-configurations=[{mechanism-name=SPNEGO, credential-security-factory=test-server}])
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <security-domains> <security-domain name="SPNEGODomain" default-realm="spnego-properties" permission-mapper="default-permission-mapper"> <realm name="spnego-properties" role-decoder="groups-to-roles"/> </security-domain> </security-domains> <security-realms> <properties-realm name="spnego-properties"> <users-properties path=" path/to/ spnego-users.properties" digest-realm-name="ELYTRON.ORG" plain-text="true"/> <groups-properties path=" path/to/ spnego-roles.properties"/> </properties-realm> </security-realms> <credential-security-factories> <kerberos-security-factory name="test-server" principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path=" path/to/ test-server.keytab" debug="true"/> </credential-security-factories> <http> <http-authentication-factory name="spnego-http-authentication" http-server-mechanism-factory="global" security-domain="SPNEGODomain"> <mechanism-configuration> <mechanism mechanism-name="SPNEGO" credential-security-factory="test-server"/> </mechanism-configuration> </http-authentication-factory> </http> </subsystem>
/core-service=management/security-realm=Kerberos:add /core-service=management/security-realm=Kerberos/server-identity=kerberos:add /core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=remote\/test-server.elytron.org@ELYTRON.ORG:add(path= path/to /remote-test-server.keytab, debug=true) /core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)
<management> <security-realms> <security-realm name="Kerberos"> <server-identities> <kerberos> <keytab principal="remote/test-server.elytron.org@ELYTRON.ORG" path=" path/to /remote-test-server.keytab" debug="true"/> </kerberos> </server-identities> <authentication> <kerberos remove-realm="true"/> </authentication> </security-realm> </security-realms> </management>
/path=kerberos:add(relative-to=user.home, path=src/kerberos) /subsystem=elytron/properties-realm=kerberos-properties:add(users-properties={path=kerberos-users.properties, relative-to=kerberos, digest-realm-name=ELYTRON.ORG}, groups-properties={path=kerberos-groups.properties, relative-to=kerberos})
/subsystem=elytron/kerberos-security-factory=test-server:add(relative-to=kerberos, path=remote-test-server.keytab, principal=remote/test-server.elytron.org@ELYTRON.ORG)
/subsystem=elytron/security-domain=KerberosDomain:add(default-realm=kerberos-properties, realms=[{realm=kerberos-properties, role-decoder=groups-to-roles}], permission-mapper=default-permission-mapper) /subsystem=elytron/sasl-authentication-factory=gssapi-authentication-factory:add(security-domain=KerberosDomain, sasl-server-factory=elytron, mechanism-configurations=[{mechanism-name=GSSAPI, credential-security-factory=test-server}])
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <security-domains> <security-domain name="KerberosDomain" default-realm="kerberos-properties" permission-mapper="default-permission-mapper"> <realm name="kerberos-properties" role-decoder="groups-to-roles"/> </security-domain> </security-domains> <security-realms> <properties-realm name="kerberos-properties"> <users-properties path="kerberos-users.properties" relative-to="kerberos" digest-realm-name="ELYTRON.ORG"/> <groups-properties path="kerberos-groups.properties" relative-to="kerberos"/> </properties-realm> </security-realms> <credential-security-factories> <kerberos-security-factory name="test-server" principal="remote/test-server.elytron.org@ELYTRON.ORG" path="remote-test-server.keytab" relative-to="kerberos"/> </credential-security-factories> <sasl> <sasl-authentication-factory name="gssapi-authentication-factory" sasl-server-factory="elytron" security-domain="KerberosDomain"> <mechanism-configuration> <mechanism mechanism-name="GSSAPI" credential-security-factory="test-server"/> </mechanism-configuration> </sasl-authentication-factory> </sasl> </subsystem>
/subsystem=security/security-domain=application-security:add /subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[ {code=UsersRoles, flag=Required, module-options={ password-stacking=useFirstPass, usersProperties=file://USD{jboss.server.config.dir}/example-users.properties}} {code=LdapExtended, flag=Required, module-options={ password-stacking=useFirstPass, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])
<security-domain name="application-security"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value="file://USD{jboss.server.config.dir}/example-users.properties"/> </login-module> <login-module code="LdapExtended" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/> <module-option name="java.naming.security.authentication" value="simple"/> <module-option name="bindDN" value="uid=admin,ou=system"/> <module-option name="bindCredential" value="secret"/> <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="baseFilter" value="(uid={0})"/> <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="roleFilter" value="(uniqueMember={1})"/> <module-option name="roleAttributeID" value="uid"/> </login-module> </authentication> </security-domain>
/core-service=management/ldap-connection=MyLdapConnection:add(url="ldap://localhost:10389", search-dn="uid=admin,ou=system", search-credential="secret") /core-service=management/security-realm=ApplicationSecurity:add /core-service=management/security-realm=ApplicationSecurity/authentication=properties:add(path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true) batch /core-service=management/security-realm=ApplicationSecurity/authorization=ldap:add(connection=MyLdapConnection) /core-service=management/security-realm=ApplicationSecurity/authorization=ldap/username-to-dn=username-filter:add(attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org") /core-service=management/security-realm=ApplicationSecurity/authorization=ldap/group-search=group-to-principal:add(base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", iterative=true, prefer-original-connection=true, principal-attribute=uniqueMember, search-by=DISTINGUISHED_NAME, group-name=SIMPLE, group-name-attribute=uid) run-batch
<security-realms> <security-realm name="ApplicationSecurity"> <authentication> <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/> </authentication> <authorization> <ldap connection="MyLdapConnection"> <username-to-dn> <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/> </username-to-dn> <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid"> <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true"> <membership-filter principal-attribute="uniqueMember"/> </group-to-principal> </group-search> </ldap> </authorization> </security-realm> </security-realms> <outbound-connections> <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/> </outbound-connections>
/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin,ou=system", credential-reference={clear-text=secret}) /subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",filter="(uniqueMember={1})",from="uid",to="Roles"}]}) /subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"}) /subsystem=elytron/aggregate-realm=combined-realm:add(authentication-realm=application-properties, authorization-realm=ldap-realm) /subsystem=elytron/security-domain=application-security:add(realms=[{realm=combined-realm}], default-realm=combined-realm, permission-mapper=default-permission-mapper) /subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}])
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <security-domains> <security-domain name="application-security" default-realm="combined-realm" permission-mapper="default-permission-mapper"> <realm name="combined-realm"/> </security-domain> </security-domains> <security-realms> <aggregate-realm name="combined-realm" authentication-realm="application-properties" authorization-realm="ldap-realm"/> <properties-realm name="application-properties"> <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/> </properties-realm> <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true"> <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org"> <attribute-mapping> <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> </attribute-mapping> </identity-mapping> </ldap-realm> </security-realms> <http> <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security"> <mechanism-configuration> <mechanism mechanism-name="BASIC"/> </mechanism-configuration> </http-authentication-factory> </http> <dir-contexts> <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system"> <credential-reference clear-text="secret"/> </dir-context> </dir-contexts> </subsystem>
/subsystem=security/security-domain=application-security:add(cache-type=default) /subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=LdapExtended, flag=Required, module-options={ java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])
<subsystem xmlns="urn:jboss:domain:security:2.0"> <security-domains> <security-domain name="application-security" cache-type="default"> <authentication> <login-module code="LdapExtended" flag="required"> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/> <module-option name="java.naming.security.authentication" value="simple"/> <module-option name="bindDN" value="uid=admin,ou=system"/> <module-option name="bindCredential" value="secret"/> <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="baseFilter" value="(uid={0})"/> <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> <module-option name="roleFilter" value="(uniqueMember={1})"/> <module-option name="roleAttributeID" value="uid"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem>
/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin,ou=system", credential-reference={clear-text=secret}) /subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",filter="(uniqueMember={1})",from="uid",to="Roles"}]}) /subsystem=elytron/caching-realm=cached-ldap:add(realm=ldap-realm)
/subsystem=elytron/security-domain=application-security:add(realms=[{realm=cached-ldap}], default-realm=cached-ldap, permission-mapper=default-permission-mapper) /subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}])
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <security-domains> <security-domain name="application-security" default-realm="cached-ldap" permission-mapper="default-permission-mapper"> <realm name="cached-ldap"/> </security-domain> </security-domains> <security-realms> . <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true"> <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org"> <attribute-mapping> <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> </attribute-mapping> </identity-mapping> </ldap-realm> <caching-realm name="cached-ldap" realm="ldap-realm"/> </security-realms> <http> <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security"> <mechanism-configuration> <mechanism mechanism-name="BASIC"/> </mechanism-configuration> </http-authentication-factory> </http> <dir-contexts> <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system"> <credential-reference clear-text="secret"/> </dir-context> </dir-contexts>
Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory"); properties.put(Context.PROVIDER_URL,"http-remoting://127.0.0.1:8080"); properties.put(Context.SECURITY_PRINCIPAL, "bob"); properties.put(Context.SECURITY_CREDENTIALS, "secret"); InitialContext context = new InitialContext(properties); Bar bar = (Bar) context.lookup("foo/bar");
<configuration> <authentication-client xmlns="urn:elytron:client:1.7"> <authentication-rules> <rule use-configuration="namingConfig"> <match-host name="127.0.0.1"/> </rule> </authentication-rules> <authentication-configurations> <configuration name="namingConfig"> <set-user-name name="bob"/> <credentials> <clear-password password="secret"/> </credentials> </configuration> </authentication-configurations> </authentication-client> </configuration>
Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory"); properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080"); InitialContext context = new InitialContext(properties); Bar bar = (Bar) context.lookup("foo/bar");
// Create the authentication configuration AuthenticationConfiguration namingConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret"); // Create the authentication context AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), namingConfig); // Create a callable that creates and uses an InitialContext Callable<Void> callable = () -> { Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory"); properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080"); InitialContext context = new InitialContext(properties); Bar bar = (Bar) context.lookup("foo/bar"); return null; }; // Use the authentication context to run the callable context.runCallable(callable);
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false remote.connections=default remote.connection.default.host=127.0.0.1 remote.connection.default.port = 8080 remote.connection.default.username=bob remote.connection.default.password=secret
// Create an InitialContext Properties properties = new Properties(); properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); InitialContext context = new InitialContext(properties); // Look up the Jakarta Enterprise Beans and invoke one of its methods RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup( "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName()); int sum = statelessRemoteCalculator.add(101, 202);
<configuration> <authentication-client xmlns="urn:elytron:client:1.7"> <authentication-rules> <rule use-configuration="ejbConfig"> <match-host name="127.0.0.1"/> </rule> </authentication-rules> <authentication-configurations> <configuration name="ejbConfig"> <set-user-name name="bob"/> <credentials> <clear-password password="secret"/> </credentials> </configuration> </authentication-configurations> </authentication-client> <jboss-ejb-client xmlns="urn:jboss:wildfly-client-ejb:3.0"> <connections> <connection uri="remote+http://127.0.0.1:8080" /> </connections> </jboss-ejb-client> </configuration>
// Create an InitialContext Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory"); InitialContext context = new InitialContext(properties); // Look up an Jakarta Enterprise Beans and invoke one of its methods // Note that this code is the same as before RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup( "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName()); int sum = statelessRemoteCalculator.add(101, 202);----
// Create the authentication configuration AuthenticationConfiguration ejbConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret"); // Create the authentication context AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), ejbConfig); // Create a callable that invokes the Jakarta Enterprise Beans Callable<Void> callable = () -> { // Create an InitialContext Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory"); properties.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080"); InitialContext context = new InitialContext(properties); // Look up the Jakarta Enterprise Beans and invoke one of its methods // Note that this code is the same as before RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup( "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName()); int sum = statelessRemoteCalculator.add(101, 202); return null; }; // Use the authentication context to run the callable context.runCallable(callable);
<security-realm name="ApplicationRealm"> <server-identities> <ssl> <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" /> </ssl> </server-identities> </security-realm>
/subsystem=elytron/key-store=LocalhostKeyStore:add(path=server.keystore,relative-to=jboss.server.config.dir,credential-reference={clear-text="keystore_password"},type=JKS)
/subsystem=elytron/key-manager=LocalhostKeyManager:add(key-store=LocalhostKeyStore,alias-filter=server,credential-reference={clear-text="key_password"})
/subsystem=elytron/server-ssl-context=LocalhostSslContext:add(key-manager=LocalhostKeyManager)
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=LocalhostSslContext) run-batch
reload
<subsystem xmlns="urn:wildfly:elytron:4.0" ...> <tls> <key-stores> <key-store name="LocalhostKeyStore"> <credential-reference clear-text="keystore_password"/> <implementation type="JKS"/> <file path="server.keystore" relative-to="jboss.server.config.dir"/> </key-store> </key-stores> <key-managers> <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore" alias-filter="server"> <credential-reference clear-text="key_password"/> </key-manager> </key-managers> <server-ssl-contexts> <server-ssl-context name="LocalhostSslContext" key-manager="LocalhostKeyManager"/> </server-ssl-contexts> </tls> </subsystem>
<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>
<security-realm name="ManagementRealm"> <server-identities> <ssl> <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password=" KEYSTORE_PASSWORD " alias="server" key-password="key_password" /> </ssl> </server-identities> <authentication> <truststore path="server.truststore" relative-to="jboss.server.config.dir" keystore-password=" TRUSTSTORE_PASSWORD " /> <local default-user="USDlocal"/> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/> </authentication> </security-realm>
/subsystem=elytron/key-store=LocalhostKeyStore:add(path=server.keystore,relative-to=jboss.server.config.dir,credential-reference={clear-text="keystore_password"},type=JKS)
/subsystem=elytron/key-store=TrustStore:add(path=server.truststore,relative-to=jboss.server.config.dir,credential-reference={clear-text="truststore_password"},type=JKS)
/subsystem=elytron/key-manager=LocalhostKeyManager:add(key-store=LocalhostKeyStore,alias-filter=server,credential-reference={clear-text="key_password"})
/subsystem=elytron/trust-manager=TrustManager:add(key-store=TrustStore)
/subsystem=elytron/server-ssl-context=LocalhostSslContext:add(key-manager=LocalhostKeyManager,trust-manager=TrustManager,need-client-auth=true)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=LocalhostSslContext)
reload
<subsystem xmlns="urn:wildfly:elytron:4.0"...> <tls> <key-stores> <key-store name="LocalhostKeyStore"> <credential-reference clear-text="keystore_password"/> <implementation type="JKS"/> <file path="server.keystore" relative-to="jboss.server.config.dir"/> </key-store> <key-store name="TrustStore"> <credential-reference clear-text="truststore_password"/> <implementation type="JKS"/> <file path="server.truststore" relative-to="jboss.server.config.dir"/> </key-store> </key-stores> <key-managers> <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore" alias-filter="server"> <credential-reference clear-text="key_password"/> </key-manager> </key-managers> <trust-managers> <trust-manager name="TrustManager" key-store="TrustStore"/> </trust-managers> <server-ssl-contexts> <server-ssl-context name="LocalhostSslContext" need-client-auth="true" key-manager="LocalhostKeyManager" trust-manager="TrustManager"/> </server-ssl-contexts> </tls> </subsystem>
<subsystem xmlns="urn:jboss:domain:undertow:14.0"> <https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/> </subsystem>
<security-domains> <security-domain name="ManagementDomain" default-realm="ManagementRealm" permission-mapper="default-permission-mapper"> <realm name="ManagementRealm" role-decoder="groups-to-roles"/> <realm name="local"/> </security-domain> </security-domains> <security-realms> <properties-realm name="ManagementRealm"> <users-properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ManagementRealm"/> <groups-properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/> </properties-realm> </security-realms>
/subsystem=elytron/x500-attribute-principal-decoder=x500-decoder:add(attribute-name=CN)
/subsystem=elytron/configurable-http-server-mechanism-factory=configured-cert:add(http-server-mechanism-factory=global, properties={org.wildfly.security.http.skip-certificate-verification=true})
./subsystem=elytron/http-authentication-factory=client-cert-digest:add(http-server-mechanism-factory=configured-cert,security-domain=ManagementDomain,mechanism-configurations=[{mechanism-name=CLIENT_CERT,pre-realm-principal-transformer=x500-decoder},{mechanism-name=DIGEST, mechanism-realm-configurations=[{realm-name=ManagementRealm}]}])
<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <http> <http-authentication-factory name="client-cert-digest" http-server-mechanism-factory="configured-cert" security-domain="ManagementDomain"> <mechanism-configuration> <mechanism mechanism-name="CLIENT_CERT" pre-realm-principal-transformer="x500-decoder"/> <mechanism mechanism-name="DIGEST"> <mechanism-realm realm-name="ManagementRealm"/> </mechanism> </mechanism-configuration> </http-authentication-factory> <configurable-http-server-mechanism-factory name="configured-cert" http-server-mechanism-factory="configured-cert"> <properties> <property name="org.wildfly.security.http.skip-certificate-verification" value="true"/> </properties> </configurable-http-server-mechanism-factory> </http> </subsystem>
<ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true"> <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org"> <attribute-mapping> <attribute from="dn" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/> </attribute-mapping> </identity-mapping> </ldap-realm>