Secure Global Desktop 4.40 Administration Guide > Users and Authentication > Web Server Authentication

Web Server Authentication

Web server authentication (HTTP authentication is the technically correct term) is the most common application of third-party authentication. With web server authentication, the web server performs the authentication and SGD determines the user identity and user profile.

The advantage of web server authentication is that you can use any web server authentication plug-in as long as it sets the REMOTE_USER environment variable. If the authentication plug-in you use sets a different variable, you can configure SGD to support it.

You can use web server authentication and system authentication together. It is best to enable at least one system authentication mechanism as a fallback. If SGD cannot find a user profile for a user, the standard SGD login page displays so that the user can authenticate using a system authentication mechanism.

This page includes the following topics:

• How Web Server Authentication Works
• Security Considerations of Using Web Server Authentication
• Enabling Web Server Authentication
• Using Authentication Plug-ins With Web Server Authentication
• Using Client Certificates With Web Server Authentication

How Web Server Authentication Works

Web server authentication works as follows:

• A web server administrator protects a section of a web site. For SGD, this is usually the http://server/sgd URL.
• When a web browser first tries to access a URL within the protected section, the web server responds by requesting authentication.
• The web browser displays an authentication dialog to the user. SGD users do not see the SGD login screen.
• The user types a user name and password, which the browser sends to the web server.
• The web server authenticates the user's credentials and allows access to the requested URL. SGD users go directly to their webtop.

The web browser caches the user's credentials because the credentials must be sent with every request to the protected URL. The browser sends the credentials automatically. The credentials are cached as follows:

• Temporarily - the credentials are cached until the user closes the browser.
• Permanently - the user selects the check box on the browser's authentication dialog.

User Identity and User Profile

Once the web server has authenticated the user, its sets the REMOTE_USER environment variable. This variable contains the user name of the authenticated user. SGD takes the value of the REMOTE_USER variable and uses it to search for the user identity and user profile. SGD supports four search methods for establishing the user identity and user profile. These are described in Third-party Authentication.

Security Considerations of Using Web Server Authentication

The following are the main security considerations of using web server authentication with SGD:

• Web browser cache.

  With web server authentication, the web browser caches the user's credentials and, in effect, their authentication to SGD. To minimize the risk of cached credentials being used by someone else, ensure that users do the following:

  • Deselect the save password check box in the web browser authentication dialog - This ensures that user credentials are not saved permanently by the web browser.
  • Close the web browser after logging out - This clears the user's credentials from the temporary cache. Logging out of SGD does not clear the credentials.
• Secure web server.

  Use a secure (HTTPS) web server to prevent user credentials from being sent in plain text.

• Trusted user.

  SGD is able to trust the web server's authentication because the SGD webtop and the SGD server have a shared secret which is the user name and password of a trusted user. The credentials of this trusted user are created by default when you install SGD. You might want to change these credentials, see Trusted Users and Third-party Authentication for details of how to do this.

Enabling Web Server Authentication

To enable web server authentication, you must do the following:

1. Configure the web server for web server authentication.
2. Configure SGD for Third-Party Authentication.

Configuring the Web Server for Web Server Authentication

You configure the web server for web server authentication by protecting the /sgd URL on each SGD host. How you protect the /sgd URL depends on your web server, see your web server documentation for details.

The following procedure is an example of how you might configure the SGD Web Server for web server authentication. For the SGD Web Server, you can protect the /sgd URL in either the Apache or the Tomcat components. This procedure assumes you protect the URL in Apache.

Repeat the following steps on each SGD server in the array.

1. Become superuser (root).
2. Create a web server password file.

   Use the /opt/tarantella/webserver/apache/version/bin/htpasswd program to create a web server password file and add entries.

3. Edit the Apache configuration file and protect the /sgd URL.

   The Apache configuration file is /opt/tarantella/webserver/apache/version/conf/httpd.conf.

   1. Insert the following directives at around line 358:

      SetEnvIf Request_URI "\.(jar|gif)$" sgd_noauth_ok
      
      <LocationMatch /sgd>
         Order Allow,Deny
         Allow from env=sgd_noauth_ok
         AuthUserFile file-path
         AuthName auth-domain
         Authtype Basic
         Require  valid-user
         Satisfy  any
      </LocationMatch>

      Where file-path is the full path to the web server password file and auth-domain is the name of authorization realm that appears in the web browser's authentication dialog.

      The SetEnvIf directive allows you to protect the /sgd URL without affecting the operation of the Welcome Page of the SGD Web Server.

      Note You must use a LocationMatch directive rather than a Directory directive because the SGD Web Server delegates the management of the /sgd URL to Tomcat. This is configured in the Apache configuration file and means you cannot use an .htaccess file to protect the /sgd URL.

   2. Save the Apache configuration file.
4. Configure the Tomcat component of the SGD Web Server to trust the web server's authentication.
   1. Edit the Tomcat configuration file.

      The Tomcat configuration file is /opt/tarantella/webserver/tomcat/version/conf/server.xml.

   2. Amend the configuration of the Coyote/JK2 AJP 1.3 Connector.

      Add a tomcatAuthentication="false" attribute to the the <Connector> element as follows:

      <!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -->
      <Connector port="8009" minProcessors="5" maxProcessors="75"
                 enableLookups="true" redirectPort="8443"
                 acceptCount="10" debug="0" connectionTimeout="0"
                 useURIValidationHack="false" tomcatAuthentication="false"
                 protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>

   3. Save the Tomcat configuration file.
5. Restart the SGD Web Server.

   You must restart the SGD Web Server for the configuration changes to take effect.

Configuring SGD for Third-Party Authentication

1. In the SGD Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.

   On the Global Settings » Secure Global Desktop Authentication tab, click the Change Secure Global Desktop Authentication button.

2. On the Third-Party/System Authentication step, select the Third-Party Authentication check box.
3. On the Third-Party Authentication - User Identity and Profile step, select the check box for one or more search methods for finding the user identity.

   For details on how the search methods work, see Third-Party Authentication.

   If the Search LDAP Repository check box is selected, select an option for finding the LDAP user profile.

4. (Optional) On the LDAP Repository Details step, configure the details of the LDAP directory.

   The LDAP Repository Details step only displays if an LDAP search method is selected on the Third-Party Authentication - User Identity and Profile step.

   1. For Repository Type, select the LDAP option. Select this option even if you are using a Microsoft Active Directory server.
   2. In the URLs field, type the URL of one or more LDAP directory servers, for example ldap://melbourne.indigo-insurance.com.
      • After typing each URL, press the Return key.
      • If there is than one URL, SGD uses the URLs in the order they are listed. If the first LDAP directory server in the list is unavailable, the next one is tried.
      • To use secure connections to LDAP directory servers, use an ldaps:// URL and install the root certificates for the LDAP directory servers.
      • The standard port used for connections to LDAP directory servers is port 389. If the LDAP directory server uses a different port, specify the port number as part of the URL, for example ldap://melbourne.indigo-insurance.com:5678.
      • Adding a search root to the end of the URL, for example ldap://melbourne.indigo-insurance.com/dc=indigo-insurance,dc=com restricts the part of the LDAP directory used to search for the user identity.
   3. Type the details of an LDAP user in the User Name and Password fields.
      • The user name must be the distinguished name of the user, for example cn=sgd-user,cn=Users,dc=indigo-insurance,dc=com.
      • Some LDAP directory servers support anonymous logins, so you do not need to supply a user name or password. Others, including Microsoft Active Directory, require the user name and password of a user that has sufficient privileges to search the LDAP directory.
      • As you can only enter one user name and password, this user must be able to search all LDAP directory servers listed in the URL field.
      • You might want to create a special LDAP user reserved for the SGD LDAP authentication.
5. On the Review Selections step, check the authentication configuration and click Finish.

Using Authentication Plug-ins With Web Server Authentication

SGD web server authentication relies on the web server setting the REMOTE_USER environment variable to identify the user. If you use an authentication plug-in for web server authentication, it is likely that the plug-in uses a different environment variable to identify the user. To work round this, you must configure the webtop web application to support your variable.

In addition to the REMOTE_USER variable, SGD includes support for the following variables:

• SSL_CLIENT_S_DN_CN - see Using Client Certificates for details of how to enable support for this variable.
• HTTP_SAFEWORD_USER - see Using SafeWord PremierAccess for details of how to enable support for this variable.

How to Enable Support for Other Environment Variables for Web Server Authentication

Before you begin, consult the documentation for your authentication plug-in and make a note of the environment variable it sets to identify users.

The following procedure assumes that you have already configured your authentication plug-in for web server authentication and verified that it is working.

Repeat the following procedure on each SGD server in the array.

1. Become superuser (root).
2. Configure the Apache component of the SGD Web Server to forward your variable to the Tomcat component.
   1. Edit the Apache configuration file.

      The file is /opt/tarantella/webserver/apache/version/conf/httpd.conf.

   2. Add a JkEnvVar directive to forward your environment variable.

      Search for the existing JKEnvVar directives and add a directive for your own variable, as follows:

      #JkEnvVar SSL_CLIENT_S_DN_CN " "
      #JkEnvVar HTTP_SAFEWORD_USER " "
      JKEnvVar YOUR_VARIABLE " "

   3. Make the variable available in the /SGD location.

      Remove the comment marks (#) from the Location directive as follows:

      <Location "/sgd">
       SSLOptions +StdEnvVars +ExportCertData
      </Location>

   4. Save the Apache configuration file.
3. Configure the webtop web application to use your environment variable.
   1. Change to the SGD web application resources directory.

      The directory is /opt/tarantella/webserver/tomcat/version/webapps/sgd/resources/jsp.

   2. Edit the webtopsession.jsp file and add support for your variable.

      Use the code for the HTTP_SAFEWORD_USER and SSL_CLIENT_S_DN_CN variables as examples of how to do this.

   3. Save the changes.
4. Restart the SGD Web Server.

Using SafeWord PremierAccess With Web Server Authentication

SGD includes support for SafeWord PremierAccess with web server authentication. SafeWord PremierAccess uses the HTTP_SAFEWORD_USER environment variable instead of the REMOTE_USER variable to identify the user.

The following procedure assumes that you have already configured SafeWord PremierAccess for web server authentication and verified that it is working.

Repeat the following procedure on each SGD server in the array.

1. Become superuser (root).
2. Edit the Apache configuration file.

   The file is /opt/tarantella/webserver/apache/version/conf/httpd.conf.

3. Enable the JkEnvVar directive to forward the HTTP_SAFEWORD_USER variable.

   Search for the existing JKEnvVar directives and remove the comment mark (#) for the HTTP_SAFEWORD_USER variable as follows:

   #JkEnvVar SSL_CLIENT_S_DN_CN " "
   JkEnvVar HTTP_SAFEWORD_USER " "

4. Make the HTTP_SAFEWORD_USER variable available in the /SGD location.

   Remove the comment marks (#) from the Location directive as follows:

   <Location "/sgd">
    SSLOptions +StdEnvVars +ExportCertData
   </Location>

5. Save the Apache configuration file.
6. Restart the SGD Web Server.

Using Client Certificates With Web Server Authentication

You can strengthen the security of web server authentication by authenticating users if they have valid Public Key Infrastructure (PKI) certificate installed on the client device.

SGD web server authentication relies on the web server setting the REMOTE_USER variable to identify the user. However, when users are authenticated using client certificates generally another environment variable is used to identify the user. For Apache web servers (including the SGD Web Server) the SSL_CLIENT_S_DN_CN variable is used. The following procedure enables support for the SSL_CLIENT_S_DN_CN variable. If your web server sets a different variable when using client certificates, follow these instructions.

The following procedure assumes that you have already configured the web server so that to access the /sgd URL you need a client certificate and verified it is working. The SGD Web Server includes the Apache mod_ssl module which you can use to set up up PKI client certificates.

Repeat the following procedure on each SGD server in the array.

1. Become superuser (root).
2. Edit the Apache configuration file.

   The file is /opt/tarantella/webserver/apache/version/conf/httpd.conf.

3. Enable the JkEnvVar directive to forward the SSL_CLIENT_S_DN_CN variable.

   Search for the existing JKEnvVar directives and remove the comment mark (#) for the SSL_CLIENT_S_DN_CN variable as follows:

   JkEnvVar SSL_CLIENT_S_DN_CN " "
   #JkEnvVar HTTP_SAFEWORD_USER " "

4. Make the SSL_CLIENT_S_DN_CN variable available in the /SGD location.

   Remove the comment marks (#) from the Location directive as follows:

   <Location "/sgd">
    SSLOptions +StdEnvVars +ExportCertData
   </Location>

5. Save the Apache configuration file.
6. Restart the SGD Web Server.

Copyright © 1997-2007 Sun Microsystems, Inc. All rights reserved.