Secure Global Desktop 4.40 Administration Guide
> Users and Authentication
> Understanding Application AuthenticationSecure Global Desktop 4.40 Administration Guide
> Users and Authentication
> Understanding Application Authentication
| Read This Topic to... |
|---|
|
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 the Application Authentication dialog as follows:
The Application Authentication dialog allows 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.
By default, users can 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 page describes the configuration options for application server authentication and includes the following topics:
Login scripts are used 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:
The login script also allows for 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.
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. Do not modify the login scripts supplied with SGD, work on a copy instead.
The login scripts supplied with SGD 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.
The login script used for an application is controlled by the Login Script attribute on the Launch tab for the application object.
Secure Global Desktop login scripts are written in Tcl (version 8.4) and Expect (version 5.43). Expect (developed by Don Libes) extends Tcl (developed by John Ousterhout) and provides additional commands for interacting with programs.
By default, SGD stores the user names and passwords used to run applications in its application server password cache. Entries in the password cache are encrypted with an encryption key. When running applications, the passwords are decrypted as they are needed. You can configure SGD to generate a new encryption key for the password cache whenever an SGD server restarts. Existing entries in the password cache are re-encrypted with the new key.
In the SGD Administration Console, you can manage the application server password cache as follows:
On the command line, you manage the application server password cache with the tarantella passcache family of commands.
You can use the SGD 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 password cache entry involves the following elements:
--resuser) - the user name for the application server--respass) - the password for the application server--resource) - the application server for which the password is cached--person) - the user identity of the user that "owns" the entry in the password cacheNote The user's SGD password can also be stored in the password cache.
In the SGD Administration Console, the attributes on the Global Settings » Application Authentication tab control application authentication. These attributes allow you to configure the following:
When starting applications on Microsoft Windows application servers, the user can change the domain using the NT Domain field on the Application Authentication dialog. 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, the NT Domain field is not completed.
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:
Note If the user is authenticated using a Microsoft Active Directory server, you do not need to set the Domain Name attribute on the user profile object as the domain name can be inferred.
When a user starts a Windows application, SGD goes through the following process to establish the domain name and password to use:
If a domain name is set, SGD searches the password cache for a password for the user identity.
If there is no domain name or there is no password, move to step 2.
If a domain name is set, SGD searches the password cache for a password for the user identity.
If there is no domain name or there is no password, move to step 3.
Note If a user is logged in using an Active Directory server, the domain name can be inferred from this.
If a domain name is set, SGD searches the password cache for a password for the user identity.
If there is no domain name or there is no password, SGD prompts the user for the user name and password.
If you want to allow users to specify their own domains, you must ensure that the Domain Name attribute is blank for the user profile object, the application server object, and the application object.
Note A user can also override the Windows Domain attribute by typing a user name in the format domain\name, for example indigo\rusty.
Copyright © 1997-2007 Sun Microsystems, Inc. All rights reserved.