Enable WebSphere Application Server security

Enable WebSphere Application Server security

1. Enable administrative security

   Click...

   Security > Global security > realm definition > Set as current

   Save the configuration to the repository. Verify that the validation that occurs after clicking OK on the Security > Global security panel is successful before continuing. If the validation is not successful and you continue with these steps, you risk the server not starting. Reconfigure the security settings until validation is successful.

2. Send a copy of the new configuration to all of the running node agents using the administrative console. If a node agent fails to get the security-enabled configuration, communication with the deployment manager fails, due to a lack of access. The node agent is not security-enabled. To force synchronize a specific node from the administrative console:

   1. Click...
      System administration > Nodes > all nodes checkbox

      We do not need to select the deployment manager node.

   2. Click Full resynchronize

      The message might indicate that the nodes already are synchronized. This message is OK. When synchronization is initiated, verify that the Synchronized status displays for all nodes.

3. Stop the deployment manager.

   Manually restart the deployment manager from the command line or service. To stop the deployment manager, click...'

   System administration > Deployment manager > Stop

   This action logs you out of the administrative console and stops the dmgr process.

4. Restart the dmgr process.

   (Dist) To restart the dmgr process

   cd app_server_root/bin
   startManager.sh

   After the deployment manager initialization is complete, go back into the administrative console to complete this task. Remember that security now is enabled in only the deployment manager. If we enabled single sign-on (SSO), specify the fully qualified domain name of our Web address, for example,

   http://myhost.domain:port_number/ibm/console

   When prompted for a user ID and password, type the one defined as the administrator ID in the configured user registry.

   (ZOS) To restart the dmgr process, run...

   START dmgr_proc_name,JOBNAME=server_short_name,ENV=cell_short_name.node_short_name.server_short_name

   Go back into the administrative console to complete this task. Security is enabled in the deployment manager only. If we enabled single sign-on (SSO), specify the fully qualified domain name of our web address, for example, http://myhost.domain:port_number/ibm/console. When we are prompted for a user ID and password, type the one that you entered as the administrator ID in the configured user registry.

   (iSeries) To restart the dmgr process, open the Qshell environment and...

   cd app_server_root/bin
   startManager

   After the deployment manager initialization is complete, go back into the administrative console to complete this task. Remember that security now is enabled in only the deployment manager. If we enabled single sign-on (SSO), specify the fully qualified domain name of our Web address, for example, http://myhost.domain:port_number/ibm/console. When we are prompted for a user ID and password, type the one definedd as the administrator ID in the configured user registry.

5. If the deployment manager does not start after enabling security, disable security using a script and restart. Disable security by issuing the following command from the DeploymentManager/bin directory:
   ./wsadmin.sh -conntype NONE

   At the prompt, enter securityoff.

6. Restart all node agents to make them security enabled.

   We must have restarted the deployment manager in a previous step before completing this step. If the node agent is security-enabled before the deployment manager is security-enabled, the deployment manager cannot query the node agent for status or give the node agent commands. To stop all node agents:

   1. Go to System administration > Node agents and select the option for all node agents.

   2. Click Restart.

      A message similar to the following example is displayed: The node agent on node NODE NAME was restarted successfully.

   3. Alternatively, if we previously did not stop the application servers, restart all of the servers within any given node by clicking System administration > Node agents and by clicking the node agents where we want to restart all the servers. Click Restart all Servers on Node. This action restarts the node agent and any started application servers.

7. If any node agent fails to restart, perform a manual resynchronization of the configuration.

   This step consists of going to the physical node and running the client syncNode command. This client logs in to the deployment manager and copies all of the configuration files to the node agent. This action ensures that the configuration is security-enabled. If the node agent is started, but is not communicating with the deployment manager, stop the node agent by issuing the stopServer command.

Cryptography

WebSphere Application Server uses cryptography to protect sensitive data and to ensure confidentiality and integrity of communications between WebSphere Application Server and other components in the network. Cryptography is also used by Web Services Security when certain security constraints are configured for the web services application.

WebSphere Application Server uses JSSE and Java Cryptography Extension (JCE) libraries in the SDK to perform this cryptography. The SDK provides strong but limited jurisdiction policy files. Unrestricted policy files provide the ability to perform full strength cryptography and to improve performance.

WebSphere Application Server provides an SDK 6 containing strong, but limited jurisdiction policy files. We can download the unrestricted policy files from the following website: IBM developer kit: Security information.

Fix packs that include updates to the SDK might overwrite unrestricted policy files and the cacerts file. Back up unrestricted policy files and the cacerts file before applying a fix pack and reapply these files after the fix pack is applied. These files are located in...

{was_install_directory}\java\jre\lib\security

Important: Your country of origin might have restrictions on the import, possession, use, or re-export to another country, of encryption software. Before downloading or using the unrestricted policy files, we must check the laws of our country, its regulations, and its policies concerning the import, possession, use, and re-export of encryption software, to determine if it is permitted.

Download and install the new policy files:

1. Click Java SE 6

2. Scroll down the page then click IBM SDK Policy files.

   The Unrestricted JCE Policy files for SDK 6 website displays.

3. Click Sign in and provide the IBM.com ID and password.

4. Select Unrestricted JCE Policy files for SDK 6 and click Continue.

5. View the license and click I Agree to continue.

6. Click Download Now.

7. Extract the unlimited jurisdiction policy files that are packaged in the compressed file. The compressed file contains a US_export_policy.jar file and a local_policy.jar file.

8. (iSeries) In the WebSphere Application Server installation, go to $JAVA_HOME/jre/lib/security and back up your US_export_policy.jar and local_policy.jar files.

9. In the WebSphere Application Server installation, mount the product HFS read/write. Go to $JAVA_HOME/jre/lib/security and back up your US_export_policy.jar and local_policy.jar files.

10. Replace your US_export_policy.jar and local_policy.jar files with the two files downloaded from the IBM.com website.

11. Re-mount the product HFS as read/only.

(ZOS) The embedded SDK ships with the unrestricted jurisdiction policy JAR files. Therefore, instead of downloading these files from the website, we can symbolically link to the files as allowed by the local country regulations. These unrestricted policy files are in...

install_root/java/demo/jce/policy-files/unrestricted/

The following UNIX based commands allow us to symbolically link to these files:

# Export the paths. We can find the values of the following
# variables in the joblog by searching for was.install.root,
# java.home, and so on:
export was.install.root=<was.install.root>
export java.home=<java.home>
# The previous paths apply to both 31- and 64-bit configurations
# of WebSphere Application Server for z/OS. For a 64-bit
# configuration, the java.home path points to the 64-bit embedded JVM.

# Delete the original policy .jar files. Because a backup is
# automatically present in the smpe.home HFS, an explicit
# backup is not needed:
cd $java.home/lib/security
rm US_export_policy.jar
rm local_policy.jar

# Create symbolic links to the unrestricted policy files:
ln -s $java.home/demo/jce/policy-files/unrestricted/US_export_po licy.jar US_export_policy.jar
ln -s $java.home/demo/jce/policy-files/unrestricted/local_policy .jar local_policy.jar

To remove the symbolic links to the unrestricted policy files in the demo directory and link to the original files, use the following UNIX based commands:

# Export the paths. We can find the values of the following variables in the
# joblog by searching for was.install.root, # java.home, and so on:
export was.install.root=<was.install.root>
export java.home=<java.home>
export smpe.install.root=<smpe.install.root>
# The previous paths apply to both 31- and 64-bit configurations
# of WebSphere Application Server for z/OS. For a 64-bit
# configuration, the java.home path points to the 64-bit embedded JVM.

# Delete the current policy .jar files. We might want
# to back up the following files:
cd $java.home/lib/security
rm US_export_policy.jar
rm local_policy.jar

# Issue the following commands on separate lines to create
# symbolic links to the smpe HFS where the original files
# are kept:
ln -s $smpe.install.root/java/lib/security/US_export_policy.jar US_export_policy.jar
ln -s $smpe.install.root/java/lib/security/local_policy.jar local_policy.jar

Subtopics

• Global security settings
• Specify extent of protection wizard settings
• z/OS security options
• Security custom properties
• Security custom property collection
• Security custom property settings
• Server and administrative security
• Java 2 security
• Enable security
• Select a registry or repository
• Configure the Lightweight Third Party Authentication mechanism
• Java 2 security policy files