When CICS® is
an HTTP server, the CICS system must be protected from access by unauthorized
users. If a system is not properly protected, users might be able to access
confidential data, or obstruct the system to cause denial of service to other
users.
Security for inbound ports
Each port used for CICS Web
support is defined by a TCPIPSERVICE resource definition. The TCPIPSERVICE
definition specifies security options for the port, including whether or not
SSL is used, and the level of authentication that is requested from clients.
Creating TCPIPSERVICE resource definitions for CICS Web support explains how to create these definitions.
To help keep ports secure, bear these points in mind:
- Specify the MAXDATALEN attribute on every TCPIPSERVICE definition. This
option limits the maximum amount of data that CICS will accept for a single request,
and it helps to defend CICS against denial of service attacks involving the
transmission of large amounts of data.
- Use Secure Sockets Layer (SSL) wherever you want to ensure that your interaction
with the Web client remains confidential and cannot be intercepted by a third
party. The use of SSL is particularly important where confidential data is
being transmitted, or where authorization such as a user ID and password is
being passed to the server. SSL with CICS Web support explains
how SSL is used with CICS Web support.
If you do experience unusual activity on one or more of your CICS Web
support ports, you can use CICS system commands to shut down CICS Web support
at different levels (a single request, a virtual host, a port, or the whole
of CICS Web
support), without shutting down the CICS system. Rejecting HTTP requests explains
how to do this.
URIMAP resource definitions name either HTTP or HTTPS
(HTTP with SSL) as the scheme for the request. A URIMAP specifying the HTTP
scheme accepts Web client requests made using either the HTTP scheme, or the
more secure HTTPS scheme. A URIMAP specifying the HTTPS scheme accepts only
Web client requests made using the HTTPS scheme.
When a URIMAP definition
with HTTPS as the scheme matches a request that a Web client is making, CICS checks
that the inbound port used by the request is using SSL. If SSL is not specified
for the port, the request is rejected with a 403 (Forbidden) status code.
When the URIMAP definition applies to all inbound ports, this check ensures
that a Web client cannot use an unsecured port to access a secured resource.
No check is carried out for a URIMAP definition that specifies HTTP as the
scheme, so Web clients can use either unsecured or secured (SSL) ports to
access these resources.
Resource level security
To police access to CICS Web
support in general, you should request identification from each user that
makes an HTTP client request, and authenticate the identity stated by the
user. Authentication and identification for HTTP clients explains how this can be achieved
for CICS as
an HTTP server.
When you have obtained an authenticated user ID for
the Web client, this ID can be used for resource level security. Resource
level security is not applied to items delivered as a static response (that
is, CICS document
templates and HFS files delivered directly from a URIMAP definition). If you
need to apply access controls based on a user ID to an item delivered in this
way, you need to deliver the material as an application-generated response
instead (that is, by using an application program).
For an application-generated
response, the user ID of the Web client is applied to the alias transaction
that is used in processing the request. Alias transactions are defined by
TRANSACTION resource definitions, and the CICS-supplied default is CWBA. They
run under the user ID that has been supplied by, or assigned to, the Web client
making the request. This user ID must have authority to:
- Attach the alias transaction for the CICS application that provides the HTTP
response.
- Access any CICS resources
used by the alias transaction (if resource security is specified for the alias
transaction).
- Access any CICS system
programming commands used by the alias transaction (if command security is
specified for the alias transaction). These system programming commands would
be used in the user-written application program that produces the response.
CICS system
security
A number of components such as application programs and
resource definitions are used to control CICS Web support. These components are
listed in Components of CICS Web support.
CICS system components
cannot be accessed directly by a Web client in the course of a normal request,
unless you have Web-enabled a CICS-supplied transaction that can issue CICS system
commands. However, as with any other CICS resource, it is important to protect
these components from modification by unauthorized users. For example, a user
with access to the TCPIPSERVICE definition for a port could remove the requirement
for a Web client to use SSL or to provide identification.
In some cases,
you might need to set up additional authorities to allow access to authorized
users:
- For URIMAP definitions, additional authority might be required to set
a user ID for the Web client. If surrogate user checking is enabled in the CICS region
(with XUSER=YES specified as a system initialization parameter), CICS checks that
the user ID used to install the URIMAP definition, is authorized as a surrogate
of the user ID specified for the USERID attribute.
- Document templates can be used to produce the body of a response from CICS as
an HTTP server, or the body of a request from CICS as an HTTP client. They are defined
by DOCTEMPLATE resource definitions. If the document templates are stored
in partitioned data sets, the CICS region user ID must have READ authority
for the data set.
- z/OS® UNIX Systems
Services HFS files can be used to produce the body of a static response from CICS as
an HTTP server. They can either be specified under their own names, or defined
by DOCTEMPLATE resource definitions. The CICS region must have permissions to access z/OS UNIX,
and it must have permission to access the HFS directory containing the file,
and the file itself. Java™ Applications
in CICS explains
how to grant these permissions.