Secure Desktop, Going beyond the default security ...

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.

SSGD modifying Apache and Tomcat for production

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.

Login button on logged-out-page not always 'active'

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'.

Sun Secure Global Desktop 4.5 to be released on May 12, 2009

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

Sun Secure Global Desktop 4.5 to be released in May 2009

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.

Playing around with the SSGD API (Part 2 : API-test pages)

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'.

Example:

Start an Application by using the API-test pages.

(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

Authenticate the user

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.

Set the configuration of the TCC

Before starting the SGD Client Connector (TCC) we must provide where the TCC can be downloaded, which version of the TCC must be used and which OS the user is using. This information can be specified via the setTCCConfiguration API-call (API-test main menu -> webtopsession -> setTCCConfiguration). By default all information is already filled in with the known information. (There is no need to change this information for use with the API-test tool, unless you are using SSL-offloading or using an external webserver).
Just a click on the 'Call' button is sufficient to provide all information.

Start the TCC

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.

Start the SGD 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.

Same Example in JSP-file

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.

Example Summary

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

Playing around with the SSGD API (Part 1: Introduction)

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.