Application Authentication

When a user clicks a link to start an application, the login script configured for the application connects to the application server, handles the authentication process, and starts the application.

The Execution Protocol Engine is the SGD component that runs the login script. The login script authenticates the user to the application server by submitting a user name and password stored in the SGD application server password cache. If there is a problem with the user’s credentials, SGD displays an Application Authentication dialog as follows:

Screen Capture of the SGD Application Authentication Dialog

The Application Authentication dialog enables users to enter their credentials and store them in the application server password cache so that they are not prompted when they next run an application on that application server.

Users can also force SGD to display the Application Authentication dialog by holding down the Shift key when they click an application’s link on the webtop.

This section includes the following topics:

• Login Scripts

• Configuring Application Authentication

• The Application Server Password Cache

• Input Methods and UNIX Platform Applications

• Adding Support for System Prompts in Different Languages

• Using RSA SecurID for Application Authentication

Login Scripts

SGD uses login scripts to handle the connection to the application server, to run the application, and to perform additional tasks.

Typically a login script performs the following tasks:

• Logs in to the application server, prompting the user for a password if necessary.

• Sets environment variables. These are the variables specified by the Environment Variables attribute on the Launch tab for the application object.

• Starts any window manager programs. These are the programs specified by the Window Manager attribute on the Presentation tab for the application object.

• Starts an input method if one is required (UNIX platform applications only).

• Runs the command to start the application.

The login script takes into account the differences between application servers, and checks for any errors that might occur during the login process. If an error is encountered that cannot be handled, control is passed back to the user.

The SGD login scripts are designed to be as universal and robust as possible. However, you might need to cope with an unusual scenario. For example, if you have a system prompt that is not catered for, you can add it to the list of prompts recognized by the script.

The login scripts supplied with SGD also contain commands and procedures that you can use to customize the display of the Application Authentication dialog, for example by adding your own labels for the Username and Password fields.

If you need to customize a login script, make a copy of an SGD login script and work on the copy. Do not modify the standard SGD login scripts. Appendix E, Login Scripts contains detailed reference information about SGD login scripts.

Configuring Application Authentication

In the Administration Console, the attributes on the Global Settings -> Application Authentication tab control application authentication. These attributes allow you to configure the following:

• Whether to automatically try the user’s SGD user name and password when logging in to an application server if these details have been cached

• What action to take if the user’s application server password has expired

• Whether to log in to a Microsoft Windows application server using a smart card

• When to display the Application Authentication dialog, what the default settings are on the dialog, and whether users can change them

The Application Server Password Cache

By default, SGD stores the user names and passwords used to run applications in its application server password cache. SGD also stores the user names and passwords used to log in to SGD.

For Windows applications, the Terminal Server handles the authentication process. No information is returned to SGD indicating whether authentication succeeds or fails, and the details remain in the SGD password cache whether correct or incorrect.

Managing the Application Server Password Cache

In the Administration Console, you can manage the application server password cache as follows:

• The Caches -> Passwords tab – This tab enables you to manage any entry in the password cache

• The Passwords tab for user profile objects – This tab enables you to manage password cache entries for the selected user profile

• The Passwords tab for application server objects – This tab enables you to manage password cache entries for the selected application server

• The Passwords tab for dynamic application server objects – This tab enables you to manage password cache entries for the selected dynamic application server

On the command line, you manage the application server password cache with the tarantella passcache family of commands.

You can use the Administration Console and the command line to list and delete entries in the password cache. You can also create entries in the password cache. With the tarantella passcache command, you can populate the password cache with a batch script.

Each entry in the password cache involves the following elements:

• A user name – The user name for the application server

• A password – The password for the application server

• A resource – The application server, dynamic application server, or domain name for which the password is cached

• A user identity –The identity of the user that “owns” the entry in the password cache

Security and the Password Cache

Entries in the application server password cache are encrypted with an encryption key. When starting applications, the passwords are decrypted as they are needed.

By default, the encryption key used for the password cache never changes. You can configure SGD to generate a new encryption key for the password cache whenever an SGD server restarts. In the Administration Console, go to the Global Settings -> Security tab and select the New Password Encryption Key check box. Alternatively, use the following command:

$ tarantella config edit --security-newkeyonrestart 1

Existing entries in the password cache are re-encrypted with the new key.

Windows Domains and the Password Cache

When SGD caches a user’s password for a Microsoft Windows application server, the password cache entry is created using the Windows domain name.

The domain name can be specified using the Domain Name attribute on application server objects, Windows application objects, or user profile objects. Users can also specify a domain name on the Application Authentication dialog.

When a user starts an application, SGD goes through the following process to establish the domain name and password cache entry to use:

1. Check if a domain name is set on the application server object.

   If a domain name is set, SGD searches the password cache for an entry for the user identity.

   If there is no domain name, or there is no entry in the password cache, move to step 2.

2. Check if a domain name is set on the application object.

   If a domain name is set, SGD searches the password cache for an entry for the user identity.

   If there is no domain name, or there is no entry in the password cache, move to step 3.

3. Check if the user typed a domain name type when they logged in to SGD.

   If you are using Windows Domain authentication, users can specify a domain name when they log in to SGD. They do this by typing a user name in the format domain\name, for example example\rusty.

   If a domain name is set, SGD searches the password cache for an entry for the user identity.

   If there is no domain name, or there is no entry in the password cache, SGD displays the Application Authentication dialog.

The Application Authentication dialog has an NT Domain field that enables users to set the domain name. This field is automatically completed if the Domain Name attribute is set for the application server or application object, or if the domain is cached in the password cache. If the Domain Name attribute is set only on the user profile object, the NT Domain field is not completed.

To force users to specify a domain when they start a Windows application for the first time, you must ensure that the Domain Name attribute is blank for the user profile object, the application server object, and the application object.

If a user’s SGD password is also their Windows domain password, the domain name and password can be cached if the following are true:

• SGD must be configured to save the user’s SGD user name and password in the password cache. SGD does this by default.

• The Domain Name must be set on the user profile object.

  ---

  Note - If the user is authenticated using Windows Domain authentication, you do not need to set the Domain Name attribute on the user profile object as the domain name can be inferred.

  ---

Input Methods and UNIX Platform Applications

An input method is a program or operating system component that enables users to enter characters and symbols not found on their keyboard.

By default, SGD runs an IM for all locales, apart from C and POSIX.

To change the IM configuration, you can edit variables the vars.exp login script. The variables are as follows:

• IM_runByDefault – This variable controls whether an IM is enabled (variable set to 1), or is disabled (variable set to 0) by default. The default is 1.

• IM_localeNotList – If IM_runByDefault is set to 1, SGD runs an IM for all locales, except the locales listed in the IM_localeNotList variable.

• IM_localeList – If IM_runByDefault is set to 0, SGD only runs an IM for the locales listed in the IM_localeList variable.

SGD uses the following environment variables to determine the locale TTA_PreferredLocale, TTA_HostLocale, and LANG. See Login Script Variables.

Adding Support for System Prompts in Different Languages

By default, the login scripts supplied with SGD support English system prompts on application servers. SGD Administrators can add support for system prompts in other languages.

To do this, you edit the vars.exp login script and add a translation for each of the English prompts defined. The vars.exp login script is located in the /opt/tarantella/var/serverresources/expect directory on the SGD server. You do not need to translate every prompt, only the prompts that are different to the English ones. The file contains examples to help you get started. You can also provide translations for the variables, strings, and error message section to match the client or user locale.

In the Administration Console, configure the General tab -> Prompt Locale attribute for your application server objects, to match a locale defined in vars.exp.

Using RSA SecurID for Application Authentication

SGD supports RSA SecurID authentication for X and character applications.

To use SecurID authentication, ensure that users can log in to the application server using SecurID before introducing SGD. When you are ready to use SecurID authentication, configure the application object to use the securid.exp login script.

When logging in to an application server that uses SecurID authentication, users enter a user name and password. When they click OK, they are prompted for a passcode.

In the Administration Console, go to the Global Settings -> Application Authentication tab and deselect the Password Cache Usage check box. This prevents SGD from using SGD login details when logging in to the application server.