Procedure 3.1. Remove Silent Authentication from the Default Security Realm

• Remove silent authentication with the Management CLI

  Remove the local element from the Management Realm and Application Realm as required.
  1. Remove the local element from the Management Realm.

     • For Standalone Servers

       /core-service=management/security-realm=ManagementRealm/authentication=local:remove

     • For Managed Domains

       /host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove

  2. Remove the local element from the Application Realm.

     • For Standalone Servers

       /core-service=management/security-realm=ApplicationRealm/authentication=local:remove

     • For Managed Domains

       /host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove

Procedure 4.1. Edit Configuration Files

1. Open the configuration file.

   Open the configuration file for editing. This file is located in one of two places, depending on whether you use a managed domain or standalone server. This is not the executable file used to start the server or domain.

   • Managed Domain

     EAP_HOME/bin/domain.conf

   • Standalone Server

     EAP_HOME/bin/standalone.conf

2. Add the Java options at the end of the file.

   Add the following line to a new line at the very end of the file. You can modify the -Djava.security.policy value to specify the exact location of your security policy. It should go onto one line only, with no line break. You can modify the -Djava.security.debug to log more or less information, by specifying the debug level. The most verbose is failure,access,policy.

   JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djboss.home.dir=$PWD/.. -Djava.security.policy==$PWD/server.policy -Djava.security.debug=failure"
   
   

3. Start the domain or server.

   Start the domain or server as normal.

Procedure 4.2. Setup a new Java Security Manager Policy

1. Start policytool.

   Start the policytool tool in one of the following ways.

   • Red Hat Enterprise Linux

     From your GUI or a command prompt, run /usr/bin/policytool.

   • Microsoft Windows Server

     Run policytool.exe from your Start menu or from the bin\ of your Java installation. The location can vary.

2. Create a new policy.

   To create a new policy, select Add Policy Entry. Add the parameters you need, then click Done.

3. Edit an existing policy

   Select the policy from the list of existing policies, and select the Edit Policy Entry button. Edit the parameters as needed.

4. Delete an existing policy.

   Select the policy from the list of existing policies, and select the Remove Policy Entry button.

Procedure 4.3. Enable general debugging

• This procedure will enable a sensible general level of security-related debug information.

  Add the following line to the server configuration file.

  • If the JBoss EAP 6 instance is running in a managed domain, the line is added to the bin/domain.conf file for Linux or the bin/domain.conf.bat file for Windows.
  • If the JBoss EAP 6 instance is running as a standalone server, the line is added to the bin/standalone.conf file for Linux, or the bin\standalone.conf.bat file for Windows.

Procedure 5.1. Subscribe to the JBoss Watch List

1. Click the following link to go to the JBoss Watch mailing list page: JBoss Watch Mailing List.
2. Enter your email address in the Subscribing to Jboss-watch-list section.
3. [You may also wish to enter your name and select a password. Doing so is completely optional but recommended.]
4. Press the Subscribe button to start the subscription process.
5. You can browse the archives of the mailing list by going to: JBoss Watch Mailing List Archives.

Procedure 5.2.  Apply a patch to a JBoss product via the zip method

1. Get notified about the security patch either via being a subscriber to the JBoss watch mailing list or by browsing the JBoss watch mailing list archives.

   Note

   Only security patches are announced on the JBoss watch mailing list.
2. Read the errata for the security patch and confirm that it applies to a JBoss product in your environment.
3. If the security patch applies to a JBoss product in your enviornment, then follow the link to download the patch from the Red Hat Customer Portal.
4. The downloadable zip file from the customer portal will contain all the files required to fix the security issue or bug. Download this patch zip file in the same location as your JBoss product.
5. Unzip the patch file in the same location where the JBoss product is installed. The patched versions overwrite the existing files.

Procedure 5.3.  Apply a patch to a JBoss product via the RPM method

1. Get notified about the security patch either via being a subscriber to the JBoss watch mailing list or by browsing the JBoss watch mailing list archives.
2. Read the errata for the security patch and confirm that it applies to a JBoss product in your environment.
3. If the security patch applies to a JBoss product in your environment, then follow the link to download the updated RPM package which is included in the errata.
4. Use

   yum update

   or a similar command to install the patch.

Procedure 6.1. Setup Authentication Settings for a Security Domain

1. Open the security domain's detailed view.

   Click the Profiles label at the top right of the management console. In a managed domain, select the profile to modify from the Profile selection box at the top left of the Profile view. Click the Security menu item at the left, and click Security Domains from the expanded menu. Click the View link for the security domain you want to edit.

2. Navigate to the Authentication subsystem configuration.

   Click the Authentication label at the top of the view if it is not already selected.
   The configuration area is divided into two areas: Login Modules and Details. The login module is the basic unit of configuration. A security domain can include several login modules, each of which can include several attributes and options.

3. Add an authentication module.

   Click the Add button to add a JAAS authentication module. Fill in the details for your module. The Code is the class name of the module. The Flags controls how the module relates to other authentication modules within the same security domain.
   Explanation of the Flags

   The Java Enterprise Edition 6 specification provides the following explanation of the flags for security modules. The following list is taken from http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA. Refer to that document for more detailed information.

   Flag	Details
   required	The LoginModule is required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list.
   requisite	LoginModule is required to succeed. If it succeeds, authentication continues down the LoginModule list. If it fails, control immediately returns to the application (authentication does not proceed down the LoginModule list).
   sufficient	The LoginModule is not required to succeed. If it does succeed, control immediately returns to the application (authentication does not proceed down the LoginModule list). If it fails, authentication continues down the LoginModule list.
   optional	The LoginModule is not required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list.

   After you have added your module, you can modify its Code or Flags by clicking the Edit button in the Details section of the screen. Be sure the Attributes tab is selected.

4. Optional: Add or remove module options.

   If you need to add options to your module, click its entry in the Login Modules list, and select the Module Options tab in the Details section of the page. Click the Add button, and provide the key and value for the option. Use the Remove button to remove an option.

Procedure 6.2. Setup Authorization in a Security Domain

1. Open the security domain's detailed view.

   Click the Profiles label at the top right of the management console. In a managed domain, select the profile to modify from the Profile selection box at the top left of the Profile view. Click the Security menu item at the left, and click Security Domains from the expanded menu. Click the View link for the security domain you want to edit.

2. Navigate to the Authorization subsystem configuration.

   Click the Authorization label at the top of the view if it is not already selected.
   The configuration area is divided into two areas: Policies and Details. The login module is the basic unit of configuration. A security domain can include several authorization policies, each of which can include several attributes and options.

3. Add a policy.

   Click the Add button to add a JAAS authorization policy module. Fill in the details for your module. The Code is the class name of the module. The Flags controls how the module relates to other authorization policy modules within the same security domain.
   Explanation of the Flags

   The Java Enterprise Edition 6 specification provides the following explanation of the flags for security modules. The following list is taken from http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA. Refer to that document for more detailed information.

   Flag	Details
   Required	The LoginModule is required to succeed. If it succeeds or fails, authorization still continues to proceed down the LoginModule list.
   Requisite	LoginModule is required to succeed. If it succeeds, authorization continues down the LoginModule list. If it fails, control immediately returns to the application (authorization does not proceed down the LoginModule list).
   Sufficient	The LoginModule is not required to succeed. If it does succeed, control immediately returns to the application (authorization does not proceed down the LoginModule list). If it fails, authorization continues down the LoginModule list.
   Optional	The LoginModule is not required to succeed. If it succeeds or fails, authorization still continues to proceed down the LoginModule list.

   After you have added your module, you can modify its Code or Flags by clicking the Edit button in the Details section of the screen. Be sure the Attributes tab is selected.

4. Optional: Add, edit, or remove module options.

   If you need to add options to your module, click its entry in the Login Modules list, and select the Module Options tab in the Details section of the page. Click the Add button, and provide the key and value for the option. To edit an option that already exists, click the key or to change it. Use the Remove button to remove an option.

Procedure 6.3. Setup Security Auditing for a Security Domain

1. Open the security domain's detailed view.

   Click the Profiles label at the top right of the management console. In a standalone server, the tab is labeled Profile. In a managed domain, select the profile to modify from the Profile selection box at the top left of the Profile view. Click the Security menu item at the left, and click Security Domains from the expanded menu. Click the View link for the security domain you want to edit.

2. Navigate to the Auditing subsystem configuration.

   Click the Audit label at the top of the view if it is not already selected.
   The configuration area is divided into two areas: Provider Modules and Details. The provider module is the basic unit of configuration. A security domain can include several provider modules each of which can include attributes and options.

3. Add a provider module.

   Click the Add button to add a provider module. Fill in the Code section with the classname of the provider module.
   After you have added your module, you can modify its Code by clicking the Edit button in the Details section of the screen. Be sure the Attributes tab is selected.

4. Verify if your module is working

   The goal of an audit module is to provide a way to monitor the events in the security subsystem. This monitoring can be done by means of writing to a log file, email notifications or any other measurable auditing mechanism.
   For example, JBoss EAP 6 includes the LogAuditProvider module by default. If enabled following the steps above, this audit module writes security notifications to a audit.log file in the log subfolder within the EAP_HOME directory.
   To verify if the steps above have worked in the context of the LogAuditProvider, perform an action that is likely to trigger a notification and then check the audit log file.
   For a full list of included security auditing provider modules, see here: Section A.4, “Included Security Auditing Provider Modules”

5. Optional: Add, edit, or remove module options.

   If you need to add options to your module, click its entry in the Modules list, and select the Module Options tab in the Details section of the page. Click the Add button, and provide the key and value for the option. To edit an option that already exists, remove it by clicking the Remove label, and add it again with the correct options by clicking the Add button.

Procedure 6.4. Setup Security Mapping Settings in a Security Domain

1. Open the security domain's detailed view.

   Click the Profiles label at the top right of the management console. This tab is labeled Profile in a standalone server. In a managed domain, select the profile to modify from the Profile selection box at the top left of the Profile view. Click the Security menu item at the left, and click Security Domains from the expanded menu. Click the View link for the security domain you want to edit.

2. Navigate to the Mapping subsystem configuration.

   Click the Mapping label at the top of the view if it is not already selected.
   The configuration area is divided into two areas: Modules and Details. The mapping module is the basic unit of configuration. A security domain can include several mapping modules, each of which can include several attributes and options.

3. Add a module.

   Click the Add button to add a security mapping module. Fill in the details for your module. The Code is the class name of the module. The Type field refers to the type of mapping this module performs. Allowed values are principal, role, attribute or credential.
   After you have added your module, you can modify its Code or Type by clicking the Edit button in the Details section of the screen. Be sure the Attributes tab is selected.

4. Optional: Add, edit, or remove module options.

   If you need to add options to your module, click its entry in the Modules list, and select the Module Options tab in the Details section of the page. Click the Add button, and provide the key and value for the option. To edit an option that already exists, click the Remove label key to remove it, and add it again with the new value. Use the Remove button to remove an option.

Procedure 7.1. Configure the JBoss Web Server to use HTTPS

1. Add a new HTTPS connector.

   Execute the following Management CLI command, changing the profile as appropriate. This creates a new secure connector, called HTTPS, which uses the https scheme, the https socket binding (which defaults to 8443), and is set to be secure.

   Example 7.1. Management CLI Command

   /profile=default/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
   

2. Configure the SSL encryption certificate and keys.

   Execute the following CLI commands to configure your SSL certificate, substituting your own values for the example ones. This example assumes that the keystore is copied to the server configuration directory, which is EAP_HOME/domain/configuration/ for a managed domain.

   Example 7.2. Management CLI Command

   /profile=default/subsystem=web/connector=HTTPS/ssl=configuration:add(name=https,certificate-key-file="${jboss.server.config.dir}/keystore.jks",password=SECRET, key-alias=KEY_ALIAS)
   

   For a full listing of parameters you can set for the SSL properties of the connector, refer to Section 7.4, “SSL Connector Reference”.

3. Deploy an application.

   Deploy an application to a server group which uses the profile you have configured. If you use a standalone server, deploy an application to your server. HTTP requests to it use the new SSL-encrypted connection.

Procedure 7.2. Generate a SSL Encryption Key and Certificate

1. Generate a keystore with public and private keys.

   Run the following command to generate a keystore named server.keystore with the alias jboss in your current directory.

   keytool -genkeypair -alias jboss -keyalg RSA -keystore server.keystore -storepass mykeystorepass --dname "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,S=NC,C=US"

   The following table describes the parameters used in the keytool command:

   Parameter	Description
   -genkeypair	The keytool command to generate a key pair containing a public and private key.
   -alias	The alias for the keystore. This value is arbitrary, but the alias jboss is the default used by the JBoss Web server.
   -keyalg	The key pair generation algorithm. In this case it is RSA.
   -keystore	The name and location of the keystore file. The default location is the current directory. The name you choose is arbitrary. In this case, the file will be named server.keystore.
   -storepass	This password is used to authenticate to the keystore so that the key can be read. The password must be at least 6 characters long and must be provided when the keystore is accessed. In this case, we used mykeystorepass. If you omit this parameter, you will be prompted to enter it when you execute the command.
   -keypass	This is the password for the actual key. Note Due to an implementation limitation this must be the same as the store password.
   --dname	A quoted string describing the distinguished name for the key, for example: "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,C=US". This string is a concatenation of the following components: CN - The common name or host name. If the hostname is "jsmith.mycompany.com", the CN is "jsmith". OU - The organizational unit, for example "Engineering" O - The organization name, for example "mycompany.com". L - The locality, for example "Raleigh" or "London" S - The state or province, for example "NC". This parameter is optional. C - The 2 letter country code, for example "US" or "UK",

   When you execute the above command, you are prompted for the following information:

   • If you did not use the -storepass parameter on the command line, you are asked to enter the keystore password. Re-enter the new password at the next prompt.
   • If you did not use the -keypass parameter on the command line, you are asked to enter the key password. Press Enter to set this to the same value as the keystore password.
   When the command completes, the file server.keystore now contains the single key with the alias jboss.

2. Verify the key.

   Verify that the key works properly by using the following command.

   keytool -list -keystore server.keystore

   You are prompted for the keystore password. The contents of the keystore are displayed (in this case, a single key called jboss). Notice the type of the jboss key, which is keyEntry. This indicates that the keystore contains both a public and private entry for this key.

3. Generate a certificate signing request.

   Run the following command to generate a certificate signing request using the public key from the keystore you created in step 1.

   keytool -certreq -keyalg RSA -alias jboss -keystore server.keystore -file certreq.csr

   You are prompted for the password in order to authenticate to the keystore. The keytool command then creates a new certificate signing request called certreq.csr in the current working directory.

4. Test the newly generated certificate.

   Test the contents of the certificate by using the following command.

   openssl req -in certreq.csr -noout -text

   The certificate details are shown.

5. Optional: Submit your certificate to a Certificate Authority (CA).

   A Certificate Authority (CA) can authenticate your certificate so that it is considered trustworthy by third-party clients. The CA supplies you with a signed certificate, and optionally with one or more intermediate certificates.

6. Optional: Export a self-signed certificate from the keystore.

   If you only need it for testing or internal purposes, you can use a self-signed certificate. You can export one from the keystore you created in step 1 as follows:

   keytool -export -alias jboss -keystore server.keystore -file server.crt

   You are prompted for the password in order to authenticate to the keystore. A self-signed certificate, named server.crt, is created in the current working directory.

7. Import the signed certificate, along with any intermediate certificates.

   Import each certificate, in the order that you are instructed by the CA. For each certificate to import, replace intermediate.ca or server.crt with the actual file name. If your certificates are not provided as separate files, create a separate file for each certificate, and paste its contents into the file.

   Note

   Your signed certificate and certificate keys are valuable assets. Be cautious with how you transport them between servers.

   keytool -import -keystore server.keystore -alias intermediateCA -file intermediate.ca

   keytool -import -alias jboss -keystore server.keystore -file server.crt

8. Test that your certificates imported successfully.

   Run the following command, and enter the keystore password when prompted. The contents of your keystore are displayed, and the certificates are part of the list.

   keytool -list -keystore server.keystore

1. Run the Management CLI.

   Start the jboss-cli.sh or jboss-cli.bat command and connect to the server.

2. Create the new security realm itself.

   Run the following command to create a new security realm named MyDomainRealm on a domain controller or a standalone server.

   /host=master/core-service=management/security-realm=MyDomainRealm:add()

3. Create the references to the properties file which will store information about the new role.

   Run the following command to create a pointer a file named myfile.properties, which will contain the properties pertaining to the new role.

   Note

   The newly-created properties file is not managed by the included add-user.sh and add-user.bat scripts. It must be managed externally.

   /host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)

1. Run the add-user.sh or add-user.bat command.

   Open a terminal and change directories to the EAP_HOME/bin/ directory. If you run Red Hat Enterprise Linux or another UNIX-like operating system, run add-user.sh. If you run Microsoft Windows Server, run add-user.bat.

2. Choose whether to add a Management User or Application User.

   For this procedure, type b to add an Application User.

3. Choose the realm the user will be added to.

   By default, the only available realm is ApplicationRealm. If you have added a custom realm, you can type its name instead.

4. Type the username, password, and roles, when prompted.

   Type the desired username, password, and optional roles when prompted. Verify your choice by typing yes, or type no to cancel the changes. The changes are written to each of the properties files for the security realm.

Procedure 10.1. Configure a Worker Node

1. Configure the network interfaces.

   By default, the network interfaces all default to 127.0.0.1. Every physical host which hosts either a standalone server or one or more servers in a server group needs its interfaces to be configured to use its public IP address, which the other servers can see.
   To change the IP address of a JBoss EAP 6 host, you need to shut it down and edit its configuration file directly. This is because the Management API which drives the Management Console and Management CLI relies on a stable management address.
   Follow these steps to change the IP address on each server in your cluster to the master's public IP address.
   1. Shut down the server completely.
   2. Edit either the host.xml, which is in EAP_HOME/domain/configuration/ for a managed domain, or the standalone-ha.xml file, which is in EAP_HOME/standalone/configuration/ for a standalone server.
   3. Locate the <interfaces> element. Three interfaces are configured, management, public, and unsecured. For each of these, change the value 127.0.0.1 to the external IP address of the host.
   4. For hosts that participate in a managed domain but are not the master, locate the <host element. Note that it does not have the closing > symbol, because it contains attributes. Change the value of its name attribute from master to a unique name, a different one per slave. This name will also be used for the slave to identify to the cluster, so make a note of it.
   5. For newly-configured hosts which need to join a managed domain, find the <domain-controller> element. Comment out or remove the <local /> element, and add the following line, changing the IP address (X.X.X.X) to the address of the domain controller. This step does not apply for a standalone server.

      <remote host="X.X.X.X" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/>

   6. Save the file and exit.

2. Configure authentication for each slave server.

   Each slave server needs a username and password created in the domain controller's or standalone master's ManagementRealm. On the domain controller or standalone master, run the EAP_HOME/add-user.sh command. Add a user with the same username as the slave, to the ManagementRealm. When asked if this user will need to authenticate to an external JBoss AS instance, answer yes. An example of the input and output of the command is below, for a slave called slave1, with password changeme.

   user:bin user$ ./add-user.sh
   
   What type of user do you wish to add? 
    a) Management User (mgmt-users.properties) 
    b) Application User (application-users.properties)
   (a): a
   
   Enter the details of the new user to add.
   Realm (ManagementRealm) : 
   Username : slave1
   Password : changeme
   Re-enter Password : changeme
   About to add user 'slave1' for realm 'ManagementRealm'
   Is this correct yes/no? yes
   Added user 'slave1' to file '/home/user/jboss-eap-6.0/standalone/configuration/mgmt-users.properties'
   Added user 'slave1' to file '/home/user/jboss-eap-6.0/domain/configuration/mgmt-users.properties'
   Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller?
   yes/no? yes
   To represent the user add the following to the server-identities definition <secret value="Y2hhbmdlbWU=" />
   

3. Copy the Base64-encoded <secret> element from the add-user.sh output.

   If you plan to specify the Base64-encoded password value for authentication, copy the <secret> element value from the last line of the add-user.sh output as you will need it in the step below.

4. Modify the slave host's security realm to use the new authentication.

   1. Re-open the slave host's host.xml or standalone-ha.xml file.
   2. Locate the <security-realms> element. This is where you configure the security realm.
   3. You can specify the secret value in one of the following ways:

      • Specify the Base64-encoded password value in the configuration file.

        1. Add the following block of XML code directly below the <security-realm name="ManagementRealm"> line,

           <server-identities>
               <secret value="Y2hhbmdlbWU="/>
           </server-identities>
           
           

        2. Replace the "Y2hhbmdlbWU=" with the secret value returned from the add-user.sh output in the previous step.

      • Configure the host to get the password from the vault.

        1. Use the vault.sh script to generate a masked password. It will generate a string like the following: VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0.
           You can find more information on the vault in the Password Vaults for Sensitive Strings section of this guide starting here: Section 3.8.1, “About Securing Sensitive Strings in Clear-Text Files”.
        2. Add the following block of XML code directly below the <security-realm name="ManagementRealm"> line.

           <server-identities>
               <secret value="${VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0}"/>
           </server-identities>
           
           

           Be sure to replace the secret value with the masked password generated in the previous step.

           Note

           When creating a password in the vault, it must be specified in plain text, not Base64-encoded.

      • Specify the password as a system property.

        1. Add the following block of XML code directly below the <security-realm name="ManagementRealm"> line

           <server-identities>
               <secret value=${server.identity.password}/>
           </server-identities>
           
           

        2. When you specify the password as a system property, you can configure the host in either of the following ways:
           • Start the server entering the password in plain text as a command line argument, for example:

             -Dserver.identity.password=changeme

             Note

             The password must be entered in plain text and will be visible to anyone who issues a ps -ef command.
           • Place the password in a properties file and pass the properties file URL as a command line argument.
             1. Add the key/value pair to a properties file. For example:

                server.identity.password=changeme
                

             2. Start the server with the command line arguments

                --properties=URL_TO_PROPERTIES_FILE

                .
   4. Save and exit the file.

5. Restart the server.

   The slave will now authenticate to the master using its host name as the username and the encrypted string as its password.

1. Stop JBoss EAP 6.

   Stop JBoss EAP 6 by sending an interrupt in the appropriate way for your operating system. If you are running JBoss EAP 6 as a foreground application, the typical way to do this is to press Ctrl+C.

2. Restart JBoss EAP 6, specifying the bind address.

   Use the -b command-line switch to start JBoss EAP 6 on a specific interface.

   Example 11.1. Specify the public interface.

   EAP_HOME/bin/domain.sh -b 10.1.1.1

   Example 11.2. Specify the management interface.

   EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1

   Example 11.3. Specify different addresses for each interface.

   EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1

   Example 11.4. Bind the public interface to all network interfaces.

   EAP_HOME/bin/domain.sh -b 0.0.0.0

Procedure 11.1. Manage Network Firewalls and JBoss EAP 6 to work together

1. Log into the Management Console.

   Log into the Management Console. By default, it runs on http://localhost:9990/console/.

2. Determine the socket bindings used by the socket binding group.

   Click the Profiles label at the top right of the Management Console. At the left-hand side of the screen, a series of menus is shown. The bottom menu heading is General Configuration. Click the Socket Binding Groups item below this heading. The Socket Binding Declarations screen appears. Initially, the standard-sockets group is shown. You can choose a different group by selecting it from the combo box on the right-hand side.

   Note

   If you use a standalone server, it has only one socket binding group.
   The list of socket names and ports is shown, six values per page. You can go through the pages by using the arrow navigation below the table.

3. Determine the ports you need to open.

   Depending on the function of the particular port and the needs of your environment, some of the ports may need to be accessible across your firewall. If you are unsure of the purpose of a socket binding, refer to Section 11.4, “Network Ports Used By JBoss EAP 6” for a list of the default socket bindings and their purposes.

4. Configure your firewall to forward traffic to JBoss EAP 6.

   Perform these steps to configure your network firewall to allow traffic on the desired port.
   1. Log into your firewall machine and access a command prompt, as the root user.
   2. Issue the command system-config-firewall to launch the firewall configuration utility. A GUI or command-line utility launches, depending on the way you are logged into the firewall system. This task makes the assumption that you are logged in via SSH and using the command-line interface.
   3. Use the TAB key on your keyboard to navigate to the Customize button, and press the ENTER key. The Trusted Services screen appears.
   4. Do not change any values, but use the TAB key to navigate to the Forward button, and press ENTER to advanced to the next screen. The Other Ports screen appears.
   5. Use the TAB key to navigate to the <Add> button, and press ENTER. The Port and Protocol screen appears.
   6. Enter 5445 in the Port / Port Range field, then use the TAB key to move to the Protocol field, and enter tcp. Use the TAB key to navigate to the OK button, and press ENTER.
   7. Use the TAB key to navigate to the Forward button until you reach the Port Forwarding screen.
   8. Use the TAB key to navigate to the <Add> button, and press the ENTER key.
   9. Fill in the following values to set up port forwarding for port 5445.
      • Source interface: eth1
      • Protocol: tcp
      • Port / Port Range: 5445
      • Destination IP address: 10.1.1.2
      • Port / Port Range: 5445
      Use the TAB key to navigate to the OK button, and press ENTER.
   10. Use the TAB key to navigate to the Close button, and press ENTER.
   11. Use the TAB key to navigate to the OK button, and press ENTER. To apply the changes, read the warning and click Yes.

5. Configure a firewall on your JBoss EAP 6 host.

   Some organizations choose to configure a firewall on the JBoss EAP 6 server itself, and close all ports that are not necessary for its operation. Consult Section 11.4, “Network Ports Used By JBoss EAP 6” and determine which ports to open, then close the rest. The default configuration of Red Hat Enterprise Linux 6 closes all ports except 22 (used for Secure Shell (SSH) and 5353 (used for multicast DNS). While you are configuring ports, make sure you have physical access to your server so that you do not inadvertently lock yourself out.

Procedure 12.1. jboss-descriptor-property-replacement

1. In the Management CLI, run the following command to determine the value of jboss-descriptor-property-replacement:

   /subsystem=ee:read-attribute(name="jboss-descriptor-property-replacement")

2. Run the following command to configure the behavior:

   /subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

Procedure 12.2. spec-descriptor-property-replacement

1. In the Management CLI, run the following command to confirm the value of spec-descriptor-property-replacement:

   /subsystem=ee:read-attribute(name="spec-descriptor-property-replacement")

2. Run the following command to configure the behavior:

   /subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)

Procedure 13.1. Setup SSO Authentication for your Web or EJB Applications

1. Configure one security domain to represent the identity of the server. Set system properties if necessary.

   The first security domain authenticates the container itself to the directory service. It needs to use a login module which accepts some type of static login mechanism, because a real user is not involved. This example uses a static principal and references a keytab file which contains the credential.
   The XML code is given here for clarity, but you should use the Management Console or Management CLI to configure your security domains.

   <security-domain name="host" cache-type="default">
      <authentication>
         <login-module code="Kerberos" flag="required">
            <module-option name="storeKey" value="true"/>
            <module-option name="useKeyTab" value="true"/>
            <module-option name="principal" value="host/testserver@MY_REALM"/>
            <module-option name="keyTab" value="/home/username/service.keytab"/>
            <module-option name="doNotPrompt" value="true"/>
            <module-option name="debug" value="false"/>
         </login-module>
      </authentication>
   </security-domain>		
   
   

2. Configure a second security domain to secure the web application or applications. Set system properties if necessary.

   The second security domain is used to authenticate the individual user to the Kerberos or SPNEGO authentication server. You need at least one login module to authenticate the user, and another to search for the roles to apply to the user. The following XML code shows an example SPNEGO security domain. It includes an authorization module to map roles to individual users. You can also use a module which searches for the roles on the authentication server itself.

   <security-domain name="SPNEGO" cache-type="default">
      <authentication>
         <!-- Check the username and password -->
         <login-module code="SPNEGO"  flag="requisite">
            <module-option name="password-stacking" value="useFirstPass"/>
            <module-option name="serverSecurityDomain" value="host"/>
         </login-module>
         <!-- Search for roles -->
         <login-module code="UserRoles" flag="required">
            <module-option name="password-stacking" value="useFirstPass" />
            <module-option name="usersProperties" value="spnego-users.properties" />
            <module-option name="rolesProperties" value="spnego-roles.properties" />
         </login-module> 
      </authentication>
   </security-domain>		
   
   

3. Specify the security-constraint and login-config in the web.xml

   The web.xml descriptor contain information about security constraints and login configuration. The following are example values for each.

   <security-constraint>
      <display-name>Security Constraint on Conversation</display-name>
      <web-resource-collection>
         <web-resource-name>examplesWebApp</web-resource-name>
         <url-pattern>/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
      <role-name>RequiredRole</role-name>
      </auth-constraint>
   </security-constraint>
   
   <login-config>
      <auth-method>SPNEGO</auth-method>
      <realm-name>SPNEGO</realm-name>
   </login-config>
    
   <security-role>
      <description> role required to log in to the Application</description>
      <role-name>RequiredRole</role-name>
   </security-role>		
   
   

4. Specify the security domain and other settings in the jboss-web.xml descriptor.

   Specify the name of the client-side security domain (the second one in this example) in the jboss-web.xml descriptor of your deployment, to direct your application to use this security domain.
   You can no longer override authenticators directly. Instead, you can add the NegotiationAuthenticator as a valve to your jboss-web.xml descriptor, if you need to. The <jacc-star-role-allow> allows you to use the asterisk (*) character to match multiple role names, and is optional.

   <jboss-web>
      <security-domain>java:/jaas/SPNEGO</security-domain>
      <valve>
         <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
      </valve>
      <jacc-star-role-allow>true</jacc-star-role-allow>
   </jboss-web>		
   
   

5. Add a dependency to your application's MANIFEST.MF, to locate the Negotiation classes.

   The web application needs a dependency on class org.jboss.security.negotiation to be added to the deployment's META-INF/MANIFEST.MF manifest, in order to locate the JBoss Negotiation classes. The following shows a properly-formatted entry.

   Manifest-Version: 1.0
   Build-Jdk: 1.6.0_24
   Dependencies: org.jboss.security.negotiation
   

Procedure 14.1. Configure Your Application to Use a Security Domain

1. Define the Security Domain

   You can define the security domain either in the server's configuration file or the application's descriptor file.

   • Configure the security domain in the server's configuration file

     The security domain is configured in the security subsystem of the server's configuration file. If the JBoss EAP 6 instance is running in a managed domain, this is the domain/configuration/domain.xml file. If the JBoss EAP 6 instance is running as a standalone server, this is the standalone/configuration/standalone.xml file.
     The other, jboss-web-policy, and jboss-ejb-policy security domains are provided by default in JBoss EAP 6. The following XML example was copied from the security subsystem in the server's configuration file.

     <subsystem xmlns="urn:jboss:domain:security:1.2">
         <security-domains>
             <security-domain name="other" cache-type="default">
                 <authentication>
                     <login-module code="Remoting" flag="optional">
                         <module-option name="password-stacking" value="useFirstPass"/>
                     </login-module>
                     <login-module code="RealmDirect" flag="required">
                         <module-option name="password-stacking" value="useFirstPass"/>
                     </login-module>
                 </authentication>
             </security-domain>
             <security-domain name="jboss-web-policy" cache-type="default">
                 <authorization>
                     <policy-module code="Delegating" flag="required"/>
                 </authorization>
             </security-domain>
             <security-domain name="jboss-ejb-policy" cache-type="default">
                 <authorization>
                     <policy-module code="Delegating" flag="required"/>
                 </authorization>
             </security-domain>
         </security-domains>
     </subsystem>
     

     You can configure additional security domains as needed using the Management Console or CLI.

   • Configure the security domain in the application's descriptor file

     The security domain is specified in the <security-domain> child element of the <jboss-web> element in the application's WEB-INF/jboss-web.xml file. The following example configures a security domain named my-domain.

     <jboss-web>
         <security-domain>my-domain</security-domain>
     </jboss-web>        
     
     

     This is only one of many settings which you can specify in the WEB-INF/jboss-web.xml descriptor.

2. Add the Required Annotation to the EJB

   You configure security in the EJB using the @SecurityDomain and @RolesAllowed annotations. The following EJB code example limits access to the other security domain by users in the guest role.

   package example.ejb3;
   
   import java.security.Principal;
   
   import javax.annotation.Resource;
   import javax.annotation.security.RolesAllowed;
   import javax.ejb.SessionContext;
   import javax.ejb.Stateless;
   
   import org.jboss.ejb3.annotation.SecurityDomain;
   
   /**
    * Simple secured EJB using EJB security annotations
    * Allow access to "other" security domain by users in a "guest" role.
    */
   @Stateless
   @RolesAllowed({ "guest" })
   @SecurityDomain("other")
   public class SecuredEJB {
   
      // Inject the Session Context
      @Resource
      private SessionContext ctx;
   
      /**
       * Secured EJB method using security annotations
       */
      public String getSecurityInfo() {
         // Session context injected using the resource annotation
         Principal principal = ctx.getCallerPrincipal();
         return principal.toString();
      }
   }
   

   For more code examples, see the ejb-security quickstart in the JBoss EAP 6 Quickstarts bundle, which is available from the Red Hat Customer Portal.

Procedure 14.2. Add Role-Based Security to Servlets

1. Add mappings between servlets and URL patterns.

   Use <servlet-mapping> elements in the web.xml to map individual servlets to URL patterns. The following example maps the servlet called DisplayOpResult to the URL pattern /DisplayOpResult.

   <servlet-mapping>
       <servlet-name>DisplayOpResult</servlet-name>
       <url-pattern>/DisplayOpResult</url-pattern>
   </servlet-mapping>		
   
   

2. Add security constraints to the URL patterns.

   To map the URL pattern to a security constraint, use a <security-constraint>. The following example constrains access from the URL pattern /DisplayOpResult to be accessed by principals with the role eap_admin. The role needs to be present in the security domain.

   <security-constraint>
   	<display-name>Restrict access to role eap_admin</display-name>
   	<web-resource-collection>
   		<web-resource-name>Restrict access to role eap_admin</web-resource-name>
   		<url-pattern>/DisplayOpResult/*</url-pattern>
   	</web-resource-collection>
   	<auth-constraint>
   		<role-name>eap_admin</role-name>
   	</auth-constraint>	
   </security-constraint>	
   
   <security-role>
     <role-name>eap_admin</role-name>
   </security-role>
   
   
   <login-config>
       <auth-method>BASIC</auth-method>
   </login-config>
   
   

   You need to specify the authentication method, which can be any of the following: BASIC, FORM, DIGEST, CLIENT-CERT, SPNEGO. This example uses BASIC authentication.

3. Specify the security domain in the WAR's jboss-web.xml

   Add the security domain to the WAR's jboss-web.xml in order to connect the servlets to the configured security domain, which knows how to authenticate and authorize principals against the security constraints. The following example uses the security domain called acme_domain.

   <jboss-web>
   	...
   	<security-domain>acme_domain</security-domain>
   	...
   </jboss-web>