HP Serviceguard Manager Plug-in Security Whitepaper, March 2009

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 t
a
k
es
as it
travel
s
through the system
:
Figure 1.
Access Path
Path 1:
When a user uses a browser t
o connect to SMH,
t
he 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 cooki
es, and eventually, Serviceguard data.
Path 2:
After SMH prompts for
the
user
’
s
credential
s
over the secure channel (Path 1), it uses the
credential
s
to authenticate the user through the Pluggable Authentication Module (PAM).
Path 3:
Authenticated request is f
orwarded 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 command
s, but it does so through
SMH's secure command, smhrun. SgmgrPI supplies smhrun with the information needed to
perform the requested task, which include
s
the user identity, Serviceguard command, and
command parameters.
Path 5:
Serviceguard commands operat
e on the managed cluster as if the commands are issued by a
local user physically logged on to one of the Serviceguard node.
The remain
d
er
of this paper describes the authentication and authorization process and how the
aforementioned components take part
in it.
Web
client
SMH
SgmgrPI
smhrun
PAM
Tomcat
1
2
3
4
5
Serviceguard
Cluster
Servicegu
ard Node