40 Security in WebSphere Application Server Version 6.1 and J2EE 1.4 on z/OS
4. RACF verifies the validity of the user ID and positively replies to LDAP.
5. LDAP also positively replies to RPSS.
6. RPSS then forwards the HTTP request to the Web server in z/OS via a
secure connection if SSL is enabled.
7. The Web server receives the HTTP request and passes it on to WAS.
8. If the Since single sign-on (SSO) mechanism is turned on, WAS does not
need to do another authentication, but queries RACF to see whether the user
is authorized to execute the work.
9. RACF checks whether the user is authorized to execute the code (method).
10.If the response from RACF is positive, the connection is complete, the work is
done, and a reply is sent back to the client with the results of the operation.
Configuration tasks
Here we provide the 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:
򐂰 Enable single sign-on (SSO) via the WebSphere Administrative console as
follows: secure administration, applications, and infrastructure > single
sign-on (SSO).
򐂰 Set up LDAP with SDBM configuration.
򐂰 Add user ID/password of client to RACF.
򐂰 Define EJBROLES in RACF to enable application authorization.
򐂰 Configure SSL in each endpoint.
For more information see:
򐂰 WebSphere Application Server on z/OS and Security Integration, REDP-4161
򐂰 Secure Production Deployment of B2B Solutions using WebSphere Business
Integration Connect, SG24-6457
2.5.3 Scenario 3 - J2EE client authentication using CSIv2
Our objective here is to demonstrate a simple security aspect between a J2EE
client and a J2EE application deployed to WAS on z/OS. This design is intended
to assist users who are beginners to the J2EE (IIOP) communication in how to
secure IIOP using CSIv2 security. A simple JavaBean program can be
developed for the client to invoke a method (an EJB) on z/OS and verify that the
connection is secured with CSv2 protocol.
Chapter 2. WebSphere security design 41
Figure 2-7 is very simple. The J2EE client communicates directly with the
application server on z/OS using the J2EE Remote Method Invocation over
Internet Inter-Orb Protocol (RMI-IIOP). There is no HTTP server involved. Again,
the user registry used in WAS is LocalOS (SAF-based).
Figure 2-7 Scenario 3 - J2EE client authentication with CSIv2
At the WAS V6.1 level, there is only one available protocol for communicating
securely between a J2EE client and WAS for z/OS:
Common Secure
Interoperability Version 2
(CSIv2). CSIv2 is a standard protocol that should be
used for any new implementations. CSIv2 enables user ID propagation between
J2EE environments. Using CSIv2, this user ID can be an LDAP distinguished
name, a client certificate, a basic user ID, and so on. The user ID that is retrieved
from the CSIv2 protocol can either be a RACF user ID or be mapped to a RACF
user ID. The transport layer can be secured using SSL/TLS.
Keep in mind that this design does not cover the back-end systems, such as
CICS, IMS, and DB2. Connectivity to the back-end systems is addressed
Furthermore, the data integrity and confidentiality aspect of the security is
handled by CSIv2, which we assume that the reader is aware of.
Logical flow
Data integrity and confidentiality is implied by the fact that the connection is over
CSIv2/SSL. The flow deals mostly with authentication and to some degree

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.