Security › Security Overview › Server Security Processing › Layer 1: Transaction Security

Layer 1: Transaction Security

Transaction security authorizes the activation of the transaction and lets control be passed to the DPS application. Layer 1 is comprised of security processing that is considered to be external to the DPS application.

Transaction security can validate that the user associated with a cooperative flow request is authorized to execute in the target environment. This processing can be considered similar to that of a logon operation. If the user associated with the cooperative request is not validated, the transaction does not get started and the Server Manager associated with the request does not receive control.

Additional transaction security validation can occur after the user associated with the cooperative request is validated as being an authorized user of the target system. The additional security processing validates the user is authorized to execute the specific transaction that is associated with the target DPS.

In certain execution environments, a DPS is identified using a transaction code (trancode). Users are granted access to execute certain trancodes. If access to a trancode is denied for a given user, the Server Manager that is associated with the specified trancode never receives control.

Layer 1, Transaction Security, is only available in certain execution environments (TE, Tuxedo Proxy Client, CICS, TMF, IMS, EJBs, and .NET Servers).

Third-party execution environments such as CICS, IMS, EJB, and .NET Servers offer transaction security processing that is unique to their respective environments. For example, if your execution environment is Pathway, an application can use Remote Server Call (RSC/MP) to invoke NonStop TMF servers to protect the integrity of server transactions. See the vendor documentation for specific details about how these environments provide transaction security.

For those environments that do not provide external transaction security, a comparable opportunity to validate user access and authorization can be accomplished in Layer 2.

Note: Beginning with Layer 2, the application load module, or Server Manager containing the target DPS, receives control and begins its execution. The security processing from Layer 2 through Layer 5 is implemented in application logic that is provided by the customer. This customer logic is implemented in the form of user exits and code that is implemented in, or invoked from, the server application itself (implemented in action language or an external action block).