A.1 SGD Gateway Architecture

This section looks at the architecture of the SGD Gateway and includes a description of the connections made when you access SGD through the SGD Gateway.

Figure A.1, “SGD Gateway Architecture” shows the architecture of the SGD Gateway.

Figure A.1 SGD Gateway Architecture

Network Diagram showing the SGD Gateway Architecture

The following steps describe the connections made when you access SGD through the SGD Gateway. The steps cover the initial connection to SGD using a browser, logging on to SGD, through to starting an application.

Note

The steps below describe the connections made when you access the SGD Gateway from a desktop computer.

If you are using the tablet workspace, some minor differences may apply. The SGD Client is not downloaded and installed on the tablet device. Instead, an HTML5 web page is used to manage the connection to the SGD Gateway.

  1. A browser on the client device makes an HTTP over Secure Sockets Layer (HTTPS) connection to the SGD Gateway, on TCP port 443.

    • For a basic deployment, users can access SGD by going to the URL of the SGD Gateway.

    • TCP port 443 is the default port for the SGD Gateway. The ports used by the SGD Gateway are defined using the routing proxy configuration file, gateway.xml. This file is created automatically during installation of the SGD Gateway, and is updated when the gateway config command is used to change the SGD Gateway configuration.

    • The SGD Gateway presents an SSL certificate to the browser on the client device.

    • The location and passwords for the keystores used by the SGD Gateway are defined in the routing proxy configuration file, gateway.xml.

  2. The routing proxy recognizes an HTTPS connection, decrypts the data stream, and forwards HTTP data to the Apache reverse proxy.

    • HTTP data is sent internally on TCP port 8081.

    • The configuration for the Apache reverse proxy is defined by the httpd.conf file. This file and related reverse proxy configuration files are created automatically during installation of the SGD Gateway. The files are updated when the gateway config command is used to change the SGD Gateway configuration.

  3. The reverse proxy uses HTTP load balancing to select an SGD web server in the array.

    • Connections between the reverse proxy and the SGD web server are secure, using HTTPS on TCP port 443.

    • The Apache reverse proxy sets a load balancing cookie in the browser. All subsequent HTTP requests by the browser use the same SGD web server.

  4. HTML from the SGD web server is routed to the browser on the client device.

    • The HTML is sent as HTTPS data on the connection established to TCP port 443 on the SGD Gateway.

    • The SGD Gateway forwards the HTTPS data to the browser.

  5. The user logs in to SGD.

    • The SGD server authenticates the user and starts a new user session.

    • The SGD Client is downloaded, installed, and started on the client device.

    • A routing token is included in HTML sent to the browser. The routing token contains the address of the SGD server which manages the user session. This information is used to route Adaptive Internet Protocol (AIP) data to the correct SGD server.

    • The routing token is signed using the private key for the SGD server's CA certificate, and then encrypted using the SGD Gateway certificate on the SGD server.

    • The routing token is passed to the SGD Client.

    • Connections to the client device use HTTPS.

  6. The SGD Client connects to the SGD Gateway on TCP port 443.

    • The data connection between the SGD Client and the SGD Gateway uses AIP over Secure Sockets Layer (SSL).

    • The SSL certificate for the SGD Gateway is presented on the connection.

    • The routing proxy recognizes incoming AIP data over SSL.

    • The SSL data stream is decrypted, and the routing token is extracted from the AIP data stream.

    • The routing token is decrypted, using the SGD Gateway private key and then verified, using the CA certificate for the SGD server.

    • The SGD Gateway private key and the CA certificate for the SGD server are stored in the SGD Gateway keystore, keystore.

    • The time stamp on the routing token is checked, to ensure the routing token is valid.

    • The AIP data stream is re-encrypted using SSL.

  7. AIP over SSL data is routed through the routing proxy to the SGD server indicated by the routing token.

    • The AIP over SSL data connection uses TCP port 5307.

    • The routing token is not included with the AIP data stream.

  8. The user starts an application on the SGD workspace.

    • The application launch request is sent to the SGD Gateway using HTTPS.

    • The routing proxy recognises and decrypts HTTPS data, and forwards HTTP traffic to the Apache reverse proxy.

    • The reverse proxy detects the load balancing cookie and uses the SGD web server indicated by the cookie.

    • SGD application session load balancing selects an SGD server to manage the application session.

    • A new routing token is created on the SGD server. The routing token is used to route AIP data to the SGD server selected to manage the application session.

    • The SGD server sends the routing token to the SGD Client. The routing token is included with the existing AIP data stream.

  9. The SGD Client connects to the SGD Gateway on TCP port 443.

    • The SSL certificate for the SGD Gateway is presented for the connection.

    • The routing proxy recognizes incoming AIP over SSL data.

    • The routing token is decrypted, verified, and validated.

    • AIP over SSL data is routed through the routing proxy to the SGD server indicated by the routing token.

    • The routing token is not included with the AIP data stream.

  10. The SGD server manages the application session.

    • The application runs on an application server located on the local area network (LAN).