SGD and HTTP Basic Authentication

Introduction

On this page we'll look at how to use HTTP Basic authentication with SGD.

Protecting the URL

 To use the Apache server's support for HTTP Basic authentication all we need to do is:

  1. Edit the Apache conf file
    This is normally found at: /opt/tarantella/webserver/apache/1.3.36_mod_ssl-2.8.27_openssl-0.9.8d_jk1.2.15_u1/conf/httpd.conf
    setEnvIf Request_URI "\.(class|cab|jar|gif|der)$|(out.jsp$)" sgd_noauth_ok
    
    <LocationMatch /sgd>
       Order Allow,Deny
       Allow from env=sgd_noauth_ok
       AuthUserFile /opt/tarantella/webserver/apache/1.3.36_mod_ssl-2.8.27_openssl-0.9.8d_jk1.2.15_u1/conf/users.conf
       AuthName "Sun Secure Global Desktop"
       Authtype Basic
       Require  valid-user
       Satisfy  any
    </LocationMatch>
    
  2. Create some Apache users 
    /opt/tarantella/webserver/apache/*/bin/htpasswd -c /opt/tarantella/webserver/apache/1.3.36_mod_ssl-2.8.27_openssl-0.9.8d_jk1.2.15_u1/conf/users.conf "Andy Hall"
    
  3. Restart the web server
    /opt/tarantella/bin/tarantella webserver restart
    

The User experience is now:

Visit the /sgd URL
And when we enter valid credentials we get past the web server but now stop at the SGD login box.

We don't really want our users to have to go thru 2 login processes so let's fix this....

Consolidating SGD and Web Server authentication

So far all we've done is protect a URL. Now we'll configure SGD to trust third-parties such that the user doesn't see the SGD System Authentication box.

  1. To do this we can use the SGD Administration Console ("http://servername/sgdadmin") as follows:
    Step Picture
    Start the "Change SGD Authentication..." wizard:
    Skip the background info
    Enable Third Party Authentication...
    We'll cover this later, but this is about which apps the user gets...
    Leave this as it...
    Leave this too...
    And finally, click Finish.
  2. What we have done so far is to tell SGD to trust third parties if they present legitimate trusted user credentials.
    The /sgd web application has been written such that if it detects the presence of a $REMOTE_USER in the environment, it attempts to use third-party authentication, rather than present the System Authentication dialog box.
    So now we need to edit the Tomcat configuration file which is usually at: /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/conf/server.xml
    Look for the section below and add the line tomcatAuthentication="false".
        <!-- 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. Now let's restart the web server:
    /opt/tarantella/bin/tarantella webserver restart
    

And the user experience is now....

Visit the SGD URL and get prompted by Apache
With valid Apache credentials you get thru to your webtop
Warning

Be careful when logging out from SGD and using Web authentication.
The Logout button will terminate that SGD session but if the browser stays around then that HTTP session is still valid and returning to the /sgd URL will take you back to your webtop without further authentication.

Which applications does a Web user get?

Let's revisit how SGD decides which applications the user gets. In the SGD admin console pages above, we specified that all web users should be treated the same and as described by the Third-Party Identity Profile in SGD.
An alternative approach is to search an LDAP directory to find more info about the web user.
Here's how to do that:

Step Picture
Start the "Change SGD Authentication..." wizard again
Skip the background info
Leave this as before
Here choose to search an LDAP repository for user's details
Leave this as it...
Leave this too...
Now tell SGD where you LDAP directory is
And finally, click Finish.

Now when a user logs in, SGD searches the LDAP directory to identify the user and from this knowledge SGD may populate the users webtop with applications published using the Directory Services Integration feature of SGD.

Troubleshooting

When attempting to use Web authentication it is always useful to see who the web server or the web application thinks is logged in. Here's a couple of ways of discovering that:

Apache access log

The Apache webserver log file is held in /opt/tarantella/webserver/apache/*/logs/access_log.
A good idea is to tail -f this file to get output like:

129.156.4.240 - - [21/Feb/2008:11:05:56 +0000] "GET /sgd/index.jsp?langSelected=en HTTP/1.1" 401 482
129.156.4.240 - Andy Hall [21/Feb/2008:11:06:17 +0000] "GET /sgd/index.jsp?langSelected=en HTTP/1.1" 401 482

Each line shows an HTTP request with the 3rd field indicating the authenticated user name.
The first line shows that the sgd index page was initially requested with no authentication and so a dialog box is thrown up. The second shows the request after "Andy Hall" had been autenticated.

Showing the Web Application Environment

environment.jsp is a useful debugging tool which you should put in the sgd web app directory. /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd. In a browser you can then visit "http://servername/sgd/environment.jsp" to see the full environment that the SGD webtop is operating in.
One of those fields is REMOTE_USER which is the authenticated user name.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Sun Microsystems community and they might not be employed or in any way formally affiliated with Sun Microsystems. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Sun nor any other party necessarily agrees with them.

Copyright 1994-2009 Sun Microsystems, Inc.
Powered by Atlassian Confluence
Sun Guidelines on Public Discourse Privacy Policy Terms of Use Trademarks Site Map Employment Investor Relations Contact