You need to protect passwords that are contained in your
WebSphere Application Server configuration. After creating your server
profile, you can added protection by creating a custom class for encrypting
the passwords.
About this task
Complete the following steps to enable custom password encryption.
Procedure
- Add the following system properties for every server and
client process. For server processes, update the server.xml file
for each process. Add these properties as a genericJvmArgument argument
preceded by a -D prefix.
com.ibm.wsspi.security.crypto.customPasswordEncryptionClass=
com.acme.myPasswordEncryptionClass
com.ibm.wsspi.security.crypto.customPasswordEncryptionEnabled=true
Tip: If the custom encryption class name is com.ibm.wsspi.security.crypto.CustomPasswordEncryptionImpl,
it is automatically enabled when this class is present in the classpath.
Do not define the system properties that are listed previously when
the custom implementation has this package and class name. To disable
encryption for this class, you must specify com.ibm.wsspi.security.crypto.customPasswordEncryptionEnabled=false as
a system property.
-
Choose one of the following methods to configure
the WebSphere®Application Server runtime to
load the custom encryption implementation class:
- Place the custom encryption class in a Java™ archive
(JAR) file that resides in the ${WAS_INSTALL_ROOT}/classes directory,
which you have created.
Avoid trouble: WebSphere Application Server does not create
the
${WAS_INSTALL_ROOT}/classes directory. For more
information on the classes directory, see the topic, "Creating a classes
subdirectory in your profile for custom classes".
gotcha
- Place the custom encryption class in a Java archive (JAR) file
that resides in the ${WAS_HOME}/lib/ext directory.
![[jan2010]](../../deltaend.gif)
jan2010
- Restart all server processes.
- Edit each configuration document that contains a password
and save the configuration. All password fields are then
run through the WSEncoderDecoder utility, which calls the plug
point when it is enabled. The {custom:alias} tags are displayed
in the configuration documents. The passwords, even though they
are encrypted, are still Base64-encoded. They seem similar to encoded
passwords, except for the tags difference.
- Encrypt any passwords that are in client-side property
files using the PropsFilePasswordEncoder (.bat or .sh) utility.
This utility requires that the properties listed previously
are defined as system properties in the script to encrypt new passwords
instead of encoding them.
- To decrypt passwords from client Java virtual machines
(JVMs), add the properties listed previously as system properties
for each client utility.
- Ensure that all nodes have the custom encryption classes
in their class paths prior to enabling this function. The order
in which enablement occurs is important. When adding a new node to
a cell that contains password encryption, the new node must contain
the custom encryption classes prior to using the addNode command.
Consider the following Network Deployment enablement scenarios:
- The StandAloneProfile profile is encrypting passwords
with a different key prior to federation to a deployment manager cell.
For this scenario, you must uninstall custom password encryption to
ensure that the configuration has {xor} tags preceding the
passwords prior to running the addNode command. The same implementation
of the plug point must be in the /classes directory prior
to running the addNode command, and the proper configuration
properties are set so that the new node can recognize the encrypted
password format of the security.xml file after federation
completes.
- The StandAloneProfile profile does not have password
encryption configured prior to federation to a deployment manager
cell. The same implementation of the plug point must be in the /classes directory
prior to running the addNode command, and the proper configuration
properties are set so that the new node can recognize the encrypted
password format of the security.xml file after federation
completes.
- If enabling custom password encryption in a cell with
multiple nodes present, update the correct configuration properties
and have the custom password encryption implementation class located
on all nodes. Stop all processes in the cell, and then start the deployment
manager. Use the administrative console to edit the security configuration
and then save it. Verify that the passwords are encrypted by looking
at the security.xml file to see if the passwords are preceded
by {custom:alias} tags.
- Run the syncNode command on each node, and start
each one individually. If any nodes fail to start, make sure that
they have custom password encryption enabled properly in each security.xml file
and that the implementation class is in the appropriate /classes directory
for the platform.
Results
Custom password encryption is enabled.