The proprietary intermediate client request control may be included in any type of request, and may serve a few different purposes:

• It may indicate that the request originated from a downstream client, in which case the control may provide additional information about interaction with that client and any other intermediate systems.

• It indicates that the server should provide information about its processing of the operation (along with information from any other upstream servers) that can be used to correlate information about the processing of the operation across multiple systems.

• It can be used to request that the operation be processed with an alternative authorization identity. In this respect, it is similar to the proxied authorization v1 or v2 request control, except the intermediate client control allows multiple authorization requests to be nested.

The intermediate client request control has an OID of 1.3.6.1.4.1.30221.2.5.2, and it takes a value. The following fields may be present in the value-json representation of the value:

• downstream-request: An optional JSON object field whose value is the representation of information from a downstream client. If present, the fields that may be included in this JSON object are the same fields that may be included in the value-json object of the intermediate client request control (optionally including yet another nested downstream-request field).

• downstream-client-address: An optional string field whose value is the address of the immediate client from which the request was received. For example, the Directory Proxy Server uses this field to pass the address of the end LDAP client to the backend Directory Server used to process the request.

• downstream-client-secure: An optional Boolean field whose value indicates whether communication with the immediate downstream client is using a secure channel. For example, the Directory Proxy Server uses this field to indicate to the backend Directory Server whether the communication between the end LDAP client and the Directory Proxy Server is secure.

• client-identity: An optional string field whose value contains the authorization identity of a user under whose authority the operation should be processed. For example, the Directory Proxy Server uses this field to indicate that the operation should be processed using the authorization identity of the end LDAP client rather than as the account the Directory Proxy Server uses to authenticate itself to the backend Directory Server.

• client-name: An optional string field whose value contains the name of the application that generated this control. For example, the Directory Proxy Server uses this field to indicate that the request has passed through the Directory Proxy Server.

• client-session-id: An optional string field whose value contains an identifier that this client is using to reference the current communication session with a downstream client. For example, the Directory Proxy Server uses this field to hold the connection ID that it has assigned to the connection it is using to communicate with the end LDAP client.

• client-request-id: An optional string field whose value contains an identifier that this client is using to reference the current request from a downstream client. For example, the Directory Proxy Server uses this field to hold the operation ID it has assigned to the operation being forwarded to the backend Directory Server.

The following sample shows the JSON encoding for the control:

{ 
    "oid":"1.3.6.1.4.1.30221.2.5.2",
    "control-name":"Intermediate Client Request Control",
    "criticality":false,
    "value-json": { 
        "downstream-client-address":"1.2.3.4",
        "downstream-client-secure":true,
        "client-identity":"dn:uid=jdoe,ou=People,dc=example,dc=com",
        "client-name":"PingDirectoryProxy",
        "client-session-id":"conn=1234",
        "client-request-id":"op=56" 
    } 
}