Planning for security implementation and auditing in CICS Service Flow Runtime

Stabilized feature: Service Flow Runtime and Service Flow Modeler capability in IBM Developer for z/OS 14.2.3 are stabilized. Consider exposing and orchestrating applications as API services by using z/OS Connect Enterprise Edition or CICS web services, or by writing web applications in Java or Node.js. See also Stabilization notices and discontinued functions.

You can implement security in two ways. The service requester can either provide the security or you can implement security in CICS.

Security implementation

You can implement security in the CICS Service Flow Runtime using one of the following components:

  • Configure RACF® or another external security manager to handle request messages.

    CICS Service Flow Runtime does not require users to sign on before issuing requests for processing. However, you can specify authentication using RACF to check that the user ID is authorized to invoke a service flow.

  • Configure the CICS-MQ bridge to provide security for service requesters that are IBM® MQ-enabled applications.
    The CICS-MQ bridge uses the AUTH parameter that is passed to the CICS bridge monitor task at startup to establish the authentication level required for the CICS bridge link task.
    • If you are using FEPI with PassTickets, set the AUTH parameter to a value other than LOCAL.
    • To establish different levels of authentication, initiate multiple bridge monitor tasks with different AUTH parameters.

The CICS-MQ bridge checks that the user has the authority to run the CICS bridge link task, based on the user ID and password. The CICS Service Flow Runtime programs and processes run under the user ID and password established for the CICS bridge link task. See Security considerations for using IBM MQ with CICS for information on security while using IBM MQ with CICS.

Audit levels

Auditing is a function of BTS that records information about BTS processing. The audit level determines the audit points. The service requester can set auditing in the request message.

The supported audit levels and their signifiers are as follows:

  • Activity (A)
  • Full (F)
  • Process (P)
  • None ( )

For a detailed description of how to create an audit trail for BTS processes and activities, see Developing with the BTS API.