Linux 版 (精华区)

发信人: netiscpu (网中鸟~~不能上BBS了), 信区: Linux
标  题: 使用Apache作基于用户级的Web浏览
发信站: 哈工大紫丁香 (Thu May 27 14:40:29 1999), 转信

 

   

Using User Authentication 

User authentication lets you restrict documents to only people with valid u

sernames and passwords. This feature explains how to set up and use user au

thentication. First published in Apache Week issue 37 (18th October 1996). 

Using User Authentication

There are two ways of restricting access to documents: either by the hostna

me of the browser being used, or by asking for a username and password. The

 former can be used to, for example, restrict documents to use within a com

pany. However if the people who are allowed to access the documents are wid

ely dispersed, or the server administrator needs to be able to control acce

ss on an individual basis, it is possible to require a username and passwor

d before being allowed access to a document. This is called user authentica

tion. 

Setting up user authentication takes two steps: firstly, you create a file 

containing the usernames and passwords. Secondly, you tell the server what 

resources are to be protected and which users are allowed (after entering a

 valid password) to access them. 

Creating a User Database

A list of users and passwords needs to be created in a file. For security r

easons, this file should not be under the document root. The examples here 

will assume you want to use a file call users in your server root at /usr/l

ocal/etc/httpd. 

The file will consist of a list of usernames and a password for each. The f

ormat is similar to the standard Unix password file, with the username and 

password being separated by a colon. However you cannot just type in the us

ernames and passwords because the passwords are stored in an encrypted form

at. The program htpasswd is used to add create a user file and to add or mo

dify users. 

htpasswd is a C program that is supplied in the support directory of the Ap

ache distribution. If it is not already compiled, you will to compile it fi

rst. Run 

  make htpasswd

in the support directory to compile it (you might need to modify the Makefi

le first, since any configuration you did when compiling the server itself 

is not available to this makefile). After compilation, you can either leave

 the htpasswd binary where it is, or move it to a directory on your path (e

.g. /usr/local/bin). In the former case, you will need to remember to give 

the full pathname to run it. The examples here will assume that it is insta

lled somewhere on your path. Using htpasswd

To create a new user file and add the username "martin" with the password "

hampster" to the file /usr/local/etc/httpd/users: 

   htpasswd -c /usr/local/etc/httpd/users martin

The -c argument tells htpasswd to create new users file. When you run this 

command, you will be prompted to enter a password for martin, and confirm i

t by entering it again. Other users can be added to the existing file in th

e same way, except that the -c argument is not needed. The same command can

 also be used to modify the password of an existing user. After adding a fe

w users, the /usr/local/etc/httpd/users file might look like this: 

martin:WrU808BHQai36

jane:iABCQFQs40E8M

art:FAdHN3W753sSU

The first field is the username, and the second field is the encrypted pass

word. Configuring the Server

To get the server to use the usernames and passwords in this file, you need

 to configure a realm. This is a section of your site that is to be restric

ted to some or all of the users listed in this file. This is typically done

 on a per-directory basis, with a directory (and all its subdirectories) be

ing protected (Apache 1.2 and later also let you protect individual files).

 The directives to create the protected area can be placed in a .htaccess f

ile in the directory concerned, or in a <Directory> section in the access.c

onf file. 

To allow a directory to be restricted within a .htaccess file, you first ne

ed to ensure that the access.conf file allows user authentication to be set

 up in a .htaccess file. This is controlled by the AuthConfig override. The

 access.conf file should include AllowOverride AuthConfig to allow the auth

entication directives to be used in a .htaccess file. 

To restrict a directory to any user listed in the users file just created, 

you should create a .htaccess file containing: 

  AuthName "restricted stuff"

  AuthType Basic

  AuthUserFile /usr/local/etc/httpd/users

  require valid-user

The first directive, AuthName, specifies a realm name for this protection. 

Once a user has entered a valid username and password, any other resources 

within the same realm name can be accessed with the same username and passw

ord. This can be used to create two areas which share the same username and

 password.The AuthType directive tells the server what protocol is to be us

ed for authentication. At the moment, Basic is the only method available. H

owever a new method, Digest, is about to be standardised, and once browsers

 start to implement it, digest authentication will provide more security th

an the basic authentication. 

AuthUserFile tells the server the location of the user file created by htpa

sswd. A similar directive, AuthGroupFile, can be used to tell the server th

e location of a groups file (see below). 

These four directives have between them tell the server where to find the u

sernames and passwords and what authentication protocol to use. The server 

now knows that this resource is restricted to valid users. The final stage 

is to tell the server which usernames from the file are valid for particula

r access methods. This is done with the require directive. In this example,

 the argument valid-user tells the server that any username in the users fi

le can be used. But it could be configured to allow only certain users in: 

  require user martin jane

would only allow users martin and jane access (after they entered a correct

 password). If user art (or any other user) tried to access this directory 

- even with the correct password - they would be denied. This is useful to 

restrict different areas of your server to different people with the same u

sers file. If a user is allowed to access the different areas, they only ha

ve to remember a single password. Note that if the realm name differs in th

e different areas, the user will have to re-enter their password. Using Gro

upsIf you want to allow only selected users from the users file in to a par

ticular area, you can list all the allowed usernames on the require line. H

owever this means you are building username information into your .htaccess

 files, and might not been convenient if there are a lot of users, and . Fo

rtunately there is a way round this, using a group file. This operates in a

 similar way to standard Unix groups: any particular user can be a member o

f any number of groups. You can then use the require line to restrict users

 to one or more particular groups. For example, you could create a group ca

lled staff containing users who are allowed to access internal pages. To re

strict access to just users in the staff group, you would use 

  require group staff

Multiple groups can be listed, and require user can also be given, in which

 case any user in any of the listed groups, or any user listed explicitly, 

can access the resource. For example   require group staff admin 

  require user adminuser

which would allow any user in group staff or group admin, or the user admin

user, to access this resource after entering a valid password. A group file

 consists of lines giving a group name followed by a space-separated list o

f users in that group. For example: 

  staff:martin jane

  admin:art adminuser

The AuthGroupFile directive is used to tell the server the location of the 

group file. Note that the maximum line length within the group file in abou

t 8000 characters (actually 8kB). If you have more users in a group than wi

ll fit within that line length, you can have more than one line with the sa

me group name within the file. Problems with Large Numbers of Users

Using htpasswd to create a text list of users, and maintaining a list of gr

oups in a plain text file is relatively easy. However if the number of user

s becomes large, the server has a lot of processing to do to find a user's 

group and password details. This processing has to be done for every reques

t inside the protected area (even though the user only enters their passwor

d once, the server has to re-authenticate them on every request). This can 

be slow with a lot of users, and adds to the server load. Much faster acces

s is possible using DBM format files. This allows the server to do a very q

uick lookup of names, without having to read through a large text file. How

ever managing DBM files is more complex. Apache Week will cover the use of 

DBM authentication in a future issue. 

Other Ways of Storing User Details

While Apache by default can only access user details in plain text files, v

arious add-on modules are available to allow user details to be stored in d

atabases. Besides DBM format (available with the mod_auth_dbm module), user

 and group lists can be stored in DB format files (with mod_auth_db). Or fu

ll databases can be used, such as mSQL (with mod_auth_msql), Postgres95 (mo

d_auth_pg95) or any DBI-compatible database (mod_auth_dbi). 

It is also possible to have an arbitrary external program check whether the

 given username and password is valid (this could be used to write an inter

face to check against any other database or authentication service). Module

s are also available to check against the system password file, or to use a

 Kerberos system. See the feature on Adding Modules for more information. 

Limiting Methods Differently

In the example .htaccess file above, the require directory is not given ins

ide a <Limit> section. This is valid in Apache, and means it applies to all

 request methods. In other servers and most example .htaccess files, the re

quire directive is given inside a <Limit> section, such as this: 

  <Limit GET POST PUT>

  require valid-user

  </Limit>

In Apache it is better to omit the <Limit> and </Limit> lines, to ensure th

at the protection applies to all methods. However, this format can be used 

to limit particular methods. For example, to limit just the POST method, us

e   AuthName "restrict posting"

  AuthType Basic

  AuthUserFile /usr/local/etc/httpd/users

  <Limit POST>

  require group staff

  <Limit>

Now only members of the group staff will be allowed to POST. Other users (u

nauthenticated) can use other methods, such as GET. This could be used to a

llow a CGI program o be accessed by anyone, but only authorised uses can PO

ST information to it. Restricting By Hostname or Username

It is possible to use both username and hostname restrictions at the same t

ime. Normally Apache will require that both restrictions are satisfied, tha

t is, that the user comes from an allowed host or domain name and that they

 supply a valid username and password. However the Satisfy any directive ca

n be used in the .htaccess file or <Directory>, <Location> or <Files>, sect

ion. When this directive is given, anyone coming from the allowed domains w

ill be given access without having to enter a username and password. All ot

her users (from the "denied" domains) will be prompted for a username and p

assword. 

How WWW Authentication Works

The method used in HTTP for user authetication is quite simple. Since HTTP 

is a stateless protocol - that is, the server does not remember any informa

tion about a request once it has finished - the browser needs to resend the

 username and password on each request. Here is how it works. 

On the first access to an authenticated resource, the server will return a 

401 status ("Unauthorized") and include a WWW-Authenticate response header.

 This will contain the authentication scheme to use (at the moment, only Ba

sic is allowed) and the realm name. The browser should then ask the user to

 enter a username and password. It then requests the same resource again, t

his time including a Authorization header which contains the scheme name ("

Basic") and the username and password entered. 

The server checks the username and password, and if they are valid, returns

 the page. If the password is not valid for that user, or the user is not a

llowed access because they are not listed on a require user line or in a su

itable group, the server returns a 401 status as before. The browser can th

en ask the user to retry their username and password.

Assuming the username and password was valid, the user might next request a

nother resource which is protected. In this case, the server would respond 

with a 401 status, and the browser could send the request again with the us

er and password details. However this would be slow, so instead the browser

 sends the Authorization header on subsequent requests. Note that the brows

er must ensure that it only sends the username and password to further requ

ests on the same server (it would be insecure to send those details if the 

user moved onto a different server).

The browser needs to remember the username and password entered, so it can 

send them with future requests from the same server. Note that this can cau

se problems when testing authentication, since the browser remembers the fi

rst username and password that works. It can be difficult to force the brow

ser to ask for a new username and password. 

Security and Digest Authentication

While authentication does allow resources to be restricted to particular us

ers, there are potential security issues. Some of these are: 

Care must be taken to ensure that the resource is restricted against all me

thods. Use of <Limit GET>, for instance, leaves POST and other request meth

ods unprotected. The username and password are stored in a plain text file.

 While the password is encrypted, it is not completely safe against decrypt

ion, so the file should not be accessible to other users on the system. Mor

e importantly, it should not be placed under the document root where users 

from other sites could access it. The username and password is as secure as

 any username/password system, in that end-users should not tells others th

eir password, or write it down, or make it easily guessable. The Basic auth

entication scheme transmits passwords across the Internet unencrypted, so t

hey could be intercepted. The Digest method, see below, is intended to addr

ess this issue. The Digest Authentication scheme will make the sending of p

asswords across the Internet more secure. It effectively encrypts the passw

ord before it is sent such that the server can decrypt it. It works exactly

 the same as Basic authentication as far as the end-user and server adminis

trator is concerned. The use of Digest authentication will depend on whethe

r browser authors write it into their products. Apache can already do Diges

t authentication, when compiled with the mod_digest module (supplied with t

he Apache distribution). More Information

For more information about how user authentication works on the Internet, s

ee the HTTP/1.0 and HTTP/1.1 documents, available from the Apache Week link

s page. Also available there is a link to the draft Digest Authentication s

pecification. 

For basic information about setting up user authentication, see the NCSA Tu

torial (most of which also applies to Apache).

For modules which allow usernames, groups and passwords to be stored in dat

abase format files, or databases themselves, see this Apache Week feature o

n Adding Modules. 

 


--
☆ 来源:．哈工大紫丁香 bbs.hit.edu.cn．[FROM: bin@mtlab.hit.edu.cn]