How it works: Authorization in CICS

CICS® Transaction Server for z/OS® uses RACF® to authorize a user identifier (user ID) to a specified resource. Authorization is based on an identifier that is either trusted or has been previously authenticated.

CICS checks authorization to:

Run CICS transactions (transaction security). For more information, see Transaction security.
Access resources (resource security). For more information, see Resource security.
Use CICS system programming commands (command security). For more information, see Command security.
Communicate between CICS systems (intercommunication security) if you are using MRO, IPIC, or ISC connections between multiple regions. For connected systems, the same principles of protecting CICS resources, commands, and transactions apply, but you also have to consider the resource definitions for the connections. For more information, see Intercommunication security.
Control access to a resource in an application served by Liberty (role authorization). For more information, see Role authorization.

You can further manipulate these capabilities to:

Customize the CICS authorization checks in your application. The application can use the CICS API to determine a user's level of access to a resource (application-specific authorization). For more information, see Application-specific security (QUERY SECURITY).
Issue requests on behalf of other users (surrogate authorization). For more information, see Surrogate security.

Usually the same RACF definitions apply to all CICS regions. Each region would normally use the same security configuration definitions. If you have a specific requirement for some regions to have different definitions, then this can be achieve using the SECPRFX SIT option.