Security › Security Overview › Client Security Processing

Client Security Processing

Each DPC application type that originates a user request (GUI, proxies, or internet client) provides some facility for placing data into the CA Gen variables CLIENT_USER_ID and CLIENT_PASSWORD. For generated the DPC applications these variables are read/write system attributes. For the proxies, they are application data variables with corresponding get and set methods.

For the DPC applications that flow to a non-EJB and a non-. NET Server, the supporting runtime invokes a client security user exit (such as WRSECTOKEN). This client security user exit indicates whether the CLIENT_USER_ID and CLIENT_PASSWORD variables are used as security data associated with a cooperative flow request. That same user exit also influences how the runtime incorporates the security data into the cooperative flow request.

For the flows between a DPC and DPS that operate in the same execution environment and have processing that does not use a CFB or a Tuxedo View32 buffer (Java clients flowing to EJBs and .NET clients flowing to .NET Server), the CLIENT_USER_ID and CLIENT_PASSWORD system attributes are always transmitted (serialized) as part of the Import data that are exchanged between the DPC and the DPS.

For the DPC applications that flow to a non-EJB and non-. NET Server, the client security user exit influences how the security data is processed, as follows:

• The security user exit can indicate that the CLIENT_USER_ID and CLIENT_PASSWORD variables should NOT BE USED to populate any part of the cooperative flow (Security None).
• If a DPC client security user exit returns Security None, it is possible for the GUI DPC application to have security data that is provided by CA Gen, which is associated with the cooperative flow request. The Client Manager can specify the security data. This security implementation requires that you specify CA Gen as the transport mechanism for the cooperative flow. In this case, CA Gen indicates that the DPC uses the Client Manager.

The client security user exit can indicate that Standard Security be used, as follows:

• For the flows that use a Common Format buffer (CFB), the data in the CLIENT_USER_ID and CLIENT_PASSWORD variables are populated into corresponding fields that are located in the header portion of the Common Format Buffer (CFB). For more information, see Standard Security.
• For the flows using Tuxedo View32 data structure, the data in the USERID and PASSWORD fields is populated in corresponding fields in the View32 data structure.

The client security user exit can indicate that Enhanced Security is used, as follows.

• For the flows that use a Common Format Buffer, the CLIENT_USER_ID and CLIENT_PASSWORD variables are populated into fields that are located in the optional security-offset portion of the CFB. In addition, when using Enhanced Security, the CLIENT_USER_ID is populated into the header portion of the CFB.
• If the client security user exit indicates that Enhanced Security is used, the exit can also indicate that the data that is placed into the optional security-offset field be used by the Client Manager or Communications Bridge.
• Lastly, if the client security user exit indicates that Enhanced Security is used, the user exit can also supply a security token. This token is added to the security portion of the CFB. The security token can be used for passing security token data to an external authenticating process such as Kerberos.

Note: For the flows using Tuxedo View32 data structure, the data in the USERID, PASSWORD, and security token fields is populated in corresponding fields in the flows View32 data structure.

For a DPC application that flows to an EJB or .NET Server, the client security user exit provides the DPC application the opportunity to provide a user-defined security object. This object is similar in function to the security token described earlier.

The DPC GUI clients can include security processing that a CA Gen communications program provides such as the Client Manager. Other DPC client types can involve the use of a Communications Bridge.

The GUI DPC applications use the Client Manager as part of their security solution by having the Client Manager supply a user ID and password for a cooperative flow.

Note: For more information about security processing specific to the Client Manager, see the Distributed Processing—Client Manager User Guide.

Customers of CA Gen can optionally use a Communication Bridge to service cooperative flows from many clients. The Communications Bridge can be involved in security processing by utilizing the security data that is transmitted in the CFB as part of the cooperative flow.

Note: For more information about the security processing specific to the Communications Bridge, see the Distributed Processing– Communications Bridge User Guide.

Client-side security processing can also involve security processing that is provided as part of a third-party vendor product, as follows:

• IBM MQSeries can carry out authorization checks for each resource that is accessed during the processing of a cooperative flow.
• Flows to CICS that uses ECI require IBM Universal Client software. The Universal Client can optionally supply a User ID and password for flows that do not specify any security data.
• Flows to EJBs can use the Java EE roll base security mechanism.

For specific details about how to incorporate security processing that is external to CA Gen cooperative processing, see the relevant vendor documentation.

For more information:

z/OS Security