On November 10, 2009 Sun Microsystems Netherlands organized a Sun Desktop Update Seminar for customers and Sun partners. The focus of this seminar was the new enhancement and possibilities of the Sun Desktop products focused on the new versions of Sun Virtual Desktop Infrastructure, Sun Ray Server Software and Sun Secure Global Desktop.

I was one of the speakers of this seminar and gave a presentation on the (new) security aspects and deployment options of Sun Secure Global Desktop.

Download theslides of my presentation:
Secure Desktop, Going beyond the default security ... .

Find here download links to the other presentations.

Installing and configuring Sun Secure Global Desktop for testing is easy. Most administrators use the same steps to install SSGD on an Acceptance and/or Production environment, but the requirements for a Acceptance/Production environment should be a bit different. When exposing a service to the Internet the service is open for anyone including people with less positive intentoions.

SSGD is secure by design and the security certifications are enough for Intelligence Agencies to use SSGD as their product for remote access to applications.

There are however minor modifications possible for the SSGD web server to enhance the security even more. For instance the default installation of SSGD provides the version and the installed modules of the Apache web server.

It is advisable to check / modify the configuration as described below.

Remove version information from server response header field:
Add the following line in the server config part of httpd.conf. If you don't know where place it below the 'ServerRoot'-directive.

ServerTokens Prod

(file /opt/tarantella/webserver/apache/<version>/conf/httpd.conf)


Remove directory listings of directories without default web-page (apache):
Edit http.conf and for every line starting with 'Option' add the minus sign for 'Indexes'. For example:

change in file /opt/tarantella/webserver/apache/<version>/conf/httpd.conf

Options Indexes FollowSymLinks

to

Options -Indexes FollowSymLinks

Remove directory listings of directories without default web-page (tomcat):
Open file web.xml and look for ' listings'. Set the param-value to false. This setting is correct in some versions of SSGD.

change in file /opt/tarantella/webserver/tomcat/<version>/conf/web.xml

<init-param>
  <param-name>listings<:/param-name>
  <param-value>true<:/param-value>
</init-param>

to

<init-param>
  <param-name>listings<:/param-name>
  <param-value>false<:/param-value>
</init-param>

Remove stack-traces for erroneous jsp-files:
This option is very usefull on production servers when for instance the Look&Feel of the webtop pages has been altered. The simplest way is to show a default error-page for erroneous pages. When the error-page does not exsist Tomcat will return an empty page (hence no java stack traces).
change in file /opt/tarantella/webserver/tomcat/<version>/conf/web.xml

</web-app>

to

<error-page>
  <exception-type>java.lang.Exception</exception-type>
  <location>/internalError.html</location>
</error-page>
</web-app>

For more SSGD Security information (including these options) take a look at the 'Secure Deployment Checklist' at wikis.sun.com. An other good article is: 'HOWTO Secure Access to the Administration Console'.

Just keep in mind connecting any server to the Internet requires good security settings independent on how secure the product is by default.

When a users logs out of the SSGD webtop with the logout-button the logged-out-page is shown. The logged-out-page contains a login-button. The login-button is not always 'active' (when clicking on the login-button nothing happens).

When looking into the JSP-code of the logged-out-page the 'activation' of the login-button is based upon the status of the TCC (Tarantella Client Connector/a SSGD-application which displays the applications). When the TCC is still running the login-button is 'activated'. This is a bit strange since logging out of the SGD webtop will stop the TCC.

/opt/tarantella/webserver/tomcat//webapps/sgd/webtops/standard/webtop/logged-out.jsp
I saw a check to 'enable' or 'disable' the login-button. The button is 'enabled' when the TCC is stll running.


A quick fix to always show the link by editing the logged-out-page. Follow these steps:

• Logon to the SSGD server

• Go to the directory:
  /opt/tarantella/webserver/tomcat//webapps/sgd/webtops/standard/webtop

• Edit the file:
  logged-out.jsp

• change line (109 for SGD4.50) from

boolean showLoginLink = (tccStarted != null && tccStarted.equals("true"));

• to

boolean showLoginLink = (tccStarted != null && tccStarted.equals("true"));
showLoginLink = true;

After this change verify the change by logging on to the webtop and log out again to see if the login-button is 'active'.

The latest news of the new SSGD version was announced on the SSGD Forum by Jeff Jameson. 

Download version of 4.5 will be available at release on May 12, 2009. GA and the availability of the media kit is slated for May 26th, 2009.
The 4.5 documentation is already available on Suns Documentation site:

• Release Notes
• User Guide
• Installation Guide
• Administration Guide
• Gateway Administration Guide

In May 2009 the new version (4.5) of Sun Secure Global Desktop (SSGD) will be released. There are no Release Notes of this new version yet.

More information will be provided around the launch of the new version.

During installation of Sun Secure Global Desktop (SSGD) a couple of extra web tools are created for SSGD Administrators/Developers. One of these web tools is an API testing tool for Developers. The base URL is:

http://[FQDN_SSGD_Server]/sgd/admin/apitest/

The webpage shown on this URL is divided in two parts. The left containing a menu where all the API-calls can be found and on the right hand side there is space for the result of the performed API-calls.



All available API-calls can be issued by using the menu. Most of the menu-items have a sub-menu with the actual API-calls. In the following example we will only use the menu-items 'webtopsession' and 'emulatorsession'.

(SSGD version 4.4 and higher)

To manually start an application using API calls at least to following steps need to be performed:

1. Authenticate the user
2. Set the configuration of the TCC (The SGD Client Connector)
3. Start the TCC
4. Start the SGD Application

Since SSGD version 4.4 it is not needed to set up a new session before authentication, but the authentication can be done directly. Basically there are two types of authentication:

• System Authentication; The authentication is performed from within SSGD using the provided username and password.
• Third Party Authentication; The authentication is performed by a trusted external application/service which passed the user-ID to SSGD.

In this example we will be using the System Authentication for simplicity.

Authenticate the user by using the main API-test menu item: webtopsession
Use the function: authenticate
The only mandatory fields are 'Username' and 'Password'. Use a valid username and password and use the button 'Call' to perform the authentication.

In the right frame the result is shown with the most important attribute 'scottasessioncookie'. This attribute contains the ID of the 'webtop'-session. With the field 'Auto-fill Cookie' enabled the the session ID will be filled in automatically for all following API calls.

The TCC can be started via a separate webpage containing the TCC-Helper-plugin. This plugin is a Java-applet which will:

• Check if the correct TCC is already 'installed', if not download the TCC
• Start the TCC with the correct parameters

To create the TCC Helper webpage containing the required applet and parameters the API-call 'startTCC' can be used (API-test main menu -> webtopsession -> startTCC). Besides the 'Session Cookie' no extra information is required. The parameter 'Target' can be used to open the new webpage in a particular frame.

If all goes well the TCC will be started and we are ready to start a SSGD Application.

An application can be started by starting an Emulator Session. We therefor switch to an other main menu item: emulatorsession.
The API-calls in the group 'emulatorsession' can be used to start, resume, suspend and list application sessions.

To start an application go to the API-call startSession (API-test main menu -> emulatorsession -> startSession). Fill in the Application Name (like: .../_ens/o=applications/cn=My Desktop) and click 'Call'.
To see which applications the user may start an API-call from the 'webtopcontent'-group must be used (searchWebtopContent), but a simple shortcut for this command is available: 'List Webtop'

The Application will start up just like it will be when clicking the Application-link in the browser-based-webtop.


On the Sun wiki a example JSP-file is available which performs the same API-calls: Single sign-on JSP

By placing the attachement in the directory

/opt/tarantella/webserver/tomcat/[version]/webapps/sgd

After providing the same information from the example above in the JSP-file, the manual called API-calls can be performed automatically.



Perform the following API-calls to start an application:

1. webtopsession -> authenticate : Provide Username and Password
2. webtopsession -> setTCCConfiguration
3. webtopsession -> startTCC
4. emulatorsession -> startSession : Provide Application-name

Sun Secure Global Desktop has a Web based Application Programming Interface (API). This API can be used to interact with the SSGD server from within a browser (by creating for instance JSP-files) or by creating a piece of java code to communicate with the SSGD server over http(s).

This opens up a lot of extra possibilities besides the already feature rich SSGD webtop, the web based Administration GUI and the other default options (like the Integrated Mode, Automatic Client Login). A few examples of features to be created using the API:

• A search page in the webtop; Let the user search for applications based on application name. might be handy if the user is presented with lots of applications.
• Remote Administration; Create applications objects from other systems (like Sun Identity Manager), create delegated administration.
• Create a webtop alike alternative without using a browser; With some java programming it is possible to re-create something with the same options as the webtop without use of a browser.
• Create a SSGD Health check; Most external hardware Load Balancer are able to check a specific webpage to verify the correct workings of the website besides the mostly used 'HTTP 200 OK' / Default HTTP check. The new health check can for instance perform the 'Tarantella status' command to enhance the health check by verifying the SSGD server is working normally.

It is my intention to explain how to work with the SSGD API in the next couple of blog posts. For the readers who do not want to wait and start playing with the API take a look at the Sun Wiki: Web Services Home Page.

Part 2 of this blog post serie will be about the API-test pages which are installed during the installation of Sun Secure Global Desktop.

Today one of our customers stated that on their Mac clients the keyboard input was not passed to the applications provided by Sun Secure Global Desktop. They have searched the internet for a solution, but it is hard to find the simple fix.

Since MacOS 10.5.1 the location of the file XKeysymDB has been changed. When creating a symbolic link for this file in the 'old' location resolved the issue mentioned above.

ln -s /usr/X11/share/X11/XKeysymDB /usr/X11R6/lib/X11/XKeysymDB

Hopefully this post will make it easier to find this little fix.

The Installation Guide of Sun Secure Global Desktop 4.41 states:

The system must have ttaserv and ttasys users and a ttaserv group before you can install SGD.

The commands to create these users are described in the Installation Guide, but there might be a simpler way to create them.

Last week I performed an installation and thought the users had been created. After the hitting the "Enter"-key for the installation I got a message stating the ttasys and ttaserv users could not be found and to create these users the following command can be performed:

/tmp/SGDCreateUsers.sh

Just run this script to create the ttasys and ttaserv users including the ttaserv group. Re-issue the installation command and continue with the installation process.

So installing is getting simpler and simpler. Almost so simple no Manual needs to be used, but I advise to always use the Installation Guide open during installation. Especially the Operation System Modifications page.

The 4.41 version of Sun Secure Global Desktop has been released and can be downloaded via the following link:

https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=SGD-4.41-SP-LX-G-F@CDS-CDS_SMI


This updated contains the following updates/changes (see blog post "ssgd4.41 to be released soon" :

• New Command for Securing an SGD Server


• Pull-Down Header for Kiosk Mode Applications


• Service Tag Support


• Active Directory Authentication Log Filter


• Active Directory SSL Security Without Client Certificates

Documentation of the 4.41 release can be found at:
http://docs.sun.com/app/docs/coll/1706.3
and on
http://www.filibeto.org/sun/sgd-users/sgd.html#sgd-4.41-docs

Sun is releasing the new version of Sun Secure Global Desktop (4.41) in September 2008.

The release date was announced in the Sun Secure Global Desktop Forum:
(http://forums.sun.com/forum.jspa?forumID=815)

The release notes of this new version can be found at:
http://docs.sun.com/source/820-4905/index.html

This week I got a question from one of our customers: Is the the SGD Enhancement Module (formerly know as Tarantella Enhancement Module/TEM) supported on Windows 2003 64 bit?

The answer would be simple when looking at the "SGD Enhancement Module Requirements" on
http://docs.sun.com/source/820-2548/chapter1.html#d0e1434
but there was only a statement which said:

Supported Version - Windows 2003

But no reference to it being the 32 bit or the 64 bit version.

A quick question to Sun gave the following response:

We explicitly call out the systems where we support just 32 bit.
Here only the Linux OS's are 32-bit versions. All the other
OS's are both 32-bit and 64-bit versions. It's a implied.


This means the SGD Enhancement Module is supported for Windows 2003 64 bit (as well as the 32 bit version).

A small update to the Sun Secure Global Desktop is about to be released. This update contains 5 new features (besides 123 bug and 1 documentation fix).

• New Command for Securing an SGD Server
  
  A very easy command to enable security without changing files, creating certificates manually. More on this subject in a later post.
  


• Pull-Down Header for Kiosk Mode Applications
  
  Sometimes needed to temporary switch between your local and remote session. This option can be changed per application on the command-line.
  


• Service Tag Support
  
  More information on Sun Connection: Register
  


• Active Directory Authentication Log Filter
  
  Once again a better way to perform debugging :)
  


• Active Directory SSL Security Without Client Certificates
  
  This will make it easier to connect to Active Directory in a secure way. The secure connection is needed to be able to let users change there Active Directory password via SGD.
  

The documentation of this new release can be found on the document website of Sun: Sun Secure Global Desktop Software 4.41 Collection. (With a PDF-version of the Administration Guide :) )

The SSGD 4.41 version is currently not yet available for download, but will be soon.

There are some extra features of Sun Secure Global Desktop (SSGD) which are only known to a few SSGD Administrators. It is my intention to post information on these features on this blog.

Today I will start with a set of pages for Administrators and SSGD Developers and explain what their function is.

If you have SSGD installed take a look at:

http(s):///sgd/admin

On the URL above the following subdirectories are visable:

• apitest; Pages for developers to test SSGD API calls,


• checker; A simple reloading page to see who is logged on,


• configmgr; The old configuration wizard (used to be available on the Administrator webtop),


• datastore; a very simplistic view of all the object in the datastore (nice for Developers),


• loaddist; Contains the swcd.jsp, which is a software based SSGD Loadbalancing script (I will surely post more on this one in a separate post),


• printman; Shows the printqueue of SSGD,


• profiles; Create or edit the profiles for the current user,


• sessman; The old SSGD Session Manager,


• sessmgr; A simple (not reloading page) to see who is logged on,


• sessxml; Also a simple (not reloading page) to see who is logged on<./LI>
  

Most of these pages require an SSGD Administrator to log on before they show information. Normal users are unable to get more information then they get on theire normal webtop.

Although it is save to have these webpages open on the internet I want to suggest to disable access to these pages or completely remove them from your system (a move of teh directory "/opt/tarantella/webserver/tomcat//webapps/sgd/admin" to "/tmp" will do as well).

More on these extra lesser known features in later posts.

(PS: Sorry for the 3 month silence not posting to my blog. I will do my best to make sure this won't happen again.)

There was a small bug regarding password changes during the authentication process when Sun Secure Global Desktop (SSGD) is using the Active Directory authentication. This bug was a bug in the underlaying Java of SSGD. A new version of Java is available since this week with a fix for this bug.

Information and instructions to upgrade the Java version for SSGD see the blog post on Mr PotatoHeads blog:
Potato Peelings

Last week I attended the "Deep Dive in the Alps"-event (officially know as Software Technical Event @ Sun Grenoble Engineering Center).

Lots of new information, too many things to put in one post. Therefor I will make multiple posts about the Deep Dive in the Alps :)

A small starter:

• There is a JSR-168 Portlet for Sun Secure Global Desktop.

An Enterprise portal is a framework for integrating information, people and processes across organizational boundaries. It provides a single point of entry and is designed to aggregate information through application-specific portlets.

"Portals unlock business processes and resources for external access,
while maintaining the security, identity and access controls"
- The Burton Group

The current portlet version (1.00.901) is working for SSGD 4.2/4.3/4.3.1
Since there have been made changes in the authentication a new portlet will be created. The new portlet will make use of the new Web-services for SSGD.


Although the dive in the Alps was deep,
"The world is Flat"

The new Sun Secure Global Desktop version 4.4 is available for download !

Feature headlines fro this version:

• New web-based Management Console


• Solaris 10 Trusted Extensions as an SGD client, SGD server and application server platform


• VDI support with MyDesktop


• Windows client Roaming Profile support


• Idle Timeout


• Server rename

Download SSGD 4.4

As stated before the documentation for this version can be found on the Sun Documentation website. The documentation can also be downloaded from filibeto.org.

Sun Secure Global Desktop comes standard with a couple of application icons.

Most users do not really care about the icon in front of the Application name, but there are some who are more visually focussed then textual. For the latter (and also for the other users) it would be nice to add new icons to SSGD.

New icons can be added to SSGD. This means every application can have its own normal icon if that icon is not in the default set of icons.

The following text may require knowledge of the Solaris/Linux Operating System.

Adding a new icon to SSGD can only be performed by the root-user of the SSGD server (hopefully the new version of SSGD, 4.40, will have a nice feature for adding icons).

Instructions for adding a new icon (version 4.2/4.3/4.31):

1. Create an icon with size 20x20 with 256 or 16bit colour in gif or jpg format


2. Copy the icon to the SSGD server (via scp/ftp or alike)


3. As root copy the icon to the following location:
   

   /opt/tarantella/webserver/tomcat/<version>/
                webapps/sgd/resources/images/icons



4. make sure the group ttaserv has read permissions on the icon
   

   chgrp ttaserv <iconname>;chmod g+r <iconname>

It is now possible to set the icon-name for the application via the command line:

/opt/tarantella/bin/tarantella object edit
             --name <end_objectname> --icon <iconname>

Changing icons via the Object Manager is also possible. Just copy the icon file to the following location and restart the Object Manager.

/opt/tarantella/var/docroot/resources/
             icons/sco/tta/standard/locale=en-us.size=24

(This will also make the icon available for the classic webtop)

When looking at the documentation and the configuration of Sun Secure Global Desktop it can be confusing to see several references to DNS names and sometimes IP-addresses. I hope this post will bring some light on which is which and help to understand when to use which name or IP-address.

The following picture shows the naming of the different Network Interfaces. The "External" refers to the connection between the client and the SGD server and the "Peer" to the connection between the SGD server and the other SGD server within the SGD Array.


First the DNS names. There are two important DNS-entries, the Peer DNS Name and the External DNS Name. These can be the same in a simple installation, but mostly they will be different.

• Peer DNS Name
  

  "A Peer DNS Name is the DNS name that the Secure Global Desktop servers in the array use to identify themselves and each other."

  
  This is the main DNS entry of the SGD server and specified during installation. This DNS-entry is also used during the communication with other SSGD servers in a SSGD Array. (Both forward and reverse DNS-entries should be available on all SSGD Servers in the SSGD Array). The Peer DNS name can not be changed after installation.
  
  
• External DNS Name
  

  "An external DNS name is the DNS name that the client devices use."

  
  The External DNS name is used at the client, therefor the client must be able to resolve the external DNS name. This is also the name for the SSL certificate (when using secure connections). The External DNS name is not used at the SSGD server or within the SSGD Array.
  
  The external DNS name can be changed via the Array Manager or via the command:
  

  /opt/tarantella/bin/tarantella config edit \
    --server-dns-external "*:<external dns name>"

  
  

Besides the Peer DNS name and External DNS name there are also the Peer Bind IP-Address and the External Bind-IP-Address. After installing the Sun Secure Global Desktop the Peer Bind IP-Address and the External Bind-IP-Address is set to all available IP-Addresses ("*") of the system. For complex installations it is advisable to change this to the IP-addresses of the different Network Interfaces.

• Peer Bind IP-Address
  This IP-address is the IP-address of the Secure Global Desktop server. When the Peer DNS Name is resolved it should resolve to this IP-address and visa versa. It is possible to bind the SSGD software to multiple IP-addresses, one of these addresses should resolve to the Peer DNS Name. Use the following command to change the Peer Bind IP-Address:
  

  /opt/tarantella/bin/tarantella config edit \
    --tarantella-config-server-bindaddresses-peer \
    <Peer Bind-IP-Address>

  
  
  
  
• External Bind-IP-Address
  The SGD software will listen on this IP-address(es) for the client connections. This IP-address can be different from the IP-address after resolving the external-dns-name, since there might be a Load Balancer or SSL-offloader between the client and the SGD server. To change the External Bind-IP-Address use the following command:
  

  /opt/tarantella/bin/tarantella config edit \
    --tarantella-config-server-bindaddresses-external 
    <External Bind-IP-Address>

  
  

When using the SGD Server in Firewall Forwarding Mode a good practice is to change the External Bind-IP-Addresses with the following command:

/opt/tarantella/bin/tarantella config edit \
  --tarantella-config-server-bindaddresses-external 
  "!127.0.0.1"

The SGD Web erver tries to bind to port 443 (the array-portencrypted) on localhost as well. Excluding this 127.0.0.1:443 for the SGD server changes the dependency of the web server being started before the SGD server.

I hope this enlightens the different DNS names and IP-Addresses a bit, if not let me know :)

SUN has released the documentation of the new Sun Secure Global Desktop 4.4.

Besides some small neat new features (like 'Automatic Timeout of Idle User Sessions' and 'Support for Solaris 10 OS Trusted Extensions') the biggest change will be the Administration Console. Up till version 4.3 management of SSGD is done with the Object Manager and the Array Manager. Version 4.4 has the new Web based Console.

The SGD Administration Console is now a single point of administration and is dynamic. For instance, when logging in to the SGD Administration Console you can directly see which servers are up and running and how many webtop and application sessions are running on each server.

More on the new SSGD version in later posts. Look at the release notes of SGD 4.4 if you can't wait :)

The new documentation be found here.

The Thin Guy started a user map using Frappr! This is a nice way to see who is using Sun Ray or Sun Secure Global Desktop or both :)

http://www.frappr.com/sunraysgd

Add yourself and see both products are being used from New Zealand till Hawaii :)

Configuring Sun Secure Global Desktop Applications in small environments (like at home) is very simple. It is easy to see which application is linked to which user and will run at which host.

When the amount of applications, host and/or users grow it can become quite a mess and rather unmanageable. For example adding an extra application server to run the same applications as an other application server (for load balancing purposes) the new application server needs to be added to all the applications.

Fortunately SSGD has Group objects. Group objects can be used to group all different types of SSGD objects (hosts, applications, application servers, profiles and groups). The SSGD groups can be seen as a container to put the objects in and it does not look at the type. It is possible to create a group with different types objects. However to keep everything easy try add only objects of the same type to the group and add the object type to the group name (like WinTermServGrp, FinanceApps or HelpdeskUsers).

Looking at the example above and the knowledge of having groups the example can be made easier to manage and keep everything well organized.

1. First create a group (ie: AppServGrp)
2. Add the 'old' application server to the group
3. Replace the link from all the applications to the 'old' application server with the group (AppServGrp)

If you want to add a new application server to all same the applications running on the 'old' application server the only step to take is:

1. Add the 'new' application server to the group (AppServGrp)

Because it is possible to group different types of objects a lot of possibilities are available to organize the objects well ordered, manageable and very easy :)

Don't forget to use the Organizational Units (OU) to organize the Objects as well.

The first thing a user sees when he/she accesses the SSGD environment is a web page with a scrolling orange dot ('splash screen'). This screen is presented for a couple of seconds before it changes to the 'log on' screen.

The 'splash screen' is a very simple html-page which contains an animated gif image (the orange dot). This web page can easily be changed by following these steps:

1. Create your own 'splash screen' page in html with your favorite web page editor
   (It is wise to have some sort of animation in it to give your users the feeling there is still progress in setting up the SSGD connection)
2. Copy the html code into a text editor (vi,Notepad/Textpad/Ultraedit or alike)
3. Remove everything except the part between <body> and </body>
4. Replace all image locations to <%= path %>
   So

   http://servername/image_dir/image.gif

   is changed to

   <%= path %>image.gif

5. Add the following lines at the top:
   

   <%@ page errorPage="/resources/jsp/errorpage.jsp" %>
   <%@ page contentType="text/html" %>
   <%@ include file="/attributes.jsp" %>
   <%@ include file="/resources/jsp/utilities.jsp" %>
   <%
      String path = getContextPath(request) + "/resources/images/splash/locale=";
      path = path + getBestSupportedLocale(request) + "/";
   %>

6. Copy the new html(/jsp)-code to the file splash.jsp:
   

   /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/
                webapps/sgd/webtops/standard/tcc/splash.jsp

   
   
7. Copy all images used in the page to:
   

   /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/
                webapps/sgd/resources/images/splash/

   
   

To make sure the new 'splash screen' is available clear the browser cache and enjoy your new page :)

When looking at almost all information about Sun Secure Global Desktop (SSGD) it seems that SSGD is only used for access to applications from the Internet which are normally only accessible via the intranet (from within the office). But SSGD can do more ...

The common way to use SSGD is to access applications running on different types of application servers (Windows 2000/2003, *nix, mainframe and more) from the Internet (any device, any time, any place).

SSGD is designed to perform the task of bringing office applications in a secure way to the Internet, but SSGD can also bring Internet to the office :)

Sometimes you might come across a company where access to the Internet is not allowed because of multiple reasons, the most common are:

• Viruses can be installed on the workstation
• Key-loggers can be installed on the workstation
• Security leaks in applications (think of a leak in MSN)
• Installation of insecure applications (for instance: ActiveX components)

There are ways to find solutions for these security issues like installing a proxy, a content/spam/virus filter/scanner, a application firewall (ISO/OSI up to level 7 ) , a messaging gateway. But there is one simple thing which is hard to handle. An employee can simply copy/paste information from a company application to a messenger (MSN/ICQ) or attach documents to a message via an external webmail application.

For all the above issues SSGD can be the solution!


The users can access a browser with access to the internet via SSDG on some sort of 'browser'-host. This 'browser'-host can be a stripped down OS (Windows 2003 or *nix) with only a browser and a couple of readers/plugins (Office readers, PDF viewer, quicktime player, shockwave player, etc). Without Client Drive Mapping and copy/paste to the 'browser'-host turned off, there is no direct way to leak information to the internet.

In this scenario is it impossible for an hacker to get access to the employees workstation. Think for instance about a key-logger. When a key-logger is accidentally downloaded form the internet it can only be installed on the 'browser'-host. The key-logger can 'read' passwords for the web-applications accessed via the 'browser'-host, but it can not 'read' any password on the employees workstation. So no password can be logged for all company applications.

Virtualization can be used to enhance the security of the 'browser'-host. When using for instance VMWare ESX 'reinstalling' the 'browser'-host can be done within minutes, just clone a new virtual machine from a template. This 're-installation' can be done every night or even dynamical when using tools like the VDA-Kit.

Think creative and see the many senario's where SSGD can be a solution and solve issues :)

Most customers like the fact that is quite easy to change the Look and Feel (L&F) of SSGD. Changing the L&F is not not that easy as changing the template of a weblog or a portal, but with a bit of knowledge of HTML the changes can be made in the webtop-pages.

The first change I normally do at a customer site is replace the SUN logo in the left top corner of the webtop:


To change this logo create a new logo image (size: 242 x 77 px) and place this file in the following location:

/opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd/resources/images/webtop

Next edit the file:

/opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd/webtops/standard/webtop/topFrame.jsp

On line 95 change the filename of the Sun Logo (sgdLogo.gif) with the filename of the new company logo.

After the topFrame.jsp has been saved a refresh of the complete webtop page within the browser the new logo will appear.

In future post I will try to describe more simple small changes which can be made to the webtop. Changing the splash-screen during logon is amongst this list I have in my mind. When someone wants to know how to make other changes please write a comment on this post.