448 Patterns: Implementing Self-Service in an SOA Environment
򐂰 CICS multi-region operation
CICS multi-region operation (MRO) enables CICS systems that are running in
the same MVS image, or in the same MVS sysplex, to communicate with
each other. MRO does not support communication between a CICS system
and a non-CICS system such as IMS. MRO is a widely used technique that is
a central part of CICS scalability.
򐂰 CICS distributed program link
CICS distributed program link (DPL) enables CICS application programs to
run programs residing in other CICS regions by shipping program-control
LINK requests. An application can be written without regard for the location of
the requested programs. It simply uses program-control LINK commands in
the usual way. Entries in the CICS program definition tables allow the system
programmer to specify that the named program is not in the local region (s the
client region), but in a remote region (server region).
An ECI request from CICS TG in either zSeries or a distributed environment
comes to an enterprise CICS program as a DPL request. The request can be
routed to a CICS program that resides in any CICS region in a sysplex.
12.6.4 Security considerations
The J2EE Connector Architecture security contract extends the J2EE security
model to provide secure connections to EIS. To create a connection to an EIS,
there must be some form of signing on to the EIS, to authenticate the connection
requester. Re-authentication can also take place if supported by the EIS. This
occurs when the security context is changed after a connection is made. (For
example, connection pooling could cause a re-authentication when the
connection is redistributed.)
Performing the sign-on generally involves one or more of the following steps:
1. Determine the resource principal under whose security context the
connection will be made.
2. Authenticate the resource principal.
3. Establish secure communications.
4. Determine authorization (access control).
The application component requests that a connection be established under the
security context of a resource principal. For example, a CICS ECI application can
specify the user name and password to the resource adapter that signs on to
CICS to invoke the CICS program. Once a connection is established
successfully, all application-level invocations to the EIS instance using the
Chapter 12. J2EE Connector Architecture scenario 449
connection happen under the security context of the resource principal. The
application component has the following two choices related to EIS sign-on:
򐂰 Container-managed sign-on
The deployer sets up the resource principal and EIS sign-on information. For
example, the deployer sets the user name and password for establishing a
connection to an EIS instance.
򐂰 Component-managed sign-on
Application code in the component performs the sign-on to an EIS by
explicitly specifying the security information for a resource principal.
If you choose component-managed sign-on, you need to specify a user name
and password at an instance of ConnectionSpec. Example in design describes
the way to use ConnectionSpec when used with the CICS ECI resource adapter.
WebSphere Application Server V6.0 supports component-managed sign-on
(Option C in the J2EE Connector Architecture Specification) which requires the
component to pass user ID and password credentials through the
ConnectionSpec to CICS. If the credentials in the ConnectionSpec are not set,
then the credentials in the ManagedConnectionFactory are used to authenticate
to CICS. WebSphere Application Server V6.0 also supports container-managed
sign-on with the use of a user ID and password credential (Option A in the J2EE
Connector Architecture Specification).
This section provides some security guidelines for J2EE Connector-enabled
applications and the underlying CICS environment. We look at the following
topics:
򐂰 Signing on to the enterprise tier
򐂰 SSL encryption support
򐂰 CICS security
Signing on to the enterprise tier
The J2EE Connector Architecture provides security contacts for an application
component. A user ID and password can be specified by the application
component, or it can be specified in the deployment descriptor when the security
contract is managed by the EJB container.
Authentication can be performed against the Resource Access Control Facility
(RACF®) using user ID and password authentication in the CICS TG for z/OS, by
setting the variable AUTH_USERID_PASSWORD=YES in the ctgstart script.

Get Patterns: Implementing Self-Service in an SOA Environment now with O’Reilly online learning.

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