Skip to Main Content

Infrastructure Software


For appeals, questions and feedback, please email

Understanding the Oracle Secure Global Desktop Gateway

Jan-OracleOct 4 2018 — edited Feb 26 2020

SGD without the gateway

When installing Oracle Secure Global Desktop (SGD) server software (eg, a client web browser can connect to that SGD server via or 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 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

Gateway connection list

[root@sgd-gateway ~]# /opt/SUNWsgdg/bin/gateway connection list

Connection ID: 461



Start time: Dec 18, 2017 9:16:53 PM

Last activity: Dec 18, 2017 9:16:54 PM

Uptime: 00:00:44

Connection type: AIP

Data sent to client: 13565

Data received from client: 9860

Token: 1ro2KiH3L6FXxHhuS46vFcn1oBo=

Connection ID: 462



Start time: Dec 18, 2017 9:16:54 PM

Last activity: Dec 18, 2017 9:16:54 PM

Uptime: 00:00:43

Connection type: AIP

Data sent to client: 3425

Data received from client: 4550

Token: L+z+vxf71/kI2iAu21239guzTA0=

Connection ID: 463



Start time: Dec 18, 2017 9:16:54 PM

Last activity: Dec 18, 2017 9:16:55 PM

Uptime: 00:00:42

Connection type: WebSocket

Data sent to client: 494

Data received from client: 3693

Token: LPFSgQ3zK58+mWrDhO5Zz2Efmdc=

On the SGD server the token can be resolved to a session

tarantella gateway token

[root@sgd-server ~]# /opt/tarantella/bin/tarantella gateway token --token 1ro2KiH3L6FXxHhuS46vFcn1oBo=

Session type: Webtop session

Connection type: Soap

User: .../_ens/dc=com/dc=oraclecloud/dc=compute/cn=sgdadmin

Login time: 1513631811119


SGD server:

State: connected

Post Details
Added on Oct 4 2018