CPI-C Reference

Conversation Security

Many systems control access to system resources through security parameters associated with a request for access to those resources. In particular, a CRM working in conjunction with node services can control access to its programs and conversation resources using access security information carried in the conversation startup request.

The conversation startup request contains one of the following forms of access security information:

• No access security information

• The user ID of the user on whose behalf access to the remote program is requested

• The user ID and a password for the user on whose behalf access to the remote program is requested

• Authentication tokens generated by a distributed security service for the user on whose behalf access to the remote program is requested.

The access security information in the conversation startup request depends on the values of the security conversation characteristics and comes from the following sources:

• The system administrator can provide security parameters in the side information. These are used to establish security characteristics when the program issues the Initialize_Conversation call.

• The program can override the values from side information and set the security characteristics directly using the Set_Conversation_Security_Type, Set_Conversation_Security_User_ID, and Set_Conversation_Security_Password calls.

• When the program allocates a conversation with conversation_security_type set to CM_SECURITY_SAME, CM_SECURITY_DISTRIBUTED or CM_SECURITY_MUTUAL, the security parameters for the program's current context are used to generate the access security information. This may involve the use of a distributed security service. The access security information is sent to the remote CRM in the conversation startup request.

The required_user_name_type field in the program binding may be used to specify the type of user name required by the remote system.

• "NONE" indicates the remote system accepts and processes requests that do not contain access security information.

• "LOCAL" indicates the remote system requires a user ID that is valid at the remote system. User IDs may be sent for CM_SECURITY_PROGRAM, CM_SECURITY_PROGRAM_STRONG, CM_SECURITY_SAME, CM_SECURITY_DISTRIBUTED and CM_SECURITY_MUTUAL requests.

• "PRINCIPAL" indicates the remote system requires a principal name from the distributed security service. Principal names are sent for CM_SECURITY_SAME, CM_SECURITY_DISTRIBUTED and CM_SECURITY_MUTUAL requests.

Certain combinations of values of conversation_security_type and required_user_name_type field (from the program binding) cause the local CRM to reject the Allocate call with a return_code of CM_SECURITY_NOT_SUPPORTED. Table 8 shows the incompatible values.

Table 8. Incompatible conversation_security_type and required_user_name_type Values

required_user_name_type	conversation_security_type
LOCAL	CM_SECURITY_NONE
PRINCIPAL	CM_SECURITY_NONE
PRINCIPAL	CM_SECURITY_PROGRAM
PRINCIPAL	CM_SECURITY_PROGRAM_STRONG

In addition to supporting access security information on conversation startup requests, the OSI standard includes the ability to perform re-authentication during a conversation. A program requests re-authentication by making OSI TP implementation-specific calls to node services. Security protocols for OSI TP CRMs are defined in standard ISO/IEC 11586 part 1, Generic Upper Layers Security.

For an OSI TP CRM, the application context identifies to the program developer which conversation security type should be used.

When a program is started as a result of an incoming conversation startup request or when an already started program accepts an incoming conversation, node services uses the access security information to validate the user's access to the program and to establish the security parameters for the resulting context.

The program that accepts an incoming conversation may examine the security_user_ID for that conversation by issuing the Extract_Security_User_ID call.