Security
This chapter introduces the security considerations when connecting applications to CICS programs with CICS Transaction Gateway (CICS TG). It then describes how the CICS TG addresses the issues of authentication, authorization, data integrity, and confidentiality. It also examines how CICS and CICS TG work together with an external security manager, such as Resource Access Control Facility (RACF), to provide these facilities. Details are included that describe the mechanisms used to secure connections and to transmit security credentials to the CICS system.
This chapter covers the following topics:
8.1 Security basics
Effective identity management, authorization, and access control capabilities are the essential elements of a comprehensive enterprise security program. These security services are necessary to control the access to resources and sensitive information within the Information Technology (IT) environment.
8.1.1 The components of a security system
A complete security system puts the necessary infrastructure in place to provide a core set of capabilities:
•Identification
•Authentication
•Authorization
•Confidentiality
•Auditing
•Nonrepudiation
This section describes the purpose of each capability, and provides some context within a typical CICS system.
Identification
This is the ability to assign an identity to the entity accessing the system. Typically, the identity is used to control access to resources. Depending on the security model in which the identification is performed, the identity can be called a user ID, a UID, or a principal.
In general, a CICS user is an entity (a person or a program) that is identified by a user identifier (or user ID). All CICS users must be defined to the External Security Manager (ESM). When the security manager is RACF, information about each user is stored in a user profile.
Authentication
Authentication is the process of validating the identity claimed by the user. Authentication is performed by verifying the authentication information provided by the claimed identity. The authentication information is generally referred to as the accessor’s credentials. A credential can be the accessor’s name and password or it can be a token provided by a trusted party, for example, a Kerberos ticket or an X.509 certificate.
CICS supports several schemes for authenticating users. In many cases, the user’s authenticity is verified by checking a password or password phrase supplied by the user. Depending on topology, authentication can be based on the user ID passed with the External Call Interface (ECI) request, a Secure Sockets Layer (SSL) client certificate, or a distributed identity (identity propagation).
Authorization
Authorization is the process of checking whether an identity, which has already been authenticated, must be provided access to a resource that it is requesting. A typical implementation of authorization is to pass a security context, which contains the identity that has been authenticated, to the access control mechanism.
In conjunction with the ESM, CICS provides a variety of security and control mechanisms. These mechanisms can limit the activities of CICS users to only those functions that any particular individual user is authorized to use. CICS provides three types of authorization checks to protect its applications, the resources they use, and the operational environment:
1. Transaction security ensures that users that attempt to run a transaction are entitled to do so.
2. Resource security ensures that users who use CICS resources are entitled to do so.
3. Command security ensures that users who use CICS system programming commands are entitled to do so.
To provide the necessary security for your CICS systems, CICS uses the Multiple Virtual Storage (MVS) System Authorization Facility (SAF) to route authorization requests to an ESM, such as RACF, at appropriate points within CICS transaction processing. The user’s identity is passed on this call and the ESM return code indicates whether the user is authorized to perform that function.
Confidentiality
Confidentiality ensures that an unauthorized party does not obtain the meaning of the transferred or stored data. Typically, confidentiality is achieved by encrypting the data.
CICS and CICS TG support the SSL transport protocol to ensure that information remains private as it passes over the connection. The data exchanged between the sender and receiver is encrypted and only the client and the server can interpret the information.
Auditing
Auditing can be used to maintain a record of security-related events, such as a user signing in to a system or out of a system, or the details of who modified a given resource, and when. The provision of an audit trail is typically mandatory in enterprise organizations, allowing post-mortem analysis to be conducted in a security breach.
Auditing is a function of the External Security Manager on z/OS. A typical implementation of auditing is the RACF auditor tool. For more information about the RACF auditor tool, see z/OS Security Server RACF Auditor’s Guide, SA22-7684:
Integrity
Integrity ensures that transmitted or stored information has not been altered in an unauthorized or accidental manner. Typically, it is a mechanism to verify whether what is received over a network is the same as what was sent.
Nonrepudiation
Nonrepudiation means that a data sender and a data receiver are able to provide legal proof to a third party that the sender did send the information and that the receiver received the identical information. Neither side is able to deny.
The IBM Redbooks publication, Securing Access to CICS Within an SOA, SG24-5756, contains a more thorough description of the security functions and security considerations when accessing CICS programs from client applications.
8.1.2 The role of cryptography
In computer security, cryptography provides the following processes:
•Encrypting converts usable data into a ciphertext, which conceals the meaning of the data from any unauthorized recipient.
•Decrypting converts ciphertext back to usable data.
•Hashing uses a one-way (irreversible) calculation to condense a long message into a compact bit string called a message digest.
•Generating a digital signature involves encrypting a message digest with a private key to create the electronic equivalent of a handwritten signature.
A digital signature is used to verify the identity of the signer. This verification ensures that nothing has been altered in the signed document from the time that it was signed, and is a basis for nonrepudiation.
Most cryptographic systems combine two elements:
•An algorithm that specifies the mathematical steps that are required to encrypt the data.
•A cryptographic key (a string of numbers or characters) or keys.
The algorithm uses the key to select one relationship between plaintext and ciphertext out of the many possible relationships that the algorithm provides. The selected relationship determines the composition of the algorithm’s result.
8.2 Network security
In a 3-tier system, remote mode applications communicate with a Gateway daemon over a TCP/IP network connection. The Gateway daemon might then use a further network connection to communicate with a CICS server. Both of these network connections can be secured with SSL for Java, JCA, and .NET applications, when using IPIC connections to the CICS server.
Implementing SSL with data encryption provides confidentiality of the messages transmitted on the connection. SSL also offers client authentication based on digital certificates.
8.2.1 Secure Sockets Layer and Transport Layer Security
CICS supports several security protocols to provide secure communication over a TCP/IP network:
•SSL 3.0
•Transport Layer Security (TLS) 1.0
•TLS 1.1
•TLS 1.2
|
Note: CICS Transaction Server for z/OS V5.1 (CICS TS) APAR PM97207 provides support for TLS 1.1 and TLS 1.2.
|
In this book, the term SSL is used as a general reference to these protocols, unless explicitly qualified.
The SSL protocol operates between the application layer and the TCP/IP layer. This allows it to encrypt the data stream itself, which can then be transmitted securely, transparent to the application layer. SSL also provides a means for establishing the identity of one or both participants in the connection.
Authentication occurs at connection time, and it is independent of the application or the application protocol. With SSL, authentication is performed by an exchange of certificates, which are blocks of data in a format described in the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T) standard X.509. The X.509 certificates can be issued and digitally signed by an external authority known as a certificate authority.
For more information about the X.509 standard, see the ITU-T Recommendation on Public-key and attribute certificate frameworks:
8.2.2 Digital signatures, certificates, and key rings
SSL uses digital signatures and digital certificates for establishing a trusted relationship between a sender and a receiver of information sent over a network connection.
Digital signature
A digital signature is a unique, mathematically computed signature that demonstrates the authenticity of a transmission.
Digital certificate
A digital certificate allows unique identification. It is essentially an electronic ID card, issued by a trusted third party, which is known as a certificate authority. Digital certificates form part of the X.509 protocol. This framework provides for authentication across networks. A digital certificate serves two purposes: it establishes the owner’s identity and it makes the owner’s public key available.
A digital certificate contains the following information:
•The public key of the person being certified
•The name and address of the person being certified, also known as the Distinguished Name (DN)
•The digital signature of the certificate authority
•The issue date
•The expiry date
A digital certificate alone is not proof of an identity; it allows verification of the owner’s identity, by providing the public key needed to check the owner’s digital signature. Therefore, the digital certificate owner must protect the private key that belongs with the public key in the digital certificate. If you send your digital certificate containing your public key to someone else, your private key prevents that person from misusing your digital certificate and posing as you. If the private key is stolen, anyone can pose as the legitimate owner of the digital certificate.
Certificate authority (CA)
A digital certificate is issued by a CA and has an expiry date. When requesting a digital certificate, you supply your distinguished name. The digitally signed certificate includes your distinguished name and the distinguished name of the CA. This allows verification of the CA.
To communicate securely, the receiver must trust the CA that issued the certificate that the sender is using. Therefore, when a sender signs a message, the receiver must have the corresponding CA’s signer certificate and public key designated as a trusted root key. Your web browser has a default list of signer certificates for trusted CAs. If you want to trust certificates from another CA, you must receive a certificate from that CA and designate it as a trusted root key.
Key ring
A key ring is a repository containing public keys, private keys, and digital certificates used by a network communications security protocol, such as SSL. Each certificate consists of at least a public key, and metadata related to the identity that it represents, such as a distinguished name.
SSL requires access to key rings for the establishment of secure connections. In the Java Secure Socket Extension (JSSE) implementation of SSL, the key ring is known as the Java KeyStore (JKS) file.
The SSL handshake
When an SSL connection is established, the client and server agree on which version of the SSL/TLS protocol they will use. They select a cipher suite, optionally authenticate each other, and use public key encryption techniques to generate a shared value to be used as the seed for encrypting and decrypting transmitted data.
The SSL handshake consists of several phases:
•Server authentication
In the first phase, the server responds to a client’s request by sending its certificate and cipher preferences.
|
Note: The encryption algorithm and key strength are selected by the client and server during the handshake. It is possible to negotiate to plaintext because two of the defined cipher suites specify no encryption.
|
•Client authentication (optional)
The server requests that the client identify itself during the SSL handshake by providing its client certificate. Client authentication can only be requested by the server.
•Key negotiation
The client then generates a master key, which it encrypts with the server’s public key, and then transmits the encrypted master key to the server. The server authenticates itself to the client by returning a message authenticated with the keys derived from the master key.
Subsequent data is secured using the cipher suite that was negotiated during the handshake. Figure 8-1 on page 137 shows the SSL handshake without client authentication.
Figure 8-1 SSL handshake without client authentication
Figure 8-2 on page 138 illustrates the SSL handshake when client authentication has been requested by the server.
Figure 8-2 SSL handshake with client authentication
8.2.3 Enabling SSL in the CICS TG
The CICS Transaction Gateway supports the JSSE implementation of SSL. JSSE, as supplied with the Java Software Development Kit (SDK), is the only supported SSL option. Two tools, iKeyman and keytool, are shipped in both the Java Runtime Environment (JRE) and SDK packages. The keytool command is issued from the command line, and iKeyman is a graphical tool. These tools are used to work with digital certificates, which are then stored in a keystore on the local file system.
Because the JSSE code is 100% Java, it is platform independent and there is no z/OS specific code. However, there are a couple of functions in other Java security components that provide z/OS specific capabilities that JSSE can use. These functions include the ability to take advantage of the hardware cryptographic devices that can be present on the z/OS platform along with storing certificates in RACF. The hwkeytool command can be used to create certificates compatible with the System z hardware cryptography. RACF administration commands support the generation, importing, exporting, and storing of certificates.
8.2.4 Securing IPIC connections
An Internet Protocol interconnectivity (IPIC) connection can be established between the Gateway daemon and the CICS server or directly to the CICS server from a Java application server when a local mode connection is being used.
IPIC connections enforce the following securities:
•Bind security to prevent an unauthorized client system from connecting to CICS
•Link security to restrict the resources that can be accessed over a connection to a CICS server
•User security to restrict the CICS resources that can be accessed by a user
Bind security
For IPIC, bind security is supported by the exchange of SSL client certificates. The following list shows important configurations that allow the CICS TG to connect successfully, and to prevent an unauthorized system from connecting:
•The SEC system initialization parameter in CICS must be set to YES.
•The TCPIPSERVICE definition in CICS must specify:
– SSL(CLIENTAUTH) or SSL(YES).
– CIPHERS (cipher_suite_code_list).
– Optionally, CERTIFICATE (X.509_certificate_label). The named certificate is used as the server certificate. If CERTIFICATE is not specified, the default certificate defined in the key ring for the CICS region user ID is used.
•The following list shows what must be configured for the Gateway daemon:
– Set the key ring parameters.
– Set the ssl parameter in the IPICSERVER section of the configuration file to Y.
– Optionally, if you want to limit the cipher suites that are enabled for the connection, set the ciphersuites parameter to a comma-separated list of cipher suites to use.
•Local mode configurations must define the CICS server name:
ssl://<server_name>:<port>
The CICS TG and CICS TS information centers provide the detailed description of the definitions required to configure SSL for IPIC connections. The CICS TG information center also contains scenarios illustrating how to perform the configuration tasks for both CICS TG and the CICS server.
Link security
There are two ways that you can specify the link user for IPIC connections. You can use the SECURITYNAME attribute, or an SSL certificate in the IPCONN definition in CICS. The client’s certificate is mapped by the external security manager to a specific user ID, which is defined as the link user. Therefore, you can specify separate link users depending on which certificate you are using.
To specify a link user, set LINKAUTH in the IPCONN definition in CICS to one of the following settings:
•SECUSER to use the user ID that is specified in the SECURITYNAME attribute to establish link security
•CERTUSER to use an SSL client certificate mapped to a user ID to establish link security
When specifying CERTUSER, the IPCONN resource must refer to a TCPIPSERVICE definition that is configured for SSL and client authentication. The certificate must be mapped in the external security manager to your chosen user ID.
User security
IPIC connections can be configured to enforce user security to restrict the CICS resources that can be accessed by a user. The level of user security checking is specified by setting the USERAUTH attribute in the IPCONN definition in CICS. The USERAUTH setting in the IPCONN definition is comparable to the ATTACHSEC setting on other connection definitions.
•If USERAUTH=IDENTIFY is specified, a user ID that is already verified must be supplied. If the connecting CICS TG for z/OS component (a Gateway daemon or an application using local mode) and the CICS TS for z/OS region are not in the same Parallel Sysplex, a client-authenticated SSL connection is required.
•If USERAUTH=VERIFY is specified, a user ID and password or password phrase must be supplied. If password phrases are to be used, the CICS server must support password phrases.
Two other user security options exist in which CICS does not accept a user ID or password from clients. In these cases, a predefined user is assigned to each task that is started. The following list shows those other security options:
•If USERAUTH=LOCAL is specified, all requests run under the link user ID or the default user ID if there is no link user ID.
•If USERAUTH=DEFAULTUSER is specified, all requests run under the default user.
Identity propagation can be used as an alternative to specifying a user ID.
8.2.5 Securing connections to the Gateway daemon
When using a remote mode topology, the connection between Java and .NET clients and the Gateway daemon can be secured using SSL. SSL is not available for clients using ECIv2. If the client will be flowing the user ID and password, an SSL connection is advised to protect the confidentiality of this information.
|
Note: The CICS TG Information Centers include scenarios to show how to configure the following options:
•SSL security on the Gateway daemon
•SSL server authentication and (optionally) SSL client authentication
•Sending an ECI request to the CICS server to check that the SSL connection works
For more information about these options, see the following scenarios:
•Scenario SC06 in the CICS TG for Multiplatforms Information Center:
•Scenario SC05 in the CICS TG for z/OS Information Center:
|
Security exits
The CICS Transaction Gateway products include a feature for the manipulation, validation, or auditing of application requests between Java and JCA client applications and the Gateway daemon. The feature is known as the security exits. Although security exits can be used for reasons other than security, several examples of their use are listed:
•Compressing data over the wire (therefore obscuring)
•Rejecting requests based on request content or metadata
|
Note: Aside from being limited to Java and JCA applications, another limitation of the security exits is the requirement for the application to specify the name of the Java classes to be used. This places an affinity into the remote client application, and also makes it difficult to implement when the Gateway daemon needs to serve a mixed set of applications.
|
CICS TG includes a set of Java components that define a simple yet flexible model for implementing custom security exits. Two of these can be used independently of whether SSL is also used:
•com.ibm.ctg.security.ServerSecurity
This interface is used for server-side security classes that do not require the exposure of SSL client certificates.
•com.ibm.ctg.security.ClientSecurity
This interface is used for all client-side security classes.
Two additional classes are designed to work in conjunction with the SSL environment on the Gateway daemon:
•com.ibm.ctg.security.JSSEServerSecurity
The JSSEServerSecurity interface is an alternative to the Server Security interface and works in conjunction with the SSL protocol. The interface allows access to a client certificate passed during the initial SSL handshake. The exposure of the client certificate depends on configuring the CICS TG to support client authentication.
•com.ibm.ctg.util.RACFUserid
This class (only available in the CICS TG for z/OS) is used to map an X.509 Client Certificate to a RACF user ID. The certificate must already be associated with a valid RACF user ID or an error is returned from RACF.
The CICS TG products include sample programs to illustrate the use of the security exits. They are principally designed to compress the data stream between the client application and the Gateway daemon:
•ClientCompression implements ClientSecurity and demonstrates data compression.
•ServerCompression implements ServerSecurity and demonstrates data compression.
•SSLServerCompression implements JSSEServerSecurity and demonstrates how to expose an SSL client certificate.
The source for these samples is in the following directory:
<install_path>/samples/java/com/ibm/ctg/samples/security
8.3 Passwords, PassTickets, and password phrases
During authentication, the identity of a user can be established by supplying both the user ID and a password. A password is typically a short sequence of letters, numbers, and certain special characters. On z/OS, a password can be up to eight characters long, and it might not be limited to uppercase, depending on the system configuration.
|
Note: Support for mixed-case passwords was introduced with CICS TG for z/OS V7.0.
|
Password phrases differ from traditional passwords in that they are longer than passwords, ranging from 9 to 100 characters long. This greater length is thought to provide more powerful security. Otherwise, they operate on the same principle as passwords, and they are used in exactly the same way. Not all CICS systems or CICS TG releases support the use of password phrases.
|
Note: Password phrase support was introduced by the CICS TG V8.1 products, and it can be used when connecting to CICS TS for z/OS V4.2, or later, using an IPIC connection. CICS TG for z/OS V9.0 added further support, allowing authentication of password phrases for external CICS interface (EXCI) connections and any supported release of CICS TS for z/OS.
|
A PassTicket is a program-generated character string to use directly instead of a password or password phrase. A PassTicket looks very much like a password, and it can be used by CICS TG applications directly in place of a normal password. However, PassTickets are only valid for a single authentication operation, and they expire within a short time after generation. The basis of the technology relies on the use of a shared secret key.
Using PassTickets removes the need to transmit reusable passwords, and password phrases, over the network. It also makes it possible for client systems to authenticate themselves to the server, without the need to securely manage reusable credentials in the client system.
For more information about PassTickets, see the topic, The RACF PassTicket, in the z/OS Information Center:
8.4 Identity propagation
Identity propagation is the capability where a non-z/OS identity (a distributed identity) is propagated into the z/OS environment and then is used for these functions:
• To provide credentials for authorization by being mapped to an existing security user ID
• To be available throughout the z/OS sysplex for auditing and reporting
The distributed identity of an authenticated user is determined by the distributed application and passed along to the receiving subsystem on z/OS. The subsystem, such as CICS, then uses the ESM (such as RACF) to search for a mapping between the distributed identity and a SAF user ID. The logon is failed if no mapping is found.
The distributed identity is then associated with the SAF user ID within the security context for the specific request. Both the SAF user ID and the distributed identity will now be included in any audit records that relate to the processing of the request.
Figure 8-3 on page 143 shows a conceptual overview of identity propagation.
Figure 8-3 Identity propagation
One requirement for identity propagation is that the connection between the CICS TG and CICS must be an IPIC connection. A client-authenticated SSL connection is required unless CICS Transaction Gateway and CICS Transaction Server are on z/OS and in the same sysplex.
In the information center for CICS TG for z/OS, Scenario SC04 shows how to configure CICS TG for z/OS, CICS TS, RACF, and WebSphere Application Server on AIX. Specifically, this scenario shows how to implement identity propagation of a user’s security information (the distributed identity), which is held in IBM Tivoli Directory Server. When this is passed to CICS Transaction Server, the identity is mapped to a user ID in RACF.
For a more thorough description of identity propagation (ID propagation) and detailed examples for implementation, see z/OS Identity Propagation, SG24-7850:
8.5 The external security interface
The external security interface (ESI) provides a security management API to manage user IDs and passwords. ESI enables user applications to perform security-related tasks, such as viewing the status of user IDs and updating passwords held by an ESM.
The original implementation of ESI was an interface to Password Expiration Management (PEM), and part of the Advanced Program-to-Program Communication (APPC) architecture. Its use was restricted to CICS TG on distributed platforms (CICS TG for Multiplatforms or the now discontinued CICS Universal Client), and then only when the gateway products connected to CICS using Systems Network Architecture (SNA). As of CICS TG V8.1, ESI is supported over IPIC connections, therefore available to all CICS TG products.
ESI can be used to verify and change the user ID and password information stored in the ESM. Two primary functions provided by ESI are verifying passwords and changing passwords. These invoke the corresponding CICS commands EXEC CICS VERIFY PASSWORD and EXEC CICS CHANGE PASSWORD. These commands interface with the ESM, such as RACF, to perform the operation that you want.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.