18.104.22.168 Connection Setup and Authentication
This phase establishes the two HTTP connections called IN channel and OUT channel and authenticates the user. This phase involves HTTP header exchanges only.
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 22.214.171.124.2) custom command and the custom header RDG-Connection-Id (section 126.96.36.199.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 188.8.131.52.1) and RDG-User-Id (section 184.108.40.206.3).
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 220.127.116.11.10) for custom authentication schemes that the RDG server supports.
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.
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.
Figure 17: IN channel tunnel and channel setup
The RDG client sends a request for creating an IN channel with the custom command RDG_IN_DATA (section 18.104.22.168.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 22.214.171.124.2) and RDG-User-Id (section 126.96.36.199.3).