As a middleware application server, Red Hat JBoss Enterprise Application Platform (JBoss EAP) provides a number of security related features, such as:

Refer to the references section to learn about these concepts.

There are three types of assets protected by the security components in JBoss EAP:

The core principle behind the design of the security is to avoid embedding the logic for authentication and authorization inside the applications. This declarative approach captures the implementation details inside reusable components that can then be referenced by the applications and subsystems at runtime. For example, you can change the authentication and authorization mechanism for an application from using a database to using an LDAP server without making any source code changes in the application.

Between JBoss EAP 6 and JBoss EAP 7.1, there was only a security subsystem within the application server. Since JBoss EAP 7.1 a new elytron security subsystem is generally available to the JBoss EAP administrators and developers. The legacy security subsystem is implemented by using the PicketBox open source project, and the elytron security subsystem is implemented by using the Wildfly Elytron open source project. The management console depicts the two subsystems as follows:

Figure 9.1: Security subsystems in the management console

The JBoss EAP security implementation relies in two main components: security realms, and security domains. A security realm is an identity store that contains information to authenticate and authorize users, such as usernames, passwords, and group membership. A security domain is a set of declarative security configurations that the applications and subsystems use.

The use of security realms and security domains is different between the legacy and the elytron security subsystems.

In the elytron security subsystem the security domain can use one or more security realms. Thus, the same elytron security domain can use different sources of identity. JBoss EAP provides 13 types of elytron security realms, such as filesystem-realm, jdbc-realm, ldap-realm, or token-realm. Refer to the references section to learn more about the elytron realm types.

In the elytron security subsystem, the deployed applications can use one elytron security domain.

In the legacy security subsystem, security domains can contains information about connections to the identity store by using LoginModule components. There are many types of LoginModule components, such as the PropertiesUsers, the Database, the Kerberos, or the SPNEGO login modules. Refer to the references section to learn more about the existing login modules. In the legacy security subsystem, if the application needs to access different identity stores, then you must configure the application to use different security domains.

<server xmlns="urn:jboss:domain:16.0">
...output omitted...
<management>
  <security-realms>
         <security-realm name="ManagementRealm"> 
             <authentication>
...output omitted...
             </authentication>
             <authorization map-groups-to-roles="false">
...output omitted...
             </authorization>
         </security-realm>
         <security-realm name="ApplicationRealm"> 
             <server-identities>
...output omitted...
             </server-identities>
             <authentication>
...output omitted...
             </authentication>
             <authorization>
...output omitted...
             </authorization>
         </security-realm>
  </security-realms>
...output omitted...
</management>
<profile>
...output omitted...
   <subsystem xmlns="urn:wildfly:elytron:13.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
...output omitted...
     </security-domains>
     <security-realms>
...output omitted...
                <properties-realm name="ApplicationRealm"> 
...output omitted...
                </properties-realm>
                <properties-realm name="ManagementRealm"> 
...output omitted...
                </properties-realm>
      </security-realms>

<server xmlns="urn:jboss:domain:16.0">
...output omitted...
<profile>
...output omitted...
  <subsystem xmlns="urn:wildfly:elytron:13.0" ...
...output omitted...
   <security-domains>
      <security-domain name="ApplicationDomain" default-realm="ApplicationRealm" permission-mapper="default-permission-mapper">
          <realm name="ApplicationRealm" role-decoder="groups-to-roles"/>
          <realm name="local"/>
      </security-domain>
      <security-domain name="ManagementDomain" default-realm="ManagementRealm" permission-mapper="default-permission-mapper">
          <realm name="ManagementRealm" role-decoder="groups-to-roles"/>
          <realm name="local" role-mapper="super-user-mapper"/>
      </security-domain>
   </security-domains>
   <security-realms>
...output omitted...
  <subsystem xmlns="urn:jboss:domain:security:2.0">
   <security-domains>
   <security-domain name="other" cache-type="default">
      <authentication>
...output omitted...
   </security-domain>
   <security-domain name="jboss-web-policy" cache-type="default">
      <authorization>
...output omitted...
      </authorization>
   </security-domain>
   <security-domain name="jaspitest" cache-type="default">
...output omitted...
   <security-domain name="jboss-ejb-policy" cache-type="default">
...output omitted...
   </security-domain>
  </security-domains>
        </subsystem>

<subsystem xmlns="urn:jboss:domain:ejb3:9.0">
...output omitted...
    <default-security-domain value="other"/>
...output omitted...
 <subsystem xmlns="urn:jboss:domain:undertow:12.0"
...output omitted...
   default-security-domain="other" ...>

<subsystem xmlns="urn:jboss:domain:ejb3:9.0">
...output omitted...
    <default-security-domain value="ApplicationDomain"/>
...output omitted...
 <subsystem xmlns="urn:jboss:domain:undertow:12.0"
...output omitted...
    <default-security-domain="ApplicationDomain" ...>

By default, the role-based access control (RBAC) to the management interfaces is disabled. If you enable RBAC, then you can use the following provided roles: Monitor, Operator, Maintainer, Deployer, Auditor, Administrator, and SuperUser. Refer to the references section to learn more about JBoss EAP RBAC.

You can define a legacy security domain backed by a database by using the Database login module. The database stores the users and the role mappings for the applications. The security domain uses a datasource reference defined in the JBoss EAP configuration file, and defines queries for fetching the users and roles from the database. The recommended approach is to store passwords in an encrypted format by configuring the hashAlgorithm attribute.

A database security domain can be created with the management CLI by using the following command:

[standalone@localhost:9990] /subsystem=security/security-domain= \
 bksecurity-domain:add(cache-type=default)

The following command associates the security domain with a database for authentication purposes:

  [standalone@localhost:9990] /subsystem=security/security-domain= \
   db-domain/authentication=classic:add \
   (login-modules=[{"code"=>"Database", "flag"=>"required", \
   "module-options"=>[("dsJndiName"=>"java:jboss/datasources/test-ds"), \
   ("principalsQuery"=>"SELECT password FROM users WHERE username = ?"), \
   ("rolesQuery"=>"SELECT role, 'Roles' FROM roles WHERE username = ?"), \
   ("hashAlgorithm"=>"SHA-256"),("hashEncoding"=>"base64")]}])

The corresponding XML definition of the database security domain is as follows:

<security-domain name="db-domain" cache-type="default"> 
  <authentication>
    <login-module code="Database" flag="required"> 
      <module-option name="dsJndiName" 
            value="java:jboss/datasources/test-ds"/>
      <module-option name="principalsQuery"
            value="SELECT password FROM users WHERE username = ?"/>
      <module-option name="rolesQuery"
            value="SELECT role, 'Roles' FROM roles WHERE username = ?"/>
      <module-option name="hashAlgorithm" value="SHA-256"/> 
      <module-option name="hashEncoding" value="base64"/> 
    </login-module>
  </authentication>
</security-domain>

When a request is made to a JBoss EAP server that requires a user to be authenticated by using the db-domain, the following steps occur:

To learn how to configure a database security domain by using the elytron subsystem, refer to the references section.

To utilize a security domain, users must add a reference to the security domain in the jboss-web.xml file. The following is an example of the <security-domain> tag in the jboss-web.xml file:

<security-domain>Security_Domain_Name</security-domain>

If an application has no <security-domain> tag in the jboss-web.xml file, then the undertow web subsystem applies the security domain defined in the default-security-domain element of the undertow configuration.

The web.xml file allows users to configure the security of the application, by creating security restrictions to specific paths, restricting based on roles, and defining the authentication type.

In the <security-constraint> portion of the web.xml file is the <web-resource-collections> section, which allows users to define which URL path requires authorization. The <url-pattern> tag can contain any path on the server or simply use an * to secure all of the pages and resources. The <auth-constraint> within the same section specifies which roles are allowed to access the restricted aspects of the application.

...
<security-constraint>
    <web-resource-collection>
         <web-resource-name>All resources</web-resource-name>
         <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
         <role-name>*</role-name>
    </auth-constraint>
</security-constraint>
...

The <login-config> tag within the web.xml defines the type of authentication to be used. BASIC refers to an authentication requirement wherein the server requests a username and password from the web client, which is validated against the database. Defining these aspects of the web.xml is outside the scope of this course.

...
<login-config>
    <auth-method>BASIC</auth-method>
</login-config>