Security considerations when adding a Base Application Server node to Network Deployment

Before you begin

At some point, you might decide to centralize the configuration of your stand-alone base application servers by adding them into a Network Deployment cell. If your base application server is currently configured with security, there are some issues to be considered. The major issue when adding a node to the cell is whether the user registries between the base application server and the Deployment Manager are the same. When adding a node to a cell, the newly federated node automatically inherits the user registry (LocalOS, LDAP or Custom), authentication mechanism (LTPA or ICSF), and authorization setting (WebSphere bindings or System Authorization Facility (SAF) EJBROLE profiles) of the existing Network Deployment cell.

Another major issue is the SSL public-key infrastructure. Prior to performing addNode with the Deployment Manager, verify that addNode can communicate as an SSL client with the Deployment Manager. This requires that the addNode truststore (configured in sas.client.props) contains the signer certificate of the Deployment Manager personal certificate as found in the keystore (specified in the administrative console).

Why and when to perform this task

The following are other issues to consider when running the addNode command with security:

Steps for this task

  1. When attempting to run system management commands such as addNode, you need to explicitly specify administrative credentials to perform the operation.
    The addNode command accepts -username and -password parameters to specify the userid and password, respectively. The user ID and password, which are specified should be an administrative user, for example, a user that is a member of the console users with Operator or Admistrator privileges or the admistrative user ID configured in the User Registry. An example for addNode, addNode CELL_HOST 8879 -includeapps -username user -password pass. -includeapps is optional, but this option attempts to include the server applications into the Deployment Manager. The addNode command might fail if the user registries used by the WebSphere Application Server and the Deployment Manager are not the same. To correct this problem, either make the user registries the same or turn off security. If you change the user registries, remember to verify that the users to roles and groups to roles mappings are correct. See addNode command for more information on the addNode syntax.

    Note that you might also run the addNode command using the Customization Dialog.

  2. Adding a secured remote node through the administrative console is not supported. You can either disable security on the remote node before performing the operation or perform the operation from the command line using the addNode script.
  3. Before running the addNode command, you must verify that the truststore files on the nodes communicate with the keystore files and SAF Keyring owned by the Deployment Manager and vice versa.
    If you have generated the certificates for deployment manager using the same certificate authority as you used for the node agent process, this will be successful. Note that the following SSL configurations must contain keystores and truststores that can interoperate:
    • System SSL repertoire specified in the Administrative Console using System Administration > Deployment Manager > HTTP Transports > sslportno > SSL
    • SSL repertoire for appropriate JMX Connector if SOAP is specified System Administration > dmgr > Administration Services > JMX Connectors > SOAPConnector > Custom Properties > sslConfig
    • SSL repertoire specified in NodeAgent System Administration > Node agents > NodeAgent Server > Administration Services > JMX Connectors > SOAPConnector > Custom Properties > sslConfig
  4. After running addNode, the application server is in a new SSL domain. It might contain SSL configurations that point to keystore and truststore files that are not prepared to interoperate with other servers in the same domain. Consider which servers will be intercommunicating and ensure that the servers are trusted within your truststore files.

Results

Proper understanding of the security interactions between distributed servers greatly reduces problems encountered with secure communications. Security adds complexity because additional function needs to be managed. For security to function, it needs thorough consideration during the planning of your infrastructure. This document helps to reduce the problems that could occur due to inherent security interactions.

What to do next

When you have security problems related to the WebSphere Application Server Network Deployment environment, check the Troubleshooting security configurations section to see if you can get information about the problem. When trace is needed to solve a problem, because servers are distributed, quite often it is required to gather trace on all servers simultaneously while recreating the problem. This trace can be enabled dynamically or statically, depending on the type problem occurring.



Searchable topic ID:   tsecewac
Last updated: Jun 21, 2007 9:56:50 PM CDT    WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/tsec_ewac.html

Library | Support | Terms of Use | Feedback