Security considerations when registering a base Application Server node with the administrative agent

Security considerations when registering a base Application Server node with the administrative agent

We might decide to centralize the control of the stand-alone base appservers by registering them with the administrative agent. If the base appserver is currently configured with security, some issues require consideration. These security considerations apply to the use of the registerNode command and the deregisterNode command.
The goal of the registerNode command is to take a standalone base node and convert it into one that is managed by the administrative agent. The main parameter of the registerNode command is profilePath, which specifies where on the local machine the administrative agent can find the node. The portsFile parameter contains keys to determine which ports the administrative agent listens to, on behalf of the base node. The format is the same as that for manageProfiles command line.
The registerNode command is run from the administrative agent itself. It is used to register a node with an administrative agent. It is required that the administrative agent be on the same system as the node being registered. The registerNode command is only valid on a base node. If a node has been federated to a deployment manager the registerNode command fails with an error.
First, the exchange signers process for profile registration processes the default secure sockets layer (SSL) configuration, in which it obtains the root certificate signers from the NodeDefaultRootStore of the administrative agent and stores them in the NodeDefaultTrustStore of the target profile. Next, the process obtains the root certificate signers from the target profile's NodeDefaultRootStore and stores them in the NodeDefaultTrustStore of the administrative agent. The signers are stored in the target profiles trust store using the alias prefix "agent_signer", and are stored in the administrative agents trust store using the alias prefix "<profileName>_signer".
Next, the exchange signers process for profile registration processes the RSAToken authentication configuration, in which it obtains the root certificate signers from the NodeRSATokenRootStore of the administrative agent and stores them in the NodeRSATokenTrustStore of the target profile. Next, the process obtains the root certificate signers from the target profile's NodeRSATokenRootStore and stores them in the NodeRSATokenTrustStore of the administrative agent. The signers are stored in the target profile's trust store using the alias prefix "agent_signer", and are stored in the administrative agents trust store using the alias prefix "<profileName>_signer".
In addition, the registration process stores all root certificate signers (SSL and RSAToken) from the administrative agent into the target profile's client trust store (ClientDefaultTrustStore by default).
The deregisterNode command activates the de-registration process which removes all signers exchanged during the registration process from both the administrative agent and base profile. The base node’s configuration is retained, except that it is marked as not registered with an administrative agent. This command is only valid for a previously registered base node.

The following issues require consideration when running the registerNode command with security:

When attempting to run system management commands such as the registerNode command, we need to explicitly specify admin credentials to perform the operation. The registerNode command accepts -username and -password parameters to specify the user ID and password, respectively.
The user ID and password specified must be for an administrative user; for example, a user that is a member of the console users with Administrator privileges or the admin user ID configured in the user registry. An example of the registerNode command follows:
registerNode -profilePath /WebSphere/AppServer/profiles/default -host localhost -connType SOAP -port 8877 -username WSADMIN -password ADMINPWD
Before registering to an administrative agent, a node must have administrative security enabled or disabled.
Once a node is registered, we cannot enable or disable the administrative security for that node (or any other registered node) until the node has been de-registered.

Proper understanding of the security interactions between distributed servers greatly reduces problems that are encountered with se cure communications. Security adds complexity because additional function needs management. The administrative agent provides a way of managing additional function while preserving security.

Related concepts

New features for securing applications and their environment