Security › Security Overview › Security Data › Standard Security

Standard Security

When using Standard Security, the security data (user ID and Password) is placed into fields that are located in the Common Format buffer (CFB) header.

The security data that is provided using this technique is used with Layer 1 and indirectly with Layer 2 (the USER_ID system attribute and transcode that is authorized by the TIRSECR user exit).

The User ID and Password values can be provided in one of two ways:

• In the implementations that do not use a Client Manager, a DPC application provides the User ID and Password using the CLIENT_USER_ID and CLIENT_PASSWORD variables. The client security user exit (WRSECTOKEN) indicates that these values be placed into the CFB header.
• In the implementations that use the Client Manager, the Client Manager provides the User ID and Password.

  Note: For more information about how the Client Manager can be configured for security processing, see the Distributed Processing—Client Manager User Guide.

The security data that is transmitted in the CFB header is not directly accessible to the logic of a DPS application. However, this security data, in most DPS execution environments, is used to establish the user context under which the DPS execute. For example, the supplied user ID and password are used to sign-on the user. The signed-on user establishes the context under which the transaction execute. The user ID value that is associated with the signed-on user is populated in CA Gen's USER_ID system attribute by way of the TIRUSRID user exit.

In certain execution environment the sign-on processing occurs by a third-party environment where the security data has to be passed as is. Therefore, when processing occurs in Layer 1 where the access validation occurs external to the DPS, the security data has to be available in a known form. To accommodate these execution environments, the header portion of the CFB cannot be encrypted.