AD248 - ch09s09

Bookmark this page

Lab: Securing JBoss EAP

Secure an application, protect a datasource password with a vault, and secure a queue.

Resources
Files:	`/home/student/AD248/labs/security-review`
Application URL:	`http://172.25.250.10:8080/messaging-client-secure`

Outcomes

You should be able to secure a messaging client by using a legacy security domain, encrypt the password for the bksecurity data source, and apply role-based access control (RBAC) to the existing queue.

Before beginning the guided exercise, run the following command to prepare the environment, and to download the lab files:

[student@workstation ~]$ lab start security-review

A JBoss EAP administrator has set up a managed domain with two host controllers running on servera and serverb machines. The domain controller runs on the workstation machine. The domain and host configuration files are stored in the /opt/domain directory on all three machines.

In this exercise you configure a data source and create a legacy security domain that uses the data source. Then, you store the database password in a JBoss EAP vault. Finally, you remove the default authorization configuration from the messaging subsystem, and secure the message broker with the security domain.

You must use the full profile of JBoss EAP to deploy the testing messaging applications on the domain. You can choose either the JBoss EAP management console or the management CLI to achieve your objectives. Keep in mind that the management CLI is the preferred option in production environments.

Instructions

Configure the bksecurity data source in the managed domain.
Create a data source in the full profile managed domain for the bksecurity database. The data source must have the following configuration, and must use the already installed MariaDB driver:
Field Value
Name bksecurity-ds
Connection URL jdbc:mariadb://172.25.250.9:3306:3306/bksecurity
User Name bkadmin
Password redhat123
Security Domain Leave empty
Validate that the connection works.
Start the managed domain to enable the management console for creating and testing the data source.
As the jboss user, start the primary host on the workstation machine:
[student@workstation ~]$ cd /opt/jboss-eap-7.4/bin [student@workstation bin]$ sudo -u jboss ./domain.sh \ -Djboss.domain.base.dir=/opt/domain/ \ --host-config=host-master.xml
Open a new terminal on the workstation machine. As the jboss user, start the secondary host controller on the servera machine.
[student@workstation ~]$ ssh -t jboss@servera /opt/jboss-eap-7.4/bin/domain.sh \ -Djboss.domain.base.dir=/opt/domain --host-config=host-slave.xml \ -Djboss.domain.master.address=172.25.250.9 \ -bprivate=172.25.250.10
Note the use of the -t option for the ssh command to allocate a pseudo-terminal. You must use this option to properly propagate the signals that Ctrl+C sends to the remote machine.
Open a new terminal on the workstation machine. As the jboss user, start the secondary host controller on the serverb machine:
[student@workstation ~]$ ssh -t jboss@serverb /opt/jboss-eap-7.4/bin/domain.sh \ -Djboss.domain.base.dir=/opt/domain --host-config=host-slave.xml \ -Djboss.domain.master.address=172.25.250.9 \ -bprivate=172.25.250.11
Note the use of the -t option for the ssh command to allocate a pseudo-terminal. You must use this option to properly propagate the signals that Ctrl+C sends to the remote machine.
Start the management CLI in a new terminal and connect to the primary host controller.
[student@workstation ~]$ cd /opt/jboss-eap-7.4/bin [student@workstation bin]$ sudo -u jboss ./jboss-cli.sh --connect \ --controller=172.25.250.9:9990 [domain@172.25.250.9:9990 /]
Create the data source by using the following command:
[domain@172.25.250.9:9990 /] data-source add \ --profile=full --name=bksecurity-ds --driver-name=mariadb \ --jndi-name=java:/jboss/datasources/bksecurity-ds \ --connection-url=jdbc:mariadb://172.25.250.9:3306/bksecurity \ --user-name=bkadmin --password=redhat123 [domain@172.25.250.9:9990 /]
Validate that the connection works properly from the servera.1 server.
[domain@172.25.250.9:9990 /] /host=servera/server=servera.1/\ subsystem=datasources/data-source=bksecurity-ds:test-connection-in-pool { "outcome" => "success", "result" => [true] }

Field	Value
`Name`	`bksecurity-ds`
`Connection URL`	`jdbc:mariadb://172.25.250.9:3306:3306/bksecurity`
`User Name`	`bkadmin`
`Password`	`redhat123`
`Security Domain`	Leave empty

Configure the ad248-sd legacy security domain.

Create an ad248-sd security domain that uses the bksecurity-ds data source. The security domain must have a default cache type. The database login module for the security domain must have the following configuration:

Field	Value
`Name`	`database`
`Code`	`Database`
`Flag`	`required`
`dsJndiName`	`java:jboss/datasources/bksecurity-ds`
`principalsQuery`	`select password from users where username=?`
`rolesQuery`	`select role, "Roles" from roles where username=?`
`hashAlgorithm`	`SHA-256`
`hashEncoding`	`base64`

Create the legacy security domain by running the following CLI command:

[domain@172.25.250.9:9990 /] /profile=full/subsystem=security/\
security-domain=ad248-sd:add
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
        "Group1" => {"host" => {
            "servera" => {"servera.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}},
            "serverb" => {"serverb.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}}
        }},
        "Group2" => {"host" => {
            "servera" => {"servera.2" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}},
            "serverb" => {"serverb.2" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}}
        }}
    }
}

Use the following command to create an authentication module.

[domain@172.25.250.9:9990] /profile=full/subsystem=\
security/security-domain\
=ad248-sd/authentication\
=classic:add
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
        "Group1" => {"host" => {
            "servera" => {"servera.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined,
                "response-headers" => {
                    "operation-requires-reload" => true,
                    "process-state" => "reload-required"
                }
            }}},
            "serverb" => {"serverb.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined,
                "response-headers" => {
                    "operation-requires-reload" => true,
                    "process-state" => "reload-required"
                }
            }}}
        }},
        "Group2" => {"host" => {
...output omitted...
}

Note

The output indicates that a server reload is required. You can safely ignore that message, because you reload the server in the next steps.

Create a login module that connects to the data source created in the previous step.

It must query the users and the roles tables to identify the credentials. The password is encrypted with a SHA-256 hash algorithm and the hash uses a base64 encoding.

Use the following CLI command to create the login module:

[domain@172.25.250.9:9990] /profile=full/subsystem=security\
/security-domain=ad248-sd/authentication=\
classic/login-module=database:add( \
  code=Database, \
  flag=required, \
  module-options=[ \
    ("dsJndiName"=>"java:jboss/datasources/bksecurity-ds"), \
    ("principalsQuery"=>"select password from users where username=?"), \
    ("rolesQuery"=>"select role, 'Roles' from roles where username=?"), \
    ("hashAlgorithm"=>"SHA-256"), \
    ("hashEncoding"=>"base64") \
  ])
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
        "Group1" => {"host" => {
            "servera" => {"servera.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined,
                "response-headers" => {
                    "operation-requires-reload" => true,
                    "process-state" => "reload-required"
                }
            }}},
            "serverb" => {"serverb.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined,
                "response-headers" => {
                    "operation-requires-reload" => true,
                    "process-state" => "reload-required"
                }
            }}}
        }},
        "Group2" => {"host" => {
...output omitted...
}

Reload the server to apply all the changes to the servers configuration:

[domain@172.25.250.9:9990] :reload-servers(blocking=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

Verify the login module settings by running the following CLI command:

[domain@172.25.250.9:9990] /profile=full/subsystem=security\
/security-domain=ad248-sd/authentication=classic/\
login-module=database:read-resource
{
    "outcome" => "success",
    "result" => {
      "code" => "Database",
      "flag" => "required",
      "module" => undefined,
      "module-options" => {
         ("rolesQuery" => "select role, 'Roles' from roles where username=?"),
         ("principalsQuery" => "select password from users where username=?"),
         ("dsJndiName" => "java:jboss/datasources/bksecurity-ds"),
         ("hashAlgorithm" => "SHA-256"),
         ("hashEncoding" => "base64"),
         }
    }
}

Note

If there are typos or errors in the login-module, then it is easier to update the module options in the management console. Access the security subsystem to fix any errors in the login-module.

Deploy the secure messaging client.
Explore the source code for the messaging-client-secure application. Open the web.xml and jboss-web.xml files to find that the application uses the ad248-sd security domain. Then, deploy the war file located at /tmp/messaging-client-secure.war to the Group 1 server group.
The application source code is located at the /home/student/AD248/labs/security-review/messaging-client-secure/ directory. Verify that the application is secured by navigating to http://172.25.250.10:8080/messaging-client-secure. Use admin as the username and the password.
Open the /home/student/AD248/labs/security-review/messaging-client-secure/WEB-INF/web.xml file. Observe the login-config tag configured with the BASIC authorization method and the ad248-sd realm name.
...output omitted... <login-config> <auth-method>BASIC</auth-method> <realm-name>ad248-sd</realm-name> </login-config> ...output omitted...
Open the /home/student/AD248/labs/security-review/messaging-client-secure/WEB-INF/jboss-web.xml file. Within the <jboss-web> tag verify that the <security-domain> is configured as ad248-sd:
<security-domain>ad248-sd</security-domain>
Use the management CLI to deploy the /tmp/messaging-client-secure.war file on the Group1 server group.
[domain@172.25.250.9:9990] deploy /tmp/messaging-client-secure.war \ --server-groups=Group1 [domain@172.25.250.9:9990 /]
The application should deploy without any errors.
Open the browser to access the application at http://172.25.250.10:8080/messaging-client-secure by using admin as the username and the password. .
Create a vault keystore.
The bksecurity data source has the username and password stored in plain text in the domain.xml file, which creates a high security risk. Store the password in a vault and reference the vault in the configuration to protect the data source credentials.
Create a keystore with the following configuration:
Field Value
Alias vault
keyalg AES
genseckey enabled
storetype jceks
keysize 128
keystore /opt/jboss-eap-7.4/vault.keystore
When prompted, use password as the vault password.
Open a new terminal window and run the following commands to create a vault.keystore file at /opt/jboss-eap-7.4/. When prompted, use password as the password for your keystore.
[student@workstation ~]$ sudo -u jboss keytool \ -genseckey -alias vault \ -keyalg AES -storetype jceks -keysize 128 \ -keystore /opt/jboss-eap-7.4/vault.keystore Enter keystore password: Re-enter new password: Enter key password for <vault> (RETURN if same as keystore password): Warning: The JCEKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /opt/jboss-eap-7.4/vault.keystore -destkeystore /opt/jboss-eap-7.4/vault.keystore -deststoretype pkcs12".
Note
You can safely ignore the warning about the JCEKS format. Refer to the Should the password Vault keystore format be migrated from JCEKS to PKCS12 ? Red Hat Knowledge Base article at https://access.redhat.com/solutions/3388801.
Copy the new keystore to both servera and serverb:
[student@workstation ~]$ sudo scp /opt/jboss-eap-7.4/vault.keystore \ servera:/opt/jboss-eap-7.4 vault.keystore [student@workstation ~]$ sudo scp /opt/jboss-eap-7.4/vault.keystore \ serverb:/opt/jboss-eap-7.4 vault.keystore
Change ownership of the keystore to user jboss on both servera and serverb:
[student@workstation ~]$ ssh root@servera \ chown jboss:jboss /opt/jboss-eap-7.4/vault.keystore
[student@workstation ~]$ ssh root@serverb \ chown jboss:jboss /opt/jboss-eap-7.4/vault.keystore

Field	Value
`Alias`	`vault`
`keyalg`	`AES`
`genseckey`	`enabled`
`storetype`	`jceks`
`keysize`	`128`
`keystore`	`/opt/jboss-eap-7.4/vault.keystore`

Create a vault entry with the bksecurity-ds data source password.

The vault must reference the keystore that you created in the previous step. You can find the vault at /opt/jboss-eap-7.4/vault.keystore. The vault must have the following configuration:

Field	Value
`Password`	`password`
`8 character salt`	`12345678`
`Iteration count`	`50`
`Keystore Alias`	`vault`
`Vault Block`	`bksecurity`
`Attribute Name`	`password`
`Attribute Value`	`redhat123`

Then, copy the VAULT.dat file to /opt/jboss-eap-7.4/ on both servera and serverb machines. Update the /opt/domain/configuration/host-slave.xml file to include the vault definition.

Enter the following command to run the vault tool script:

[student@workstation ~]$ cd /opt/jboss-eap-7.4/bin
[student@workstation bin]$ sudo -u jboss ./vault.sh

At the first prompt, enter 0 to select Start Interactive Session.
When prompted for the directory to store encrypted files, enter /opt/jboss-eap-7.4/.
Note that the trailing slash is required.
The Keystore URL is the path to the vault.keystore file you created in the previous step.
Enter:
```
/opt/jboss-eap-7.4/vault.keystore
```
For the remaining prompts, use the following values:
Field Value
Password password
8 character salt 12345678
Iteration count 50
Keystore Alias vault

Make a note of the Vault Configuration for the domain mode.

WFLYSEC0056: Initializing Vault
Sep 21, 2023 6:56:48 AM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX00361: Default Security Vault Implementation Initialized and Ready
WFLYSEC0048: Vault Configuration commands in WildFly for CLI:
********************************************
For standalone mode:
/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "/opt/jboss-eap-7.4/vault.keystore"),("KEYSTORE_PASSWORD" => "MASK-31x/z0Xn83H4JaL0h5eK/N"),("KEYSTORE_ALIAS" => "vault"),("SALT" => "12345678"),("ITERATION_COUNT" => "50"),("ENC_FILE_DIR" => "/opt/jboss-eap-7.4/")])
********************************************
For domain mode:
/host=the_host/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "/opt/jboss-eap-7.4/vault.keystore"),("KEYSTORE_PASSWORD" => "MASK-31x/z0Xn83H4JaL0h5eK/N"),("KEYSTORE_ALIAS" => "vault"),("SALT" => "12345678"),("ITERATION_COUNT" => "50"),("ENC_FILE_DIR" => "/opt/jboss-eap-7.4/")])
********************************************
WFLYSEC0057: Vault is initialized and ready for use
WFLYSEC0058: Handshake with Vault complete

The vault tool has now connected to your vault. Enter 0 to store a secured attribute.
At the prompt to enter attribute value, enter redhat123, which is the password to connect to the MariaDB database. Enter redhat123 twice to verify.
At the prompt to enter a Vault Block, enter bksecurity and at the Enter Attribute Name prompt, enter password.

Make a note of the resulting information:

Please make note of the following:
********************************************
Vault Block:bksecurity
Attribute Name:password
Configuration should be done as follows:
VAULT::bksecurity::password::1
********************************************

The password for the MariaDB database is now in the /opt/jboss-eap-7.4/VAULT.dat file.
Enter 3 to Exit the vault tool.

Copy the vault file from the workstation to servera and serverb:

[student@workstation bin]$ sudo scp /opt/jboss-eap-7.4/VAULT.dat \
servera:/opt/jboss-eap-7.4
VAULT.dat
[student@workstation bin]$ sudo scp /opt/jboss-eap-7.4/VAULT.dat \
serverb:/opt/jboss-eap-7.4
VAULT.dat

Change ownership of the VAULT.dat file to the jboss user:

[student@workstation bin]$ ssh root@servera \
chown jboss:jboss /opt/jboss-eap-7.4/VAULT.dat

[student@workstation bin]$ ssh root@serverb \
chown jboss:jboss /opt/jboss-eap-7.4/VAULT.dat

Configure the vault in each host controller by using the management CLI.

Start the management CLI in a new terminal and connect to the primary host controller.

[student@workstation bin]$ sudo -u jboss ./jboss-cli.sh --connect \
--controller=172.25.250.9:9990
[domain@172.25.250.9:9990 /]

Add the vault by using the following commands returned in the previous step, and adapted for each host controller:

[domain@172.25.250.9:9990 /] /host=master/core-service=vault:add\
(vault-options=[("KEYSTORE_URL" => "/opt/jboss-eap-7.4/vault.keystore"),\
("KEYSTORE_PASSWORD" => "MASK-31x/z0Xn83H4JaL0h5eK/N"),\
("KEYSTORE_ALIAS" => "vault"),("SALT" => "12345678"),\
("ITERATION_COUNT" => "50"),\
("ENC_FILE_DIR" => "/opt/jboss-eap-7.4/")])
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

[domain@172.25.250.9:9990 /] /host=servera/core-service=vault:add\
(vault-options=[("KEYSTORE_URL" => "/opt/jboss-eap-7.4/vault.keystore"),\
("KEYSTORE_PASSWORD" => "MASK-31x/z0Xn83H4JaL0h5eK/N"),\
("KEYSTORE_ALIAS" => "vault"),("SALT" => "12345678"),\
("ITERATION_COUNT" => "50"),\
("ENC_FILE_DIR" => "/opt/jboss-eap-7.4/")])
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

[domain@172.25.250.9:9990 /] /host=serverb/core-service=vault:add\
(vault-options=[("KEYSTORE_URL" => "/opt/jboss-eap-7.4/vault.keystore"),\
("KEYSTORE_PASSWORD" => "MASK-31x/z0Xn83H4JaL0h5eK/N"),\
("KEYSTORE_ALIAS" => "vault"),("SALT" => "12345678"),\
("ITERATION_COUNT" => "50"),\
("ENC_FILE_DIR" => "/opt/jboss-eap-7.4/")])
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

Restart the servers.

[domain@172.25.250.9:9990 /] :reload-servers(blocking=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

Disable the bksecurity-ds data source, and replace the password with the vault reference to the bksecurity password.

Disable the data source, and reload the servers:

[domain@172.25.250.9:9990 /] /profile=full/subsystem=datasources/\
data-source=bksecurity-ds:write-attribute(name=enabled,value=false)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
        "Group1" => {"host" => {
...output omitted...
[domain@172.25.250.9:9990 /] :reload-servers(blocking=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

Replace the clear password with the vault reference.

[domain@172.25.250.9:9990 /] /profile=full/subsystem=datasources/\
data-source=bksecurity-ds:write-attribute\
(name=password,value=${VAULT::bksecurity::password::1})
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
        "Group1" => {"host" => {
            "servera" => {"servera.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}},
            "serverb" => {"serverb.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}}
        }},
        "Group2" => {"host" => {
            "servera" => {"servera.2" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}},
            "serverb" => {"serverb.2" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}}
        }}
    }
}

Enable the data source, and reload the servers:

[domain@172.25.250.9:9990 /] /profile=full/subsystem=datasources/\
data-source=bksecurity-ds:write-attribute(name=enabled,value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
        "Group1" => {"host" => {
            "servera" => {"servera.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined,
                "response-headers" => {
                    "operation-requires-reload" => true,
                    "process-state" => "reload-required"
                }
            }}},
            "serverb" => {"serverb.1" => {"response" => {
...output omitted...

[domain@172.25.250.9:9990 /] :reload-servers(blocking=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

Verify that the connection works with the configured vault reference:

[domain@172.25.250.9:9990 /] /host=servera/server=servera.1/\
subsystem=datasources/data-source=bksecurity-ds:test-connection-in-pool
{
    "outcome" => "success",
    "result" => [true]
}

Secure the queue.

The messaging-mdb-secure example application has the credentials to read from the queue called JB248TestQueue. The credentials are admin/admin. These credentials are the same as those that are stored in the bksecurity database.

You must restrict access to every queue in the application to ensure that only administrators can send and receive messages. To achieve that restriction, remove the existing guest security setting, and create a new security setting for the role admin, which has the send, receive, and manage privileges. The new security setting must use the # wildcard for the pattern to apply to every destination.

Finally, run the following command to set ad248-sd as the default security domain for the messaging subsystem:

/profile=full/subsystem=messaging-activemq/server=default:\
write-attribute(name=security-domain,value=ad248-sd)

Use the management CLI to remove the # pattern for the guest role in the messaging subsystem of the full profile

[domain@172.25.250.9:9990 /] /profile=full/subsystem=messaging-activemq/\
server=default/security-setting=#:remove
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
        "Group1" => {"host" => {
            "servera" => {"servera.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}},
            "serverb" => {"serverb.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}}
        }},
        "Group2" => {"host" => {
            "servera" => {"servera.2" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}},
            "serverb" => {"serverb.2" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}}
        }}
    }
}

Add a new # pattern, and associate it to the admin role.

[domain@172.25.250.9:9990 /] /profile=full/subsystem=messaging-activemq/\
server=default/security-setting=#:add
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
...output omitted...

[domain@172.25.250.9:9990 /] /profile=full/subsystem=messaging-activemq/\
server=default/security-setting=#/role=admin:add
{
    "outcome" => "success",
    "result" => undefined,
...output omitted...
}

Add the consume, manage, and send privileges to the admin role.

[domain@172.25.250.9:9990 /] /profile=full/subsystem=messaging-activemq\
/server=default/security-setting=#\
/role=admin:write-attribute(name=consume, value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
...output omitted...
    }
}
[domain@172.25.250.9:9990 /] /profile=full/subsystem=messaging-activemq\
/server=default/security-setting=#\
/role=admin:write-attribute(name=manage, value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
...output omitted...
    }
}
[domain@172.25.250.9:9990 /] /profile=full/subsystem=messaging-activemq\
/server=default/security-setting=#\
/role=admin:write-attribute(name=send, value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
...output omitted...

Change the default security domain for the messaging-activemq subsystem to the ad248-sd security domain:

[domain@172.25.250.9:9990 /] /profile=full/subsystem=messaging-activemq\
/server=default:write-attribute(name=security-domain,value=ad248-sd)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
        "Group1" => {"host" => {
            "servera" => {"servera.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined,
                "response-headers" => {
                    "operation-requires-reload" => true,
                    "process-state" => "reload-required"
                }
            }}},
...output omitted...

Reload all the servers in the managed domain.

[domain@172.25.250.9:9990 /] :reload-servers(blocking=true)

Test the queue authorization. Access the secure message client application at http://172.25.250.10:8080/messaging-client-secure, and send a test message. Use admin as the username and the password. Remove the send and receive privileges for this user and verify that you can no longer send a message.

Deploy the MDB application located at /tmp/messaging-mdb-secure.jar onto the Group1 server group.

[domain@172.25.250.9:9990 /] deploy /tmp/messaging-mdb-secure.jar \
--server-groups=Group1
[domain@172.25.250.9:9990 /]

Publish a test message. Enter the message producer application running on servera.1 at http://172.25.250.10:8080/messaging-client-secure.
Fill the application form with the following data:
Field Value
Message Count 5
Message Label testmsg
Message to send jms test
Navigate to http://172.25.250.10:8080/messaging-client-secure.
Complete the web form and click Send Message to send the messages.
The web form should refresh and show the following message in green: Messages sent successfully.

Field	Value
`Message Count`	`5`
`Message Label`	`testmsg`
`Message to send`	`jms test`

Use the management console, or the files in the servera, and the serverb machines to inspect the server logs, and find the entries generated by the consumer application.

The servera.1 and serverb.1 servers have log entries generated by the consumer application.

There are log entries similar to the following on the servera and serverb logs:

[student@workstation ~]$ ssh jboss@servera \
cat /opt/domain/servers/servera.1/log/server.log

...output omitted...
2023-09-25 09:51:46,776 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 20) WFLYSRV0010: Deployed "messaging-mdb-secure.jar" (runtime-name : "messaging-mdb-secure.jar")
2023-09-25 09:53:38,064 INFO  [class com.redhat.training.messaging.mdb.MessageReceiver] (Thread-3 (ActiveMQ-client-global-threads)) Message Properties: Copy #2 [testmsg]
2023-09-25 09:53:38,066 INFO  [class com.redhat.training.messaging.mdb.MessageReceiver] (Thread-5 (ActiveMQ-client-global-threads)) Message Properties: Copy #4 [testmsg]
2023-09-25 09:53:38,066 INFO  [class com.redhat.training.messaging.mdb.MessageReceiver] (Thread-5 (ActiveMQ-client-global-threads)) Message Body: jms test
2023-09-25 09:53:38,066 INFO  [class com.redhat.training.messaging.mdb.MessageReceiver] (Thread-3 (ActiveMQ-client-global-threads)) Message Body: jms test
2023-09-25 09:53:38,066 INFO  [class com.redhat.training.messaging.mdb.MessageReceiver] (Thread-4 (ActiveMQ-client-global-threads)) Message Properties: Copy #3 [testmsg]
2023-09-25 09:53:38,080 INFO  [class com.redhat.training.messaging.mdb.MessageReceiver] (Thread-4 (ActiveMQ-client-global-threads)) Message Body: jms test
2023-09-25 09:53:38,081 INFO  [class com.redhat.training.messaging.mdb.MessageReceiver] (Thread-2 (ActiveMQ-client-global-threads)) Message Properties: Copy #1 [testmsg]
2023-09-25 09:53:38,081 INFO  [class com.redhat.training.messaging.mdb.MessageReceiver] (Thread-2 (ActiveMQ-client-global-threads)) Message Body: jms test
2023-09-25 09:53:38,101 INFO  [class com.redhat.training.messaging.mdb.MessageReceiver] (Thread-6 (ActiveMQ-client-global-threads)) Message Properties: Copy #5 [testmsg]
2023-09-25 09:53:38,101 INFO  [class com.redhat.training.messaging.mdb.MessageReceiver] (Thread-6 (ActiveMQ-client-global-threads)) Message Body: jms test

Update the messaging subsystem security settings for the default server.

From the management CLI, remove the send and consume privileges.

[domain@172.25.250.9:9990 /] /profile=full/subsystem=messaging-activemq\
/server=default/security-setting=#\
/role=admin:write-attribute(name=consume, value=false)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
        "Group1" => {"host" => {
            "servera" => {"servera.1" => {"response" => {
                "outcome" => "success",
                "result" => undefined
            }}},
...output omitted...

[domain@172.25.250.9:9990 /] /profile=full/subsystem=messaging-activemq\
/server=default/security-setting=#\
/role=admin:write-attribute(name=send, value=false)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {
        "Group1" => {"host" => {
            "servera" => {"servera.1" => {"response" => {
...output omitted...

Return to the messaging-client-secure application.
Click Send Messages again to send more test messages.

Verify in the server logs for servera that no message was sent because this user's role did not have proper authorization to send a message.

[student@workstation ~]$ ssh jboss@servera \
cat /opt/domain/servers/servera.1/log/server.log
...output omitted...
2023-09-25 10:03:28,697 INFO  [stdout] (default task-2) javax.jms.JMSSecurityRuntimeException: AMQ229032: User: admin does not have permission='SEND' on address jms.queue.TestQueue

Clean up and grading.
1. Press Ctrl+C in all terminals to stop the domain controller on workstation, and the two host controllers on the servera and serverb machines.
2. Run the following command to grade the exercise:
```
[student@workstation bin]$ lab grade security-review
```

Finish

As the student user on the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish security-review

Discuss Red Hat JBoss Enterprise Application Platform Administration I

Go to community

Welcome to the Red Hat JBoss Application Administration 1 (AD248) group!

Deanna

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat JBoss Application Administration I! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to AD248.Read more about Red Hat JBoss Application Administration I here.

270

Revision: ad248-7.4-18a9db2