Chapter 9. Security attribute propagation and CSIv2 309
9.3.3 CSIv2 standard identity assertion in action
During a CSIv2 identity assertion between an upstream server (outbound server)
and a downstream server (inbound server), the following happens:
򐂰 The outbound server authenticates to the inbound server to establish trust
with one of the following mechanisms:
Client certificate authentication
The outbound server’s client certificate must be verifiable by the inbound
server. The client certificate authority must be connected to the inbound
server’s keyring. The outbound server’s certificate must be mapped to an
identity in the inbound server registry.
Basic authentication
The outbound server identity and password must be in the inbound
servers registry.
򐂰 The outbound server provides the attribute layer asserted identity only with no
password. This identity can be a RACF ID, an LDAP DN, a certificate, and so
on.
򐂰 The inbound server receives the outbound server identity and the asserted
identity.
򐂰 The inbound server checks whether the outbound server (from the outbound
server identity) is in its list of trusted servers. If so, it authenticates the
upstream server. You can use the System Authorization Facility (SAF) CBIND
class to indicate that a process is trusted to assert identities to WebSphere
Application Server for z/OS.
򐂰 The inbound server accepts the asserted identity and creates credentials by
querying the registry. No validation is performed on the asserted identity (no
password, token, and so on).
For CSIv2 stateful connections, this checking is done only once. All subsequent
requests are made through a session ID.

Get Security in WebSphere Application Server V6.1 and J2EE 1.4 on z/OS now with O’Reilly online learning.

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