Skip to Main Content
Forums

Getting Started: SGD Concepts and Configuration

Jan-OracleDec 14 2017 — edited Nov 4 2020

Introduction

After successfully installing Oracle Secure Global Desktop (SGD) on premise or in a cloud environment like Oracle Cloud Infrastructure (OCI) as explained in this blog post or by simply using the OCI Marketplace image as explained in this blog entry, the user has but the simplest setup to securely access the SGD server itself. This document will describe the terminology used and additional steps to configure SGD to access applications and entire desktops on other instances on premise or in the cloud.

Administration

SGD provides different mechanisms to administer User profiles, Applications and Application Servers. The easiest way to get started would be to use the Administration Console which is being provisioned automatically to all users assigned the Administrator role. It is a web based interface into almost all of the different areas of configuration of SGD.

sgdadminlinkpngsgdaminpng

Alternatively, SGD can be configured via the command line, which allows scripting or automation of tasks. In this document, we will cover concepts of SGD and give examples how to perform certain tasks via the web based UI and the command line.

Concepts

A single SGD server runs in an array of one. Additional servers can be added to the array for load balancing and high availability. SGD manages internal configuration information in Objects that are stored within the SGD server, and replicated to other SGD servers of an array.

Note: if the SGD server is setup to run in a co-located environment (ie. the SGD gateway and SGD server are on the same system), an array can only contain one server. To create an array with multiple servers you need to drop the gateway from the configuration and setup the gateway on its own instance. See this article which outlines the steps to take.

Throughout this article I will capitalize terms referring to SGD concepts, like Application, Group etc.

Structure of SGD Objects

User Profiles, Applications and Application Servers can be stored in hierarchical structures in the SGD configuration data store, similar to a filesystem structure of directories and files. Additionally, Applications and Application Servers can be  managed in Groups. This is helpful to manage the assignment of Applications to User Profiles (just assign a Group of Applications to the User Profile instead of individual Applications), or create a Group of Application Servers to then assign the Group to an Application, thus allowing easier management of which servers an Application can be launched on, eg. Group Unux Servers contains all Unix Application Servers and this group is assigned to the Application gnome terminal.

User Profiles

User Profiles are the mechanism of authorization, ie. what can an authenticated user do. When a user authenticates to SGD, either through UNIX accounts, LDAP, Active Directory or Single Sign On (SSO) provided via Oracle Identity Management (OIM), a match is made to a User Profile based on the mechanism of authentication, or by providing a specific User Profile. Individual applications can be assigned to these profiles, or entire groups of applications.

Applications

Applications in SGD define what should happen when an authorized user is clicking on the Application in the web based workspace. The definition of the Application controls how a connection to an Application Server should be established, what command should be run, how the Application should be presented to the user and with what features enabled, like copy & paste. It also defines which Application Servers the command can be executed on and which User Profiles are authorized to start the Application.

Application Servers

An Application Server is an internal definition of assets on which an Application can run. The servers can be named and organized hierarchically to represent an organization, lab or cloud tenancy. SGD can manage these objects with Fully Qualified Domain Names (FQDN) or by providing an IP address, thus providing yet another level of abstraction. Eg. a server can be called database production in SGD and reference the actual FQDN/IP of the production server, making it easier to identify the infrastructure. Application Servers can also be grouped to make it easier to assign multiple servers to an application.

Command Line to Manage Objects in the Data Store

As mentioned before SGD can be controlled via the Web based Administration Console, which is relatively self-explanatory once the overall concepts are understood, or via the command line. The latter allows to document, preserve and replicate configuration steps and also allows scripting to speed up creation of multiple objects. In this article I will provide a couple of examples how to use the tarantella object command, but for a comprehensive list of options please consult the documentation.

In the following example we create organizational units, applications and User Profiles.

First we add an organizational unit to our top level organization, applications and appservers structures (every SGD datastore has o=organization to manage User Profiles, o=applications to manage the Applications and o=appservers to manage the Application Servers). I will name it example.com.

# /opt/tarantella/bin/tarantella object new_orgunit --name o=applications/ou=example.com
# /opt/tarantella/bin/tarantella object new_orgunit --name o=appservers/ou=example.com
# /opt/tarantella/bin/tarantella object new_orgunit --name o=organization/ou=example.com

Let us add an Application Server to that directory.

# /opt/tarantella/bin/tarantella object new_host \
  --name o=appservers/ou=example.com/cn=testserver10 \
  --address 10.0.0.10

As an optional step we create a Group in the same place that could contain all our test Application Servers for example.com.

# /opt/tarantella/bin/tarantella object new_group \
  --name o=appservers/ou=example.com/cn=TestServers \
  --member o=appservers/ou=example.com/cn=testserver10

We need an Application, so we define one that launches a gnome terminal and provide our Group of TestServers as potential launch candidates.

# /opt/tarantella/bin/tarantella object new_xapp \
  --name o=applications/ou=example.com/cn=gnome-terminal \
  --width 400 \
  --height 200 \
  --app /usr/bin/gnome-terminal \
  --args "--fullscreen" \
  --displayusing clientwm \
  --appserv o=appservers/ou=example.com/cn=TestServers

We assign a gnome-terminal Application to the organizational unit for User Profiles, so all members of that unit will inherit this Application.

# /opt/tarantella/bin/tarantella object add_link --name o=organization/ou=example.com --link "o=applications/ou=example.com/cn=gnome-terminal"

Last but not least, we create a user in that organization and also tell it to inherit the applications from the parent.

# /opt/tarantella/bin/tarantella object new_person \
    --name o=organization/ou=example.com/cn=user_profile \
    --surname Last \
    --inherit true \
    --email email@example.com\
    --user os_level_user \
    --description "A new SGD User Profile"

If we need to create several users, we can create a file and feed it to the command. Almost all of the tarantella object commands allow to feed it input via the --file option

# cat <<EOF > /tmp/user_profiles.dat
--name o=organization/ou=example.com/cn="John Smith" --surname Smith --user jsmith --email john.smith@example.com --inherit true
--name o=organization/ou=example.com/cn="Fred Miller" --surname Miller --user fmiller --email fred.miller@example.com --inherit true
EOF
# /opt/tarantella/bin/tarantella object new_person --file /tmp/user_profiles.dat

To really speed things up, you can put all of the above into a single batch file and feed it to the tarantella object script command (the script option actually reads its input from stdin). This is the fastest way to create objects via the command line.

Here is an example with the above individual commands, but I added another Application Server and also add a so-called Dynamic Application Server to the Group TestServers, the SGD Broker; it allows a user to choose in case there are more than one Application Servers available for an Application.

# cat <<EOF > /tmp/script
new_orgunit --name o=applications/ou=example.com
new_orgunit --name o=appservers/ou=example.com
new_orgunit --name o=organization/ou=example.com
new_host --name o=appservers/ou=example.com/cn=testenvironment10 --address 10.0.0.10
new_host --name o=appservers/ou=example.com/cn=testenvironment11 --address 10.0.0.11
new_group --name o=appservers/ou=example.com/cn=TestServers --member o=appservers/ou=example.com/cn=testenvironment10
add_member --name o=appservers/ou=example.com/cn=TestServers --member o=appservers/ou=example.com/cn=testenvironment11
add_member --name o=appservers/ou=example.com/cn=TestServers --member "o=appservers/cn=SGD Broker"
new_xapp --name o=applications/ou=example.com/cn=gnome-terminal --width 400 --height 200 --app /usr/bin/gnome-terminal --args '--fullscreen' --displayusing clientwm --appserv o=appservers/ou=example.com/cn=TestServers
add_link --name o=organization/ou=example.com --link 'o=applications/ou=example.com/cn=gnome-terminal'
new_person --name "o=organization/ou=example.com/cn=John Smith" --surname Smith --user jsmith --email john.smith@example.com --inherit true
new_person --name "o=organization/ou=example.com/cn=Fred Miller" --surname Miller --user fmiller --email fred.miller@example.com --inherit true
EOF
# /opt/tarantella/bin/tarantella object script < /tmp/script
>>>>>>>>>
#

This should give a good introduction to the command line to manipulate the SGD data store. Again, please consult the documentation for all available sub commands and options for the tarantella object command.
Comments
Post Details
Added on Dec 14 2017
#legacy-documents, #oracle-virtualization, #secure-global-desktop
0 comments
1,593 views