Chapter 3. Cluster Systems Management security infrastructure 33
The following steps are done by definenode:
1. The CSM management server adds a node definition to the CSM
management cluster and database by using its RMC client API.
2. Within the node definition, the attribute AllowManageRequest for this node
definition is set to 1.
The following steps are done by
updatenode:
1. Through a remote shell command issued to the managed node, CSM creates
the management server resource definition (IBM.ManagementServer) and
defines the node as a managed node by using its RMC client API. The node
RMC calls the management server RMC and sends a request to be
managed. RMC exchanges credentials, for example, connectivity node name,
host name, public key, node identifier, and so on.
2. The management server uses an unauthenticated request to the node in
order to retrieve the public key of that node, and then it stores the public key
and the host name in the trusted host list (THL) using its ctcasd API.
3. The management server sends the management node host name,
management node identifier, and the management nodes public key to the
managed node.
4. The node stores the public key and host name of the management server in
its THL file.
5. The managed node RMC updates its ACL files to allow the root@nodeid and
root@management_server_hostname identities read and write access to all
resources. All other users get read-only access.
3.3.3 Requesting access to resources
The following steps show the communication flow between the management
server and a node requesting access to a resource. Figure 3-3 shows a simple
illustration of the given example.
34 An Introduction to Security in a CSM 1.3 for AIX 5L Environment
Figure 3-3 Example of CSM security communication
The communication flow between the management server and a node
requesting access to a resource is as follows:
1. CSM on node1 wants to access a resource on node2. Because CSM uses
RMC client APIs, CSM is a client that has specific process properties. In this
case, the RMC daemon on node2 acts as a server that accepts or rejects the
request from the client.
2. The client on node1 needs to create a security context to be able to
communicate with RMC on node2. This is done by calling an RMC API
function.
3. RMC on node1 calls CtSec to initiate a security context. CtSec inherits
properties of the client that initiates the security context (for example, the user
of the calling process).
4. RMC on node1 calls the MAL component to initiate the security context.
5. MAL on node1 calls the MPM to initiate the security context.
6. UNIX MPM on node1 initiates the generation of credentials for the client by
using HBA/ctcasd.
7. HBA/ctcasd on node1 also generates a session key that can be used for
further data transfers.
RSCT
node1 (RMC client)
Cluster Security Services (ctSec)
)
Mechanism Abstract Layer (MAL)
HBA (ctcasd)
UNIX MPM
Identity Mapping Service (IDM)
CSM
RMC API
RSCT
node2 (RMC server)
Cluster Security Services (ctSec)
)
Mechanism Abstract Layer (MAL)
HBA (ctcasd)
UNIX MPM
Identity Mapping Service (IDM)
RMC Daemon
RM
TCP/IP Socket
Comm.

Get An Introduction to Security in a CSM 1.3 for AIX 5L Environment now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.