Secure Global Desktop 4.40 Administration Guide > Users and Authentication > Authentication Token Authentication
Authentication token authentication allows users to log in to SGD if the SGD Client submits a valid authentication token.
Authentication token authentication can only be used when the SGD Client is operating in Integrated mode and a user has previously generated an authentication token.
Authentication token authentication is disabled by default.
This page includes the following topics:
When the SGD Client starts, it submits the authentication token to SGD. The user does not enter a user name or password.
If the authentication token is invalid or the SGD Client does not submit a token, the user is not logged in. The SGD login screen is displayed in a web browser so that the user can log in using another system authentication mechanism.
If the SGD Client submits a valid authentication token, the user is logged in.
The SGD server stores the authentication token against the identity of the user when they generated their authentication token. This means the user identity and user profile used are those of the authentication mechanism that originally authenticated the user.
Application sessions and password cache entries belong to the user identity of the original authentication.
When a user generates an authentication token and saves their client profile, the SGD server sends the authentication token to the SGD Client. The SGD Client stores the token in the profile cache on the client device. To ensure an authentication token cannot be intercepted and used by a third party, use secure (HTTPS) web servers and enable SGD security services.
When a user generates an authentication token, SGD maintains a record of the tokens issued in a token cache. SGD stores the authentication token using the current identity of the user when the token was generated. When a user logs in with an authentication token, the authentication token allows SGD to "remember" the user's original identity and user profile. All user sessions and application sessions are managed using the original user identity and user profile. If the original login becomes invalid, for example because the UNIX system account is disabled or the password has expired, the user can still log in automatically if they have a valid token. However, they cannot run any applications using the invalid credentials.
To enable automatic logins with authentication tokens:
The user must log in and be authenticated by another authentication mechanism so that SGD can store a user identity and user profile when the user generates an authentication token.
You can use third-party authentication, or any of the other system authentication mechanisms, apart from anonymous user authentication.
Use secure connections between SGD Clients and SGD servers to prevent the interception of authentication tokens.
Use secure connections between client devices and SGD Web Servers to prevent the interception of authentication tokens.
Client profile editing must be enabled to allow users to generate authentication tokens. You can enable profile editing for all users or just for users that require authentication tokens.
See Configuring Authentication Token Authentication for details.
Enable Integrated mode in the client profile and generate an authentication token. If a user logs in to different SGD servers, an authentication token is needed for each SGD server.
See Configure the Client Device for Automatic Logins for details.
On the Global Settings » Secure Global Desktop Authentication tab, click the Change Secure Global Desktop Authentication button.
The following procedure is performed by users and enables automatic logins on the client device. If a user logs in to different SGD servers, they must repeat this procedure on each server.
Profile editing must be enabled for the user.
On the webtop, click the Edit button. The Edit Client Settings page displays.
If the check box is selected, the user is logged in automatically to SGD when they log in to the desktop.
The box might already be selected if a Secure Global Desktop Administrator has configured the client profile using the Profile Editor tool.
You must log out of SGD and log in again for changes to a client profile to take effect.
Users must click the SGD Login link in their desktop Start menu to use automatic logins. If the Connect on System Login check box in the client profile is selected, this happens automatically when a user logs in to the desktop.
Administrators can use the SGD Administration Console or the command line to administer authentication tokens. You can view the tokens in the token cache and delete them. You can also prevent users from generating new tokens.
You view the users (either by the user identity or the user profile) that have authentication tokens as follows:
tarantella tokencache list
Deleting a token from the token cache makes the token stored on a client device invalid. If the SGD Client presents an invalid token, the user is prompted to log in with a user name and password. The user must then generate another authentication token if they want to log in automatically.
You delete authentication tokens as follows:
tarantella tokencache delete --username username | --all
The username
must match the user name displayed by the tarantella tokencache list
command.
Use --all
to delete all tokens from the cache.
Note You can run this command on any SGD server in the array. The change is replicated to the other servers in the array.
Use this procedure to prevent SGD from issuing new authentication tokens. If authentication token authentication is still enabled, users with existing authentication tokens can still log in.
tarantella config edit --login-autotoken 0
To troubleshoot problems with automatic logins, use the following log filters:
server/login/*:destination server/tokencache/*:destination
The server/login/*
filter allows you see when authentication tokens are used for authentication and when they fail. The server/tokencache/*
filter allows you to see errors with operations on the token cache, for example to see why a token is not added to the cache.
Copyright © 1997-2007 Sun Microsystems, Inc. All rights reserved.