46 Security in WebSphere Application Server Version 6.1 and J2EE 1.4 on z/OS
6. The J2EE server passes the client request to WAS on z/OS via IIOP (GIOP)
with the security credentials.
7. At this stage, authentication is complete, the requested object is located, and
WAS checks to see whether the user is authorized to access and execute the
method indicated in the object. To verify authorization, WAS queries RACF.
8. RACF responds to WAS positively or negatively.
9. If the response from RACF is positive, then the method is executed and
results are sent back to the J2EE server. If the response from RACF is
negative, the method is not executed.
10.Finally, the outcome of the original operation is sent back to the client.
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 as follows:
Add the user ID/password of the client to RACF.
Define EJBROLES in RACF to enable application authorization.
Enable CSIv2 (inbound/outbound) via the admin console on z/OS.
Enable identity assertion via the WebSphere administrative console on z/OS.
IBM Redbooks Technote: Configuration of WebSphere Application Server
Security, TIPS0206, at:
IBM Education Assistant at:
2.5.5 Scenario 5 - JCA custom principal mapping
WAS Version 6.0.x supports the J2EE Connector architecture (JCA) Version 1.5
specification, which provides new features such as the inbound resource
The demand to do more business online has forced companies to find ways to
integrate their back-end systems such as CICS, IMS, and DB2 to the Internet. To
integrate the back-end system to the Internet, one of the available solutions is to
use J2C connectors. But with the J2C security architecture integrated with the
Chapter 2. WebSphere security design 47
back-end rigid security system, accessing applications running on these systems
may not be trivial.
Log in to any of the back-end systems via the Internet t requires the user provide
to his user ID/password several times. The requirement to re-authenticate a user
is repetitive to some clients. In addition, it is not efficient to use many login
passwords to access a single application in a system. The requirement to
re-authenticate users must be minimized to a single sign-on, or at the most two
The Java Connector Architecture (JCA) 1.5 has enhanced its connection factory
specification to use JAAS for customizing principal login capability. This
enhanced custom mapping capability allows users accessing the back-end
system through the connectors to not have to resubmit their user ID/password
From a security perspective, WebSphere Application Server Version 6.0.x
provides an enhanced custom principal and credential mapping programming
interface and custom mapping properties at the resource reference level.
Therefore, our objective is to describe a scenario that can be used for
implementing J2C custom principal mapping.
Figure 2-11 to shows J2C custom principal mapping.
Figure 2-11 Scenario 5 - JCA custom principal mapping authentication
SAF user ID /