Authentication, Authorization and Access Control

Available Languages: en | + es | + ja | + ko

+ +

Authentication is any process by which you verify that + someone is who they claim they are. Authorization is any + process by which someone is allowed to be where they want to + go, or to have information that they want to have.

Related Modules and Directives
Introduction
The Prerequisites
Getting it working
Letting more than one +person in
Possible problems
What other neat stuff can I +do?
More information

Related Modules and Directives

+ +

Related Modules	Related Directives
`mod_auth` `mod_access`	`Allow` `AuthGroupFile` `AuthName` `AuthType` `AuthUserFile` `Deny` `Options` `Require`

Introduction

If you have information on your web site that is sensitive + or intended for only a small group of people, the techniques in + this article will help you make sure that the people that see + those pages are the people that you wanted to see them.

+ +

This article covers the "standard" way of protecting parts + of your web site that most of you are going to use.

The Prerequisites

The directives discussed in this article will need to go + either in your main server configuration file (typically in a + <Directory> section), or + in per-directory configuration files (.htaccess files).

+ +

If you plan to use .htaccess files, you will + need to have a server configuration that permits putting + authentication directives in these files. This is done with the + AllowOverride directive, which + specifies which directives, if any, may be put in per-directory + configuration files.

+ +

Since we're talking here about authentication, you will need + an AllowOverride directive like the + following:

+ +

+ AllowOverride AuthConfig +

+ +

Or, if you are just going to put the directives directly in + your main server configuration file, you will of course need to + have write permission to that file.

+ +

And you'll need to know a little bit about the directory + structure of your server, in order to know where some files are + kept. This should not be terribly difficult, and I'll try to + make this clear when we come to that point.

Getting it working

Here's the basics of password protecting a directory on your + server.

+ +

You'll need to create a password file. This file should be + placed somewhere not accessible from the web. This is so that + folks cannot download the password file. For example, if your + documents are served out of /usr/local/apache/htdocs you + might want to put the password file(s) in + /usr/local/apache/passwd.

+ +

To create the file, use the htpasswd utility that + came with Apache. This will be located in the bin directory + of wherever you installed Apache. To create the file, type:

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords rbowen +

+ +

htpasswd will ask you for the password, and + then ask you to type it again to confirm it:

+ +

+ # htpasswd -c /usr/local/apache/passwd/passwords rbowen + New password: mypassword + Re-type new password: mypassword + Adding password for user rbowen +

+ +

If htpasswd is not in your path, of course + you'll have to type the full path to the file to get it to run. + On my server, it's located at + /usr/local/apache/bin/htpasswd

+ +

Next, you'll need to configure the server to request a + password and tell the server which users are allowed access. + You can do this either by editing the httpd.conf + file or using an .htaccess file. For example, if + you wish to protect the directory + /usr/local/apache/htdocs/secret, you can use the + following directives, either placed in the file + /usr/local/apache/htdocs/secret/.htaccess, or + placed in httpd.conf inside a <Directory + /usr/local/apache/apache/htdocs/secret> section.

+ +

+ AuthType Basic + AuthName "Restricted Files" + AuthUserFile /usr/local/apache/passwd/passwords + Require user rbowen +

+ +

Let's examine each of those directives individually. The AuthType directive selects + that method that is used to authenticate the user. The most + common method is Basic, and this is the method + implemented by mod_auth. It is important to be aware, + however, that Basic authentication sends the password from the client to + the browser unencrypted. This method should therefore not be used for + highly sensitive data. Apache supports one other authentication method: + AuthType Digest. This method is implemented by mod_auth_digest and is much more secure. Only the most recent + versions of clients are known to support Digest authentication.

+ +

The AuthName directive sets + the Realm to be used in the authentication. The realm serves + two major functions. First, the client often presents this information to + the user as part of the password dialog box. Second, it is used by the + client to determine what password to send for a given authenticated + area.

+ +

So, for example, once a client has authenticated in the + "Restricted Files" area, it will automatically + retry the same password for any area on the same server that is + marked with the "Restricted Files" Realm. + Therefore, you can prevent a user from being prompted more than + once for a password by letting multiple restricted areas share + the same realm. Of course, for security reasons, the client + will always need to ask again for the password whenever the + hostname of the server changes.

+ +

The AuthUserFile + directive sets the path to the password file that we just + created with htpasswd. If you have a large number + of users, it can be quite slow to search through a plain text + file to authenticate the user on each request. Apache also has + the ability to store user information in fast database files. + The mod_auth_dbm module provides the AuthDBMUserFile directive. These + files can be created and manipulated with the dbmmanage program. Many + other types of authentication options are available from third + party modules in the Apache Modules + Database.

+ +

Finally, the Require + directive provides the authorization part of the process by + setting the user that is allowed to access this region of the + server. In the next section, we discuss various ways to use the + Require directive.

Letting more than one +person in

The directives above only let one person (specifically + someone with a username of rbowen) into the + directory. In most cases, you'll want to let more than one + person in. This is where the AuthGroupFile comes in.

+ +

If you want to let more than one person in, you'll need to + create a group file that associates group names with a list of + users in that group. The format of this file is pretty simple, + and you can create it with your favorite editor. The contents + of the file will look like this:

+ +

+ GroupName: rbowen dpitts sungo rshersey +

+ +

That's just a list of the members of the group in a long + line separated by spaces.

+ +

To add a user to your already existing password file, + type:

+ +

+ htpasswd /usr/local/apache/passwd/passwords dpitts +

+ +

You'll get the same response as before, but it will be + appended to the existing file, rather than creating a new file. + (It's the -c that makes it create a new password + file).

+ +

Now, you need to modify your .htaccess file to + look like the following:

+ +

+ AuthType Basic + AuthName "By Invitation Only" + AuthUserFile /usr/local/apache/passwd/passwords + AuthGroupFile /usr/local/apache/passwd/groups + Require group GroupName +

+ +

Now, anyone that is listed in the group GroupName, + and has an entry in the password file, will be let in, if + they type the correct password.

+ +

There's another way to let multiple users in that is less + specific. Rather than creating a group file, you can just use + the following directive:

+ +

+ Require valid-user +

+ +

Using that rather than the Require user rbowen + line will allow anyone in that is listed in the password file, + and who correctly enters their password. You can even emulate + the group behavior here, by just keeping a separate password + file for each group. The advantage of this approach is that + Apache only has to check one file, rather than two. The + disadvantage is that you have to maintain a bunch of password + files, and remember to reference the right one in the + AuthUserFile directive.

Possible problems

Because of the way that Basic authentication is specified, + your username and password must be verified every time you + request a document from the server. This is even if you're + reloading the same page, and for every image on the page (if + they come from a protected directory). As you can imagine, this + slows things down a little. The amount that it slows things + down is proportional to the size of the password file, because + it has to open up that file, and go down the list of users + until it gets to your name. And it has to do this every time a + page is loaded.

+ +

A consequence of this is that there's a practical limit to + how many users you can put in one password file. This limit + will vary depending on the performance of your particular + server machine, but you can expect to see slowdowns once you + get above a few hundred entries, and may wish to consider a + different authentication method at that time.

What other neat stuff can I +do?

Authentication by username and password is only part of the + story. Frequently you want to let people in based on something + other than who they are. Something such as where they are + coming from.

+ +

The Allow and + Deny directives let + you allow and deny access based on the host name, or host + address, of the machine requesting a document. The + Order directive goes + hand-in-hand with these two, and tells Apache in which order to + apply the filters.

+ +

The usage of these directives is:

+ +

+ Allow from address +

+ +

where address is an IP address (or a partial IP + address) or a fully qualified domain name (or a partial domain + name); you may provide multiple addresses or domain names, if + desired.

+ +

For example, if you have someone spamming your message + board, and you want to keep them out, you could do the + following:

+ +

+ Deny from 10.252.46.165 +

+ +

Visitors coming from that address will not be able to see + the content covered by this directive. If, instead, you have a + machine name, rather than an IP address, you can use that.

+ +

+ Deny from host.example.com +

+ +

And, if you'd like to block access from an entire domain, + you can specify just part of an address or domain name:

+ +

+ Deny from 192.168.205 + Deny from phishers.example.com moreidiots.example + Deny from ke +

+ +

Using Order will let you be + sure that you are actually restricting things to the group that you want + to let in, by combining a Deny + and an Allow directive:

+ +

+ Order deny,allow + Deny from all + Allow from dev.example.com +

+ +

Listing just the Allow + directive would not do what you want, because it will let folks from that + host in, in addition to letting everyone in. What you want is to let + only those folks in.

More information

You should also read the documentation for mod_auth + and mod_access which contain some more information + about how this all works.