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

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!

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/

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.

Could a wildcard on the AuthDigestDomain help?
*.domain.com

Related

.htaccess AuthUserFile has no effect or is being ignored

After hours of searching the web and trying dozens of unsuccessful solutions - here is my question.
I'm currently configuring a webserver on RHEL 6.4 and httpd 2.2.15 behind another RHEL 6.4 server using squid 3.1.10 and HTTPS only. I'm also using mod_rpaf to simplify logging and identification of visitors behind the proxy.
My problem is to configure a simple password protected folder. When I try to access the folder, the password dialog pops up with the configured AuthName. So I know that the .htaccess is being parsed. But the dialog does not accept the correct credentials and gives me an error 401.
I messed around with:
different permissions for .htaccess, .htpasswd and parent folders
different absolute locations for the .htpasswd
all activated Apache modules that are available on my system
different encryption algorithms for .htpasswd (crypt, md5, sha, salted sha...)
AllowOverride All on the protected and parent folder
But what I really do not understand that even if I put a wrong location for AuthUserFile there is no error message in Apaches error_log like the well known Permission denied: Could not open password file. Even on LogLevel debug Therefore I think that something is wrong with that Directive AuthUserFile.
I hope there is someone out there knowing better methods to identify the problem.
This is my simple .htaccess I'm using for testing:
AuthType Basic
AuthName "Test123"
#AuthUserFile /var/www/test/.htpasswd
AuthUserFile /notexisting
Require valid-user
Finally I got it to work!
I tracked the error down to the squid reverse proxy by using lynx on my webserver and successfully accessing the protected folder from there.
With my new focus on squid I started googling again. Already the first link took me to the correct answer: squid did not allow the apache to handle user authentication.
Resulution:
Add login=PASS to the cache_peer command in your squid.conf

http digest authentication with .htpasswd

I am working on windows and for now I have Http Basic authentication with following .htaccess file:
AuthName "Restricted Area"
AuthType Basic
AuthUserFile D:\\some\\windows\\path/.htpasswd
require valid-user
and following .htpasswd file for user "test" with password "test" (created using http://www.htaccesstools.com/htpasswd-generator-windows/):
test:$apr1$EUhLJ8Ye$LpBIbzDcBXY.80pH53oN2/
This works, I am able to enter correct username and password and I gain access.
But as I am not using SSL I would like to use Digest authentication (to avoid sending password in plain text to server). I changed line AuthType Basic to AuthType Digest but it is not working anymore - even if I am typing correct user and pass I cant gain access.
Probably I should encrypt/hash password in .htpasswd using different algorithm but I cant find it...
If you want to use digest authentication, you'll have to create new password files. Those for digest auth will have a slightly different format that that used for basic auth. Typically, apache comes with tools for doing this.
Look out for the command line programs "htpasswd.exe" and "htdigest.exe". You need to use the second one for generating password files for digest auth. Use it like this:
c:\path\to\htdigest.exe -c c:\some\windows\path.htpasswd_digest realm username
You'll only need "-c" the first time you issue the command, if you only add new users to an existing file, it's like:
c:\path\to\htdigest.exe c:\some\windows\path.htpasswd_digest realm another_username
"realm" should be the same value you used in your apache config for AuthName.
Oh, and obviously, don't forget to update AuthUserFile in your apache configuration...

Apache asks the password for each subdomain with htpasswd

Apache asks the password for each subdomain with htpasswd.
I want that he would ask the password at the first input and remembered me for all subdomains
I use the following code:
AuthType Basic
AuthName "Projects"
AuthUserFile /blablabla/baz.htpasswd
Require valid-user
Actually Apache httpd asks for your user credentials on every request on every subdomain. It's your web browser, which caches your credentials (per hostname) and sends them on every subsequent request on the same hostname.
You can't really circumvent that behaviour without full control over your clients' software if you want to keep the different subdomains.

How can I configure Apache and LDAP to allow a second authentication attempt?

I just got Apache/LDAP authentication working (almost) on a new SLES 10 server.
When I visit one of the protected areas on my website I get the Apache Authentication pop-up window where I can LDAP authenticate to gain access to the protected folder.
But I'm getting wierd behaviour.
If I type in a valid user but the incorrect password, it lets me retry authentication.
If I type in a non-valid user (like 'aldfklsf' or even leave the username field blank) then I get an error 500 page and do not get the opportunity to retry authentication.
I have cache disabled... Try to refresh the page to get the Apache authentication window to come back and it doesn't. I just keep getting the error 500 page. Looking in the Apache error logs it says: user aldfklsf not found, every time I refresh the page. It's like it's hanging on to that username.
Is there some setting in Apache that will allow me to attempt to authenticate again?
Here's the entirety of the conf file that is protecting the directory:
<Directory "/media/nss/VOL1/ProtectedDir">
Options Indexes Multiviews
AllowOverride None
Order deny,allow
Allow from all
AuthType Basic
AuthName "Protected"
Require valid-user
AuthBasicAuthoritative Off
AuthzLDAPAuthoritative Off
AuthBasicProvider ldap
AuthLDAPURL ldap://10.20.32.3/o=wlwv?uid?sub
</Directory>
An update. I found this in the Apache documentation:
Under normal circumstances, the Apache
access control modules will pass
unrecognized user IDs on to the next
access control module in line. Only if
the user ID is recognized and the
password is validated (or not) will it
give the usual success or
"authentication failed" messages.
This seems to be the answer. Unfortunately I do not understand Apache enough to take the information from that page and implement it so that it works correctly.
Can anyone help?
Ok, got it figured out. Here is the simple solution in case anyone else has this issue.
Changing:
AuthBasicAuthoritative Off
to
AuthBasicAuthoritative On
was all it took.

How to secure an admin area for a public and private rails app

How would you secure access to the admin area for a web app?
Our Rails CMS serves pages publicly. I would like to make the backend (/admin) inaccessible using either the webserver(apache) or firewall(netfilter).
Could this be done using an SSL certificate? I would like to limit access to the backend to only those whose have the "key", similar to SSH access to a server.
Thanks in advance.
You're absolutely right that an SSL cert is the way to go. And it's not really all that tricky to set up, though it's rarely done.
It's important to remember that this problem has two components. The first is, "how do I get the darn thing working at all," and, this being a security system, the second is, "how do I set it up so that I'm not likely to accidently do something that borks my security?"
The first thing I would suggest is to write a separate Rails application for the admin stuff, and run it with a different web server on a different port. (If you really want to avoid putting a port number in the URL for the admin site, use a proxy in front of both web servers that uses the Host: header to redirect requests to for foo.com to one server, and admin.foo.com to the other.) This separation will help ensure that you don't accidently give regular users access to admin functionality, and make the SSL setup easier.
For the admin server, set it up for SSL access only. Create a new signing cert, and allow only certificates signed by the signing cert to connect. (This is web-server dependent; if you really need details on how to do this, you probably want to post a new question giving the specifics of the server and configuration you're using.) You can set up a page (on the non-SSL site, or on a page accessable to non-authenticated users on the SSL site) that will have your admins' web browsers automatically generate and upload a certificate that you can sign which will give them access.
Keep copies of all the certs you sign so that when you need to revoke access, you can put that cert in the revocation list.
DON'T use the firewall, you'll just complicate your implementation. The "correct" approach is to use .htaccess or set up authorisation in Apache Directory configuration.
It sounds like you want SSLRequire
SSLVerifyClient none
<Directory /usr/local/apache/htdocs/secure/area>
SSLVerifyClient require
SSLVerifyDepth 5
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
SSLOptions +FakeBasicAuth
SSLRequireSSL
AuthName "Snake Oil Authentication"
AuthType Basic
AuthUserFile /usr/local/apache/conf/httpd.passwd
require valid-user
</Directory>
Howto: http://eregie.premier-ministre.gouv.fr/manual/mod/mod_ssl/ssl_howto.html