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
Gateway connection list
|
[root@sgd-gateway ~]``# /opt/SUNWsgdg/bin/gateway connection list
Connection ID: 461
Client: 148.87.19.198
Server: ol7-one.sub09151850172.sgdvcn.oraclevcn.com
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
Client: 148.87.19.198
Server: ol7-one.sub09151850172.sgdvcn.oraclevcn.com
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
Client: 148.87.19.198
Server: ol7-one.sub09151850172.sgdvcn.oraclevcn.com
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
Session-Id: ol7-one.sub09151850172.sgdvcn.oraclevcn.com:1513631811119:4662877212585399150
SGD server: ol7-one.sub09151850172.sgdvcn.oraclevcn.com
State: connected
|