Example of using AuthType Digest to authenticate a user once across sub-domains?

Question

Hi there.

I have a domain that will be accessed by a small, private group of people. So I want to control access via authentication.

The domain has a collection of applications installed that each have their own sub-domain. Eg: domain.com, app1.domain.com, app2.domain.com, app3.domain.com

I'd love to have a single sign-on solution so they don't have to authenticate themselves for each application. Also, the applications are written in different languages (PHP, Python and Perl) so authenticating users through an Apache module is ideal.

I am new to digest authentication, but it seems like a good solution. I have used htdigest to create my users. I have configured my domain and sub-domains (See below).

If I go to the domain or any of the sub-domains it will prompt for a username and password. If I enter a correct username and password, it will authenticate me and the page will load. However, if I go to another sub-domain, it will ask for me to enter a username and password again. If I enter the same username and password, it will work.

So the password file is OK, and authentication is OK, but the problem seems to lie in the configuration of the AuthDigestDomain.

I have searched all over the net to find an example of using Digest authentication on multiple domains, but I cannot find a specific example that solves my problem.

I am hoping someone here can assist. Do I put the same authentication information in every Directory? Should I be using Directory or Location or Files? Have I missed something all-together?

Thanks in advance!

Below is an example of my Apache config for domain.com:

<Directory /var/www>
  AuthType Digest
  AuthName "realm"
  AuthDigestAlgorithm MD5
  AuthDigestDomain / http://domain.com/ http://app1.domain.com/ http://app2.domain.com/ http://app3.domain.com/
  AuthDigestNcCheck Off
  AuthDigestNonceLifetime 0
  AuthDigestQop auth
  AuthDigestProvider file
  AuthUserFile /etc/apache2/.htpasswd-digest
  AuthGroupFile /dev/null
  Require valid-user
</Directory>

And here is an example of app1.domain.com:

<Directory /var/lib/app1>
  AuthType Digest
  AuthName "realm"
  AuthDigestAlgorithm MD5
  AuthDigestDomain / http://domain.com/ http://app1.domain.com/ http://app2.domain.com/ http://app3.domain.com/
  AuthDigestNcCheck Off
  AuthDigestNonceLifetime 0
  AuthDigestQop auth
  AuthDigestProvider file
  AuthUserFile /etc/apache2/.htpasswd-digest
  AuthGroupFile /dev/null
  Require valid-user
</Directory>

To baffle things even further, this works when using IE6, but not Firefox or Chrome. Is it the clients not sending the authentication properly, or is is the server not sending the correct credentials?

I have also been reading up on RFC 2617 and written the authentication headers using PHP to ensure that the request/response challenge is correct. This hasn't helped at all!

Answer 1

I have no experience with something like this myself. But I just took a look at the Apache documentation and found this:

The AuthDigestNonceLifetime directive controls how long the server nonce is valid. [...] If seconds is less than 0 then the nonce never expires.

So it seems to me that 0 seconds (the value you are using) is either illegal or really tells Apache to expire the nonce after 0 seconds which would exactly explain the behavior you are geting.

Answer 2

Could a wildcard on the AuthDigestDomain help?

    *.domain.com

Answer 3

Most browsers do not respect the Digest "domain" directive and will not resend credentials for other URIs. As far as I know, Opera is the only browser that honors it.

For Opera, the server(s) must respond with the same "realm" string for each URI in the domain list. In other words, if domain="/test /example", the server needs to send "Test Realm - example.com" in the WWW-Authenticate header for both of those URIs. I assume Opera does this because it stores H(A1) instead of the actual password for security. Read into RFC2617 for more on this.

Here's my cross-browser solution to this problem: http://travisce.com/arest/