[Top] [Prev] [Next] [Last] Download PDF:   US   UK Download Postscript:   US   UK

Chapter 3

Tutorial: Access Control

One of the purposes of any secure Web server is to control access to private materials. Access control requires two components:

• a configuration that defines who is allowed to access a given object and who is forbidden to access it
  
  
• a means of authenticating users or hosts to determine whether they fall within the set of allowed entities
  
  

There are various ways of identifying users and controlling which objects they can access. This tutorial leads you through three different scenarios designed to demonstrate three popular methods of authentication and access control:

• host-based access control
  
  
• access control with basic authentication
  
  
• access control with SSL/TLS-compliant client certificates
  
  

If you are inexperienced in using access control, use this chapter as a detailed introduction. Once you have worked through all three scenarios step by step, you can implement access control on your own site quickly and easily. If you are somewhat familiar with access control and its Apache implementations, you may find it useful to skim this chapter as an overview.

---

Host-Based Access Control

Host-based access control restricts access based on the network identity of the host that originates the client request. A host's network identity can take the form of a fully-qualified domain name (or hostname) or an IP number.

Since these are the only criteria, this method alone cannot control which users access your data. For example, if only one host is allowed to access a certain document, this does not mean that only one user is allowed. If many users have access to the allowed host, all of them can access the document.

This method also has the disadvantage of leaving your files open to hackers who can "spoof," or impersonate, an allowed host. For example, a hacker on a disallowed host can send client requests that appear to originate from an allowed host, then collect restricted files from your server. Although host-based access control is the easiest method of controlling access, you should use it only in low-security situations such as the one described here, or in combination with the Satisfy directive. When you have more than one authentication method configured for an object, Satisfy can be set to "any" to indicate that any single method can qualify a user for access, or "all" to require that users satisfy all authentication methods in order to gain access. For example, you could configure host-based access as described here, configure basic authentication as described in the next section, then add "Satisfy all" to require that users satisfy the requirements of both methods.

Imagine that you belong to a widget distribution company, and that your Stronghold server serves two purposes:

• to publish marketing information to the World Wide Web
  
  
• to provide shipping and routing data to employees
  
  

Your marketing information is automatically available to anyone on the Web-without any special configuration-as long as it resides within the DocumentRoot directory. To provide the shipping and routing data to employees without revealing it to the entire Web, you need to establish a special realm for the tracking data that

• allows any employee to access the tracking data and
  
  
• prevents external users from reaching it.
  
  

Widget shipping and routing information is relatively low-security data, and the employees work from a discrete set of computers on the company's LAN. In this case, host-based access control provides a quick, reliable, maintenance-free method of restricting the information.

---

To set up host-based access control

1. Create a new subdirectory within the DocumentRoot directory.
   
   

   The new directory corresponds to the special URL that only employees should be allowed to access. Usually, the DocumentRoot directory is ServerRoot/htdocs. For the purposes of this scenario, create a staff subdirectory:

   # cd ServerRoot/htdocs
   # mkdir staff
   
   

   NOTE:

   Alternatively, you could create a special virtual host, such as staff.host.com. However, virtual host support varies from platform to platform, and establishing a new host is beyond the scope of this tutorial.

   
   
2. Open the server configuration file in your favorite text editor:
   
   

   # vi ServerRoot/conf/httpd.conf
   
   

   You must establish the access control configuration before you can safely move restricted files into the staff directory.

3. Move to the end of the file.
   
   
4. Insert a new directory container, leaving space for configuration directives:
   
   

   <Directory ServerRoot/htdocs/staff>
   . . .
   </Directory>
   
   

   The configuration that affects only this directory and its subdirectories must go between these opening and closing container tags.

5. Insert the order directive between the container tags, like this:
   
   

   order deny,allow
   
   

   This directive establishes the order in which Stronghold evaluates the other two access control directives: deny and allow. It can also take the value "mutual-failure," which means that access is limited to hosts that appear in the allow list and not in the deny list.

6. Insert the deny directive, like this:
   
   

   deny from all
   
   

   This directive instructs Stronghold to deny access to all hosts. Since the order directive causes Stronghold to read this directive first, access denial is the default result of client requests for this directory.

7. Insert the allow directive, like this:
   
   

   allow from yourhost.com
   
   

   This instructs Stronghold to fulfill requests from any host within the yourhost.com domain, such as host1.yourhost.com and host2.yourhost.com. You could do the same using the first part of an IP address to denote a network range:

   allow from 204.17
   
   

   NOTE:

   Domain name-to-IP number mapping is not straightforward, so be sure you know how your address space is mapped before you use a partial IP address with allow or deny.

   
   
8. Save the modified configuration file.
   
   
9. Restart Stronghold:
   
   

   # ServerRoot/bin/reload-server
   
   

   Stronghold re-reads the configuration file when it restarts.

10. Test the new configuration:
    
    
    • Access http://www.yourhost.com/staff from an internal host.
      
      
    • Try to access the same URL from an external host, either by asking an external user to do so or by telnetting to an external host and using a text-based browser to test the URL.
      
      

    Stronghold should return an empty directory index (if indexing is enabled) when you send the request from an internal host, and an error message with status code 403 when you send the request from an external host. If not,

    • make sure the URL uses the correct directory name,
      
      
    • check httpd.conf to make sure that deny is set to "all," and
      
      
    • make sure that allow is set to your base domain name preceded by a wildcard.
      
      

If the test succeeds, you have successfully established host-based access control. It is now safe to move restricted files into the ServerRoot/htdocs/staff directory. You can also create as many subdirectories as you like; the staff directory configuration also protects all of its subdirectories, unless they are separately configured.

Now imagine that several managers routinely telecommute, and that they want to be able to view the company's shipping and routing data from their homes. In order to add their home domains to the host-based access control configuration, they must each have a static IP number. (Some Internet Service Providers (ISPs) offer only dynamic IP numbers; these do not work with host-based access control.) If they do, you can easily add them to your configuration.

---

To add hosts to the configuration

1. Make a list of the home hostnames or IP numbers of the telecommuters:
   
   

   207.33.129.36
   jabberwock.wonderland.com
   
   

2. Open the server configuration file using a text editor:
   
   

   # vi ServerRoot/conf/httpd.conf
   
   

3. Locate the <Directory ServerRoot/htdocs/staff> container.
   
   
4. Append the list of hostnames and IP numbers to the value for the allow directive, separating them with spaces:
   
   

   allow from *.yourhost.com 207.33.129.36 jabberwock.wonderland.com
   
   

5. Append the same list to the allow directive in the identical directory configuration within the <VirtualHost *:443> container.
   
   

   You pasted the identical directory configuration into the virtual host container in the previous procedure.

6. Save the modified configuration file.
   
   
7. Restart Stronghold:
   
   

   # ServerRoot/bin/reload-server
   
   

   Stronghold re-reads the configuration file when it restarts.

8. Enter your pass phrase.
   
   

Now your configuration grants access only to users on the LAN and users on the home terminals of the telecommuters. Keep in mind that this does not limit the actual users who can access http://www.yourhost.com/staff. For example, family members of telecommuters can also view the information, assuming they have access to the home terminals.

---

Access Control with Basic Authentication

Basic authentication refers to authentication using simple usernames and passwords. The usernames and crypt()-encrypted passwords are stored in a special file similar to your system's /etc/passwd file. When you have established this file, you can use it to control access so that only users with valid usernames and passwords can access an object. You can also create separate authentication realms, each with its own password file, to separate restricted information and the groups of users who can access it.

Basic authentication's weakness lies in its use with the HTTP protocol. When a user sends an HTTP request for a restricted file, then enters a username and password for basic authentication, that information traverses the network in the clear, that is, unencrypted. An eavesdropper monitoring your network can obtain the username and password, then use them to access your restricted data. This section shows you how to use basic authentication and access control with HTTPS, which hides the username and password using SSL/TLS encryption.

Imagine that your widget company decides to make its confidential client information available to managers through your Stronghold server, using a subdirectory within the staff directory you created in "Host-Based Access Control" on page 3-2. The new subdirectory is already protected by your host-based access control configuration, but now you need to make sure that the confidential client information is accessible to managers and protected from everyone else-including family members and other employees. In this case, authenticating the host alone is not enough. You also need to authenticate the user.

---

To set up access control with basic authentication

1. Create the new directory for the confidential client information:
   
   

   # mkdir ServerRoot/htdocs/staff/clients
   
   

   This new directory inherits the host-based access controls you configured in "Host-Based Access Control" on page 3-2.

2. Create a new directory for password files:
   
   

   # mkdir ServerRoot/pw
   
   

3. Use the ServerRoot/bin/htpasswd utility to create a new password file and add yourself, the administrator, as its first user:
   
   

   # htpasswd -c ServerRoot/pw/passwd1 admin
   
   

   The program prompts you for your new password.

4. Enter a new password.
   
   
5. Re-enter your password for confirmation.
   
   
6. Open the server configuration file in your favorite text editor:
   
   

   # vi ServerRoot/conf/httpd.conf
   
   

7. Move to the end of the file.
   
   
8. Insert a new directory container:
   
   

   <Directory ServerRoot/htdocs/staff/clients>
   . . .
   </Directory>
   
   

9. Insert the following directives inside the directory container:
   
   

   RequireSSL on
   AuthType Basic
   AuthName "Client Information"
   AuthUserFile pw/passwd1
   Require valid-user
   
   

   These directives set

   • the SSL/TLS requirement, which blocks HTTP access and permits HTTPS access
     
     

     This prevents users from sending their usernames and passwords unencrypted.

   • the type of authentication-in this case, basic authentication
     
     
   • the name of the authentication realm, so that users with access to more than one realm know which username and password they must enter
     
     
   • the name of the password file for this authentication realm
     
     
   • the access control requirement, which is that the user must be a valid user from the password file
     
     
10. Save the configuration file.
    
    
11. Restart Stronghold:
    
    

    # ServerRoot/bin/reload-server
    
    

    Stronghold re-reads the configuration file when it restarts.

12. Test the new configuration:
    
    
    • Access https://www.yourhost.com/staff/clients. Your browser should present a dialog box where you can enter your username and password. After you enter these, Stronghold should return an empty directory index.
      
      
    • To make sure passwords cannot be transmitted in the clear, try accessing the same URL with HTTP instead of HTTPS. Stronghold should return a status code of 403 (Forbidden).
      
      
13. Add more users to the password file using the htpasswd utility:
    
    

    # htpasswd ServerRoot/pw/passwd1 user1
    
    

    The htpasswd utility always takes a filename or path and a username as its arguments. It also prompts you twice for the password. Once you have created a password file, do not use the -c flag with the same path again or you will overwrite the file.

You have successfully established basic authentication and access control. Under the configuration described here, all users must access the new directory using HTTPS instead of HTTP. Any link to the clients directory must also specify the HTTPS protocol in order to work.

---

Access Control with SSL/TLS Certificates

The most reliable means of authentication is X.509 client certificates, which comply with the SSL/TLS protocol. By providing a nearly foolproof means of identifying users, client certificates also facilitate airtight access control. When Stronghold verifies a certificate's signature, this also verifies that the other information in the certificate is correct. Each client certificate contains information about

• the mathematical algorithm used to generate its signature
  
  
• the issuer of the certificate, including its country, state or province, locality, organizational name, organizational unit, and common name
  
  
• the validity period
  
  
• the subject or bearer of the certificate, including the subject's country, state or province, locality, organization, organizational unit, and public key
  
  

This section shows you how to configure Stronghold to require a client certificate for access to a directory, then accept only certificates that match a certain set of parameters.

Imagine that you run an online banking service that provides information about customer accounts, including credit accounts. The sensitive nature of this information turns any security weakness into an enormous liability for your company, so you need to ensure that it is as secure as possible. You also need to make sure that each account-holder can access only his particular account information. In this case, basic authentication is insufficient, because there are known techniques for systematically guessing usernames and passwords. Certificates are nearly impossible to forge and can be password-protected on the client side.

In order to test the configuration described here, you need a client certificate and a browser that supports client certificates. If you do not have a client certificate, you can get a test certificate at https://www.xcert.com/demo/.

---

To set up access control with client certificates

1. Create a new directory to hold the dynamic Web pages that would generate account information:
   
   

   # mkdir ServerRoot/htdocs/account-data
   
   

2. Open the server configuration file in your favorite text editor:
   
   

   # vi ServerRoot/conf/httpd.conf
   
   

3. Insert the following in the global server configuration:
   
   

   SSLVerifyClient 2
   
   

   This requires all clients to submit a client certificate.

4. Move to the end of the file.
   
   
5. Insert a new directory container:
   
   

   <Directory ServerRoot/htdocs/account-data>
   . . .
   </Directory>
   
   

6. Enter the following directives inside the directory container:
   
   

   RequireSSL on
   SSL_Require size GTE 1024
   
   

   These directives set

   • the SSL/TLS requirement, which blocks HTTP access and permits HTTPS access
     
     
   • the certificate parameter required for access: The certificate's public key algorithm must implement a key size greater than or equal to 1024 bits.
     
     

   This means that only you can access the directory, and only with your client certificate. You cannot access it from another host without obtaining another client certificate for that host and adding it to the configuration. Constraining the acceptable key size prevents users from accessing the directory using a weak certificate. You can use SSL_Require to set requirements for any field in a client certificate. You can find the complete list of possible arguments for the SSL_Require directive in "SSL Certificate Authentication and Access Control" on page 7-96.

7. Save the modified configuration file.
   
   
8. Restart Stronghold:
   
   

   # ServerRoot/bin/reload-server
   
   

   Stronghold re-reads the configuration file when it restarts.

9. Test the new configuration:
   
   
   • Access https://www.yourhost.com/account-data. Stronghold should return an empty directory index (if directory indexing is enabled).
     
     
   • Try accessing http://www.yourhost.com/account-data. Stronghold should return an error message with status code 403.
     
     

If the test succeeds, you have successfully established access control with client certificates.

Now, imagine that you want to establish two subdirectories within the account-data directory, one for files relating to checking or savings account and one for files relating to credit accounts. You also want to apply a higher level of security to the credit account directory than to the others. To accomplish this, you can use the SSL_Group directive to establish different client certificate access control groups.

---

To set up access control groups

1. Create the new subdirectories:
   
   

   # mkdir ServerRoot/htdocs/account-data/deposit
   # mkdir ServerRoot/htdocs/account-data/credit
   
   

2. Open the server configuration file in your favorite text editor:
   
   

   # vi ServerRoot/conf/httpd.conf
   
   

3. Move to the end of the file.
   
   
4. Enter the following directives:
   
   

   SSLVerifyClient 2
   SSL_Group deposit "size GTE 1024 AND IOU EQ DepositAcctCA"
   SSL_Group credit "size GT 1024 AND IOU EQ CreditAcctCA"
   
   

   SSLVerifyClient requires all clients to submit client certificates. The "credit" SSL/TLS group requires a greater key size than the "deposit" group, for higher security. Note that this means that clients that do not support key sizes greater than 1024 bits are blocked.

5. Create two new directory containers, one for each of the new subdirectories:
   
   

   <Directory ServerRoot/htdocs/account-data/deposit>
   . . .
   </Directory>
   
   <Directory ServerRoot/htdocs/account-data/credit>
   . . .
   </Directory>
   
   

6. Add the following directives to the "deposit" container:
   
   

   RequireSSL on
   SSL_Require deposit
   
   

   These directives set

   • the SSL/TLS requirement, which blocks HTTP access and permits HTTPS access
     
     
   • the SSL/TLS access control group, whose parameters the client must satisfy
     
     
7. Add the following directives to the "credit" container:
   
   

   RequireSSL on
   SSL_Require credit
   
   

8. Save the modified configuration file.
   
   
9. Restart Stronghold:
   
   

   # ServerRoot/reload
   
   

   Stronghold re-reads the configuration file when it restarts.

10. Test the new configuration:
    
    
    • Access https://www.yourhost.com/account-data/deposit using a 1024-bit certificate. Stronghold should return an empty directory index (if directory indexing is enabled).
      
      
    • Try accessing http://www.yourhost.com/account-data/credit using the same certificate. Stronghold should return an error message with status code 403 (Forbidden).
      
      

If the test succeeds, you have successfully established SSL/TLS access control groups.

There are other ways to control access, including DB files, DBM files, and databases. However, these are beyond the scope of this tutorial. The methods described here work well for almost any situation.

---

[Top] [Prev] [Next] [Last]

© 1998 C2Net International Feedback: stronghold-docs@c2.net