- 17.9K All Categories
- 3.4K Industry Applications
- 3.4K Intelligent Advisor
- 75 Insurance
- 537.6K On-Premises Infrastructure
- 138.7K Analytics Software
- 38.6K Application Development Software
- 6.1K Cloud Platform
- 109.6K Database Software
- 17.6K Enterprise Manager
- 8.8K Hardware
- 71.3K Infrastructure Software
- 105.4K Integration
- 41.6K Security Software
Understanding the Oracle Secure Global Desktop Gateway
SGD without the gateway
When installing Oracle Secure Global Desktop (SGD) server software (eg sgd1.acme.com), a client web browser can connect to that SGD server via http://sgd1.acme.com or https://sgd1.acme.com to access services via SGD. In order for the native SGD client to communicate via the native AIP protocol with that server, port 3144 (insecure) or 5307 (encrypted) need to be opened in any firewalls between the client and the SGD server.
For high availability or load-balancing purposes, additional SGD servers can be added together into an array, sharing all configuration and session information. If we install and add server sgd2.acme.com to our array, a potential user could connect to either of the two servers to access their workspace, and launch and resume applications.
The firewalls would need to be amended to allow access to port 3144 or 5307 for that second server, and no load-balancing between the SGD servers can happen, because a user would directly connect to a specific server.
In this configuration, accessing resources over the open internet via SGD would also require to open the additional ports in a companies firewall, which is not very desirable. Also every SGD server would require their own SSL certificate.
SGD with the gateway
SGD comes with a free gateway component that should be preferably installed in a DMZ. It only requires port 443 (and to redirect unencrypted traffic port 80) to be opened in a firewall. It will then tunnel all SGD related traffic inside the SSL connection the client web browser established with the service. A single gateway can connect to an array with multiple servers and load balance between array members. The gateway is completely state-less and has no information about authenticated users or running sessions.
Only a single, user-friendly URL with a single SSL certificate is necessary, even when deploying more than one gateway for high-availability.
Since now all access happens through the SGD gateway(s), the SGD servers in the array no longer need to be accessible either on the open internet, or even inside a Corporate WAN, and can be completely hidden from the end-user. Only the SGD gateway(s) should have valid SSL certificates.
Furthermore, the gateway controls if access to individual members of the array should be enabled, or disabled, or in which order fail-over between the SGD servers should happen.
Use additional gateway commands
On the gateway a user with the proper permissions can list all active connections. Each connection carries a token
On the SGD server the token can be resolved to a session