Network Deployment (Distributed operating systems), v8.0 > Reference > Administrator best practices
Security considerations when registering a base Application Server node with the admin agent
You might decide to centralize the control of your stand-alone base application servers by registering them with the admin agent. If your base application server 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 stand-alone base node and convert it into one that is managed by the admin agent. The main parameter of the registerNode command is profilePath, which specifies where on the local machine the admin agent can find the node. The portsFile parameter contains keys to determine which ports the admin 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 admin agent itself. It is used to register a node with an admin agent. It is required that the admin 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 dmgr 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 admin 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 admin agent. The signers are stored in the target profiles trust store using the alias prefix "agent_signer", and are stored in the admin 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 admin 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 admin agent. The signers are stored in the target profile's trust store using the alias prefix "agent_signer", and are stored in the admin agents trust store using the alias prefix " <profileName>_signer".
In addition, the registration process stores all root certificate signers (SSL and RSAToken) from the admin 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 admin agent and base profile. The base node's configuration is retained, except that it is marked as not registered with an admin 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, you need to explicitly specify administrative 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 administrative 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 admin agent, a node must have administrative security enabled or disabled.
- Once a node is registered, you 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 admin agent provides a way of managing additional function while preserving security.
Overview and new features for securing applications and their environment