An Introduction to Security in a CSM 1.3 for AIX 5L Environment

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 node’s 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.