Security considerations specific to a multi-node or process Network Deployment environment

Before you begin

WebSphere Application Server Network Deployment allows for centralized management of distributed nodes and application servers. This inherently brings complexity, especially when security is included into the mix. Because everything is distributed, security plays an even larger role in ensuring that communications are appropriately secure between applications servers and node agents, and between node agents (a node specific configuration manager) and the Deployment Manager (a domain-wide, centralized configuration manager). The following issues should be considered when operating in this environment, but preferably prior to going to this environment.

Because the processes are distributed, the authentication mechanism that must be used is LTPA. The LTPA tokens are encrypted and signed and therefore, forwardable to remote processes. However, the tokens have expirations. The SOAP connector (the default connector) used for administrative security does not have retry logic for expired tokens, however, the protocol is stateless so a new token is created for each request (if there is not sufficient time to execute the request with the given time left in the token). An alternative connector is the RMI connector, which is stateful and has some retry logic to correct expired tokens by resubmitting the requests after the error is detected. Also, because tokens have time specific expiration, the synchronization of the system clocks are crucial to the proper operation of token based validation. If the clocks are off by too much (approximately 10-15 minutes), you could easily run into unrecoverable validation failures which would have been avoided by having them in sync. Verify that the clock time, date, and time zones are all the same between systems. It is acceptable for nodes to be across time zones provided that the times are correct within the time zones (for example, 5 PM CST = 6 PM EST, and so on).

Why and when to perform this task

The following are issues to consider when using or planning for a Network Deployment environment.

Steps for this task

  1. When attempting run system management commands such as stopNode, you need to explicitly specify administrative credentials to perform the operation. Most commands accept -username and -password parameters to specify the user ID and password, respectively. The user ID and password that are specified should be an administrative user, for example, a user who is a member of the console users with Operator or Admistrator privileges or the administrative user ID configured in the user registry. An example for stopNode, stopNode -username user -password pass.
  2. Verify that the configurations at the node agents are always synchronized with the Deployment Manager prior to starting or restarting a node. To manually get the configuration synchronized, issue the syncNode command from each node that is not synchronized. To synchronize the configuration for node agents that are started, click System Administration > Nodes and select all started nodes. Click Synchronize.
  3. Verify that the clocks on all systems are in sync including the time zone, time and date. If they are out of sync, the tokens will expire immediately when they reach the target server due to the time differences.
  4. Verify that the LTPA token expiration period is long enough to complete your longest downstream request. Some credentials are cached and therefore the timeout does not always count in the length of the request. There is a LTPA token expiration cushion period for Web requests so that the LTPA token has sufficient time to make a downstream request. The cushion is 20 percent of the LTPA expiration period up to a maximum of ten minutes (configurable by a system property com.ibm.ws.security.cacheCushionMax specified in minutes) and usually not below the ORB request time-out (default 3 minutes, but the minute value is configurable by a system property com.ibm.ws.security.cacheCushionMin specified in minutes). When considering the actual expiration period of the LTPA token, you should consider this cushion. This helps prevent downstream expirations occurring in EJB servers.
  5. The administrative connector used by default for system management is SOAP. SOAP is a stateless HTTP protocol. For most situations, this connector is sufficient. When running into a problem using the SOAP connector it might be desirable to change the default connector on all servers from SOAP to RMI. The RMI connector uses CSIv2, a stateful or interoperable protocol, and can be configured to use identity assertion (downstream delegation), message layer authentication (BasicAuth or Token), or client certificate authentication (for server trust isolation). To change the default connector on a given server, go to the Administration Services in Additional Properties for that server.
  6. It is possible that the sending process might not supply a credential to the receiving process. Typically the causes for this problem are:

    • The sending process has security disabled while the receiving process has security enabled. This typically indicates one of the two processes are not in sync with the cell.

      Note: Having security disabled for a specific application server should not have any effect on administrative security.

    • The clocks between the systems are not synchronized; thus invalidating the credential tokens immediately. Verify that the time, date, and time zones are consistent between the two machines. An error similar to the following might occur:
      [9/18/02 16:48:23:859 CDT] 3b9cef35 RoleBasedAuth A SECJ0305I: Role 
      based authorization check failed for security name <null>, 
      accessId NO_CRED_NO_ACCESS_ID while invoking method 
      propagateNotifications:[Ljavax.management.Notification; on resource 
      NotificationService and module NotificationService.

  7. When getting the following error message, you should validate that the clocks are synchronized between all servers within the cell, and the configurations are synchronized between all nodes and the Deployment Manager.
    An error similar to the following might occur:
    [9/18/02 16:48:22:859 CDT] 3bd06f34 LTPAServerObj E SECJ0372E: 
    Validation of the token failed.

Results

Proper understanding of the security interactions between distributed servers will greatly reduce problems encountered with secure communications. Security adds complexity because additional function needs to be managed. For security to work properly, it needs thorough consideration during the planning of your infrastructure. Hopefully, this document will help 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 find additional information about the problem. When trace is need 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:   tsecesecarun
Last updated: Jun 21, 2007 4:55:42 PM CDT    WebSphere Application Server Network Deployment, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tsec_esecarun.html

Library | Support | Terms of Use | Feedback