About this task
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 Java™ Secure Sockets Extension (JSSE)
and Java Cryptography Extension
(JCE) libraries in the Software Development Kit (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.
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, you must check the laws of your
country, its regulations, and its policies concerning the import,
possession, use, and re-export of encryption software, to determine
if it is permitted.
WebSphere Application
Server provides a SDK 5 that contains strong, but limited jurisdiction
policy files. You can download the unrestricted policy files from
the following Web site: IBM developer
kit: Security information. Complete the following steps to
download and install the new policy files:
- Click J2SE 5.0
- Click IBM SDK Policy
files.
The Unrestricted
JCE Policy files for SDK 5 Web site displays.
- Click Sign in and provide your IBM.com ID and password.
- Select Unrestricted JCE Policy files for SDK
5 and click Continue.
- View the license and click I Agree to continue.
- Click Download Now.
- Extract the unlimited jurisdiction policy files that are packaged
in the ZIP file. The ZIP file contains a US_export_policy.jar file
and a local_policy.jar file.
- In your WebSphere Application
Server installation, go to the $JAVA_HOME/jre/lib/security directory
and back up your US_export_policy.jar and local_policy.jar files.
- Replace your US_export_policy.jar and local_policy.jar files
with the two files that you downloaded from the IBM.com Web site.
Attention: Fix packs that include updates to the Software Development
Kit (SDK) might overwrite unrestricted policy files. Back up unrestricted
policy files before you apply a fix pack and reapply these files after
the fix pack is applied.
![[z/OS]](../../ngzos.gif)
The embedded Software Development Kit
(SDK) ships with the unrestricted jurisdiction policy Java archive (JAR) files. Therefore, instead
of downloading these files from the Web site, you can symbolically
link to the files as allowed by your local country regulations. These
unrestricted policy files are located in the
install_root/java/demo/jce/policy-files/unrestricted/ directory.
The following UNIX-based commands enable you to symbolically link
to these files:
# Export the paths. You 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
# Java virtual machine (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
# Issue the following commands on separate lines to create
# the 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. You 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
# Java virtual machine (JVM).
# Delete the current policy .jar files. You 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
Complete
the following steps to enable security for the realm:
- Enable
administrative security in WebSphere Application
Server.
For more information, see Enabling security. It
is important to click Security > Secure administration, applications,
and infrastructure. Select an available realm definition from
the list, and then click Set as current. Save the configuration
to the repository. Verify that the validation that occurs after you
click OK on the Security > Secure administration, applications,
and infrastructure panel is successful before continuing. If the
validation is not successful and you continue with these steps, you
risk the server not starting. Re-configure the security settings until
validation is successful.
- 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, complete
the following steps from the administrative console:
- Click System administration > Nodes and select
the option next to all the nodes. You do not need to select the deployment
manager node.
- Click Full resynchronize to verify that the file
synchronization has occurred. 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.
- 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 and click Stop.
This action logs you out of the administrative console and stops the
deployment manager process.
- Restart
the deployment manager process.
To restart
the deployment manager process, locate the app_server_root/bin directory
and type startManager.bat or startManager.shAfter
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 you enabled single
sign-on (SSO), specify the fully qualified domain name of your Web
address, for example, http://myhost.domain:port_number/ibm/console.
When you are prompted for a user ID and password, type the one that
you defined as the administrator ID in the configured user registry.
![[z/OS]](../../ngzos.gif)
To restart the deployment manager process, enter the
following command:
START dmgr_proc_name,JOBNAME=server_short_name,
ENV=cell_short_name.node_short_name.server_short_name
You
must enter this command on a single line. It is split here for illustrative
purposes (refer to the related links below for more information on
using z/OS
® MVS™ system commands). After the deployment manager
initialization is complete, go back into the administrative console
to complete this task. Remember that security is enabled in the deployment
manager only. If you enabled single sign-on (SSO), specify the fully
qualified domain name of your Web address, for example,
http://myhost.domain:port_number/ibm/console.
When you are prompted for a user ID and password, type the one that
you entered as the administrator ID in the configured user registry.
Restart
the deployment manager process. To restart the deployment
manager process, open the Qshell environment and locate the app_server_root/bin directory.
The app_server_root variable refers to the app_server_root/bin/ default
directory. On the Qshell command line, type 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 you enabled single
sign-on (SSO), specify the fully qualified domain name of your Web
address, for example, http://myhost.domain:port_number/ibm/console.
When you are prompted for a user ID and password, type the one that
you defined as the administrator ID in the configured user registry.
- 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.
- Restart
all node agents to make them security enabled. You 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, complete the following steps:
- Go to System administration > Node agents and
select the option beside all node agents. Click Restart. A
message similar to the following example is displayed at the top of
the panel: The node agent on node NODE NAME was restarted successfully.
- Alternatively, if you previously did not stop your application
servers, restart all of the servers within any given node by clicking System
administration > Node agents and by clicking the node agents where
you want to restart all the servers. Click Restart all Servers
on Node. This action restarts the node agent and any started application
servers.
- 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 into 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.