HP Serviceguard Manager manual Access Path, Web Client

Access Path

In order to understand the SgmgrPI Security model, it is best to trace a client request as it enters the system and travels through the components which take part in its processing. Figure 1 below provides a high-level view of these components, their relative positions within the security model, and the path the request takes as it travels through the system:

Figure 1. Access Path

	1	3	Tomcat
	SMH		SgmgrPI
Web	2		4
client
	PAM		5
			smhrun

Serviceguard

Cluster

Serviceguard Node

Path 1: When a user uses a browser to connect to SMH, the connection must be made over a secure HTTP channel, or HTTPS. This will safeguard all the information exchanged between SMH and the remote client. The information exchanged in this channel includes user a logon name and password, session cookies, and eventually, Serviceguard data.

Path 2: After SMH prompts for the user’s credentials over the secure channel (Path 1), it uses the credentials to authenticate the user through the Pluggable Authentication Module (PAM).

Path 3: Authenticated request is forwarded to SgmgrPI for processing. Unix Domain Socket (HP-UX) and HTTPS (LINUX) are used as the communication channel between the SMH process and Tomcat process which hosts SgmgrPI.

Path 4: SgmgrPI spawns a child process to issue Serviceguard CLI commands, but it does so through SMH's secure command, smhrun. SgmgrPI supplies smhrun with the information needed to perform the requested task, which includes the user identity, Serviceguard command, and command parameters.

Path 5: Serviceguard commands operate on the managed cluster as if the commands are issued by a local user physically logged on to one of the Serviceguard node.

The remainder of this paper describes the authentication and authorization process and how the aforementioned components take part in it.