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.

  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. This certificate is the only entry in the keystore.client keystore on the SGD Gateway.

    • 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 the first free port above TCP port 8080.

    • 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. The SGD web server delivers HTML 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, selects an SGD server to manage the user session, 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 selected to manage 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 of the SGD server, 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 for the connection.

    • The routing proxy recognizes incoming AIP over SSL data.

    • 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 webtop.

    • 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 the same 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).