Changes to security

APAR PI28039 update

The default setting for the ENCRYPTION system initialization parameter, ENCRYPTION=STRONG, no longer allows the use of the SSL version 3.0 security protocol. The minimum security protocol allowed with ENCRYPTION=STRONG is now TLS version 1.0.

If you have clients that still require the SSL version 3.0 protocol, you can enable support for that protocol by specifying the system initialization parameter ENCRYPTION=SSLV3 for the CICS region. SSL 3.0 should only be used for a migration period while clients that still require this protocol are upgraded. Any connections that require encryption automatically use the TLS protocol, unless the client specifically requires SSL 3.0.

Security for CICS bundles

For resources that are dynamically created by CICS bundles, no additional CICS command security checks and resource security checks take place for those resource types, either when the resources are dynamically created at bundle installation time, or when you manipulate the resources by making changes to the CICS bundle. You need authority only to perform the actions on the CICS bundle, or for bundles that are installed with applications and platforms, to perform the actions on the application or platform with which the CICS bundle was deployed. However, CICS command security and resource security for the individual resource types do apply when you inquire on the dynamically created resources, or if you manipulate the dynamically created resources directly.

If you used CICS bundles in earlier CICS releases, check the security permissions that you gave to users for those bundles. Depending on how you set up security for CICS bundles, users with authority to act on individual CICS bundles might now be able to act on new or existing resources that are dynamically created as part of the installation of a bundle. Ensure that the levels of authority for BUNDLE resources are still appropriate.

Permission to make applications and CICS bundles available or unavailable

Operators with UPDATE access for the CLOUD.APPLICATION.context security profile now have permission for the new actions to make applications that are deployed on platforms available or unavailable to users, which is required in addition to enabling or disabling them. In releases before CICS TS 5.2, the action of enabling or disabling an application also made it available or unavailable to users, so the new permission is still appropriate for the same operators.

The same situation applies to operators with UPDATE access for a security profile that specifies the BUNDLE resource type and the resource name $*, as described in Security for platforms and applications. These operators can make BUNDLE resources that are created for platforms and applications available and unavailable.

Stand-alone CICS bundles need to be made available or unavailable only if they contain application entry points. Operators with UPDATE access for the security profile for a stand-alone CICS bundle, which specifies the BUNDLE resource type and the name of the BUNDLE resource, can make the resource available or unavailable.

Security for programs declared as application entry points

If you apply security measures to individual PROGRAM resources, for applications that are deployed on platforms, secure the programs that are declared as application entry points, but do not secure other programs in the applications. The security settings that you specify for a program that is part of an application deployed on a platform apply to both public and private programs, and do not take into account the version of the application. Programs that are declared as an application entry point must have a unique PROGRAM resource name in your environment. However, if you secure programs that run at a lower level in the application, programs with the same names might be running in different applications, which can lead to unforeseen consequences. In this situation, a user might have permission to access a program that is declared as an application entry point, but not have permission to access a program that runs at a lower level in the application, because the security settings from another instance of the program name are in effect. Consider the security measures that you apply to a program that is declared as an application entry point program, as applying to the whole application.

Integrated support for SAML

In CICS TS for z/OS, Version 4.2 and CICS TS for z/OS, Version 5.1, support for Security Assertion Markup Language (SAML) was provided in the CICS Transaction Server for z/OS Feature Pack for Security Token Extensions. The functions of that feature pack are now incorporated into CICS itself. You cannot use the feature pack with CICS Version 5.2.

The SAML output containers have been enhanced with additional information extracted from the SAML token.

The SAML IVP has been enhanced to support easier validation of customer defined tokens.

Support for Kerberos

Previously, support for Kerberos tokens was provided remotely by using a web service. You can now validate a Kerberos token with a local external security manager (ESM) by using the CICS API. For more information, see VERIFY TOKEN. If your ESM is RACF®, support is provided for Kerberos Version 5 and Generic Security Services. For the Kerberos support level of other ESMs, refer to their documentation.

Support is provided for validating Kerberos tokens in inbound web service requests. Optionally, the target application can also be set to run under the user ID associated with the client principal in the Kerberos token. To use Kerberos token validation, set the mode of the <authentication> element to the new value basic-kerberos. For more information, see The <authentication> attribute.

Extended support for cryptographic standards

The enhancements to support NIST SP800-131A compliant cipher suites and certificates, which were supplied in APAR PM97207 for CICS TS for z/OS Version 5.1 are now incorporated into CICS itself. For more information, see Making your CICS TS system conformant with NIST SP800-131A.