Chapter 2. WebSphere security design 43
Here we provide a list of tasks that need to be done to configure security for this
design. This list may not be complete, but the main task items are as follows:
Add the user ID/password of client to RACF.
Define EJBROLES in RACF to enable application authorization.
Enable CSIv2 (inbound/outbound) via the WebSphere administrative console
CSIv2 is considered enabled on the client with the existence of the
com.ibm.CORBA.ConfigURL Java property. If the property is not specified or
the property does not exist, CSIv2 is not enabled.
IBM Redbooks Technote: Configuration of WebSphere Application Server
Security, TIPS0206, at:
IBM Education Assistant at:
WebSphere Application Server on z/OS and Security Integration, REDP-4161
2.5.4 Scenario 4 - J2EE server authentication using CSIv2
The objective of this design is to expand the previous design that dealt with a
J2EE client directly connecting to z/OS. In this design the J2EE client is attached
to an intermediate box that has a J2EE server running on it. The main goal with
this design is to show users how authentication can be done using an identity
assertion mechanism. Once the client is authenticated by the J2EE server
running machine, there is no need to re-authenticate the client in WAS for z/OS,
if an identity assertion mechanism is enabled.
This is the most commonly used J2EE application connectivity, where two J2EE
servers talk to each other over a secure connection using CSIv2.
The integrity and confidentiality of data aspect of the security has been taken
care of by CSIv2 internally and there is no need to describe it.
44 Security in WebSphere Application Server Version 6.1 and J2EE 1.4 on z/OS
Figure 2-9 shows what this design is all about. The client to the J2EE server
connection can be secured or not secured, but the J2EE server to WAS z/OS is a
secure connection. The authentication registry being used in this case is LDAP
attached to RACF via SDBM.
Figure 2-9 Scenario 4 - J2EE server authentication using CSIv2
The Common Secure Interoperability Version 2 protocol is designed to exchange
its protocol elements in the service context of
General Inter-ORB Protocol
(GIOP) request and reply messages that are communicated over a
connection-based transport. The protocol is intended for use in environments
where transport layer security, such as that available through Secure Sockets
Layer (SSL) and Transport Layer Security (TLS), is used for providing message
protection (that is, integrity and or confidentiality) and server-to-client
authentication. The protocol provides client authentication, delegation, and
privilege functionality that might be applied to overcome security deficiencies in
an underlying transport.
CSIv2 authentication protocols used by WebSphere Application Server are
add-on Interoperable Inter-ORB Protocol (IIOP) services. IIOP is a
request-and-reply communications protocol used to send messages between
two object request brokers (ORBs).
For each request made by a client ORB to a server ORB, an associated reply is
made by the server ORB back to the client ORB. Prior to any request flowing, a
connection between the client ORB and the server ORB must be established
over secured TCP/IP transport (SSL is a secure version of TCP/IP).
An identity assertion is a way for one server to trust another server without the
need to re-authenticate or re-validate the originating client. In this case, WAS for