3.3.5.1 Connection Setup and Authentication

  • Article

This phase establishes the two HTTP connections called IN channel and OUT channel and authenticates the user. This phase involves HTTP header exchanges only.

  1. The RDG client first establishes a secure HTTP connection to the RDG server using SSL on the name and port number supplied by the higher layer. This step also includes server authentication using the RDG server's certificate.

    Note If the higher layer provides password credentials, the credentials are sent along with the request. The RDG client uses Negotiate as the preselected authentication scheme.

    The RDG client sends a request with the RDG_OUT_DATA (section 2.2.3.1.2) custom command and the custom header RDG-Connection-Id (section 2.2.3.2.1) set to a unique identifier. A GUID generated by the RDG client is used for this purpose. The RDG client disallows caching and uses "*/*" as the accept type.

    Optional headers with an RDG_OUT_DATA request SHOULD include RDG-Connection-Id (section 2.2.3.2.1) and RDG-User-Id (section 2.2.3.2.3).

  2. The RDG server interprets this request as a request to create the OUT channel. It sends back an HTTP 401 status code (authentication required) with the supported authentication schemes in the WWW-Authenticate header. This should include any Custom HTTP Authentication Scheme Names (section 2.2.5.3.10) for custom authentication schemes that the RDG server supports.

  3. The RDG client selects an authentication method and starts the authentication exchange by setting the Authorization header. Messages are exchanged until the client is authenticated.

  4. The server sends back the final status code 200 OK, and also a random entity body of limited size (100 bytes). This enables a reverse proxy to start allowing data from the RDG server to the RDG client. The RDG server does not specify an entity length in its response. It uses HTTP 1.0 semantics to send the entity body and closes the connection after the last byte is sent.

    The RDG client resends the request on the same connection. The RDG server recognizes this second request as an authenticated connection request, as described in the following diagram.

    IN channel tunnel and channel setup

    Figure 17: IN channel tunnel and channel setup

  5. The RDG client sends a request for creating an IN channel with the custom command RDG_IN_DATA (section 2.2.3.1.1), and the RDG-Connection-Id header set to the same GUID sent on the RDG_OUT_DATA request. This allows the RDG server to correlate the two requests as belonging to the same connection. Steps 1 through 4 in the process are repeated but with the RDG_IN_DATA command, as shown in steps 5 through 8 in the previous diagram (IN channel and tunnel channel creation). The content length is not used to tell to the RDG server that this not the data but the authentication request.

    Optional headers with an RDG_IN_DATA request SHOULD include RDG-Correlation-Id (section 2.2.3.2.2) and RDG-User-Id (section 2.2.3.2.3).