Support for HTTPS in the web service user-defined functions
uses Application Transparent Transport Layer Security (AT-TLS). AT-TLS
is based on z/OS® System SSL,
and it transparently implements Transport Layer Security (TLS) protocols
in the TCP layer of the stack.
About this task
SSL connections make use of public/private key mechanisms
(PKI) for authenticating each side of the SSL session and agreeing
on bulk encryption keys to be used for the SSL session. To use PKI,
public/private key pairs must be generated. In addition, X.509 certificates
(which contain public keys) might need to be created, or certificates
must be requested, received, and managed.System SSL supports the
following two methods for managing PKI private keys and certificates:
- A z/OS shell-based program
called gskkyman. gskkyman creates, fills in, and manages a z/OS file that contains PKI private
keys, certificate requests, and certificates. This z/OS file is called a key database and, by convention,
has a file extension of .kdb.
- The z/OS Security Server
(RACF®) RACDCERT command. RACDCERT
installs and maintains PKI private keys and certificates in RACF.
Procedure
To enable support for HTTPS and AT-TLS:
- Specify the TTLS parameter on the TCPCONFIG statement in
PROFILE.
- To protect TCP/IP connections, you can configure the RACF EZB.INITSTACK.sysname.tcpname
resource in the SERVAUTH class to block all stack access except for
the user IDs that are permitted to use the resource. Refer
to member EZARACF in sample data set hlq.SEZAINST where hlq is the
high level qualifier data set name for TCPIP data sets.
- Configure AT-TLS policy rules. The policy agent
provides AT-TLS policy rules to the TCP/IP stack. Each rule defines
a set of security conditions that the policy agent compares to the
conditions at the connection that it is checking. When the policy
agent finds a match, it assigns the connection to the actions that
are associated with the rule.
- Create a client keyring for each client with necessary
certification authority certificates. The name of the client
keyring should match the name that is provided for the keyring in
the policy configuration file.
If the web service user-defined functions
are defined with DB2® security,
the authorization ID that is associated with the WLM-established address
space where the user-defined functions are defined must have all the
necessary permissions to access the keyring.
- Stop and start TCP/IP stacks.
- Start the policy agent. Verify that message EZZ4248E is
released from the console.
Results
Setup is complete and you can run the web service user-defined
functions with HTTPS.