| Previous Contents Index DocHome Next |
| iPlanet Web Proxy Server 3.6 Administrator's Guide - Unix Version |
Chapter 5 Controlling Access to Your Server
You can restrict access to all of the data served by the proxy server or to the specific URLs it serves. You can specify that only certain people access specific URLs or that everyone except those people can see the files. This access restriction applies only to URLs that your proxy server can send to a client and does not have anything to do with allowing people to administer or configure your server.For example, you might allow all clients to access URLs for HTTP but then allow only restricted access to FTP. You could also restrict URLs based on host names or domain names, such as if you have a proxy serving many internal web servers but want only specific people to access a confidential research project stored on one of the web servers.
If your server has SSL (Secure Sockets Layer) enabled, the user's name and password are sent encrypted. Otherwise, names and passwords are sent in clear text, and can be read if intercepted.
If you want to control who can configure the proxy server itself and who can access the server configuration files, see Managing Netscape Servers.
When configuring access control for your server, you usually follow this process:
Choose an LDAP directory server or a local database.
For more information on databases, users, and groups, see Managing Netscape Servers.Enter one or more users into the directory or database.
Create a resource by choosing the URLs you want to restrict (discussed on page 69).
Specify the default access (everyone allowed or everyone denied) for that resource (discussed on page 71).
Specify which users are exceptions to the default access (discussed on page 71).
How Does Access Control Work?
You can control access to the entire server or to parts of the server (that is, directories, files, file types). When the server evaluates an incoming request, it determines access based on a hierarchy of rules called access-control entries (ACEs), and then it uses the matching entries to determine if the request is allowed or denied. Each ACE specifies whether or not the server should continue to the next ACE in the hierarchy. The collection of ACEs is called an access-control list (ACL). When a request comes in to the server, the server looks in obj.conf for a reference to an ACL, which is then used to determine access. By default, the server has one ACL file that contains multiple ACLs.
Access Control Files
When you use access control on your proxy server, the settings are stored in a file with the extension .acl. These files are known as access control files, or ACL files. An ACL file is a text file containing access control lists which can be used to control access to server resources. Each access control list controls a set of access rights and specifies the clients that have these rights. Clients can be specified by their IP address, DNS name, user name, group name, or combinations of these attributes.ACL files also contain information about how to authenticate users, such as what user database to use and what authentication method to use. ACL files do not contain any information about the server resources to which they are applied. ACLs are bound to server resources by directives in the server's obj.conf file, which refer to ACLs defined in the ACL file.
Access control files for the proxy server are stored in the directory server_root/httpacl. The main ACL file name is generated.proxy-id.acl; the temporary working file is called genwork.proxy-id.acl. If you use the Server Manager forms to restrict access, you'll have these two files. However, if you want to do more complex restrictions, you can create multiple files and reference them from the magnus.conf file.
You also need to know the syntax and function of ACL files if you plan to customize access control using the access-control API. See"ACL File Syntax" for more information on ACL file syntax.
ACL File Syntax
All ACL files must follow a specific format and syntax. Some general rules of ACLs are:
Spaces, tabs, and newline characters generally are not significant except to create whitespace.
An ACL file contains a sequence of ACL definitions. Each of these specifies an ACL name, a set of access rights to be controlled by the ACL, and a list of ACL directives. The following is the syntax of an ACL.Comments begin with a # and end with a newline, and can be placed anywhere.
Identifiers, including ACL names, access right names, and user and group names, can contain letters, digits, hyphens, and underscores, but must begin with a letter.
With the exception of user, group, and database names, case is generally not significant in identifiers or keywords.
ACL acl-name acl-rights {
acl-directives
}acl-name is a unique name for the ACL. Typically, this name is generated by the Server Manager forms.
acl-rights are a list of access right names separated by commas and enclosed in parentheses. Access right names are specific to a particular type of server. Proxy servers use HTTP and FTP method names as access right names, including GET, HEAD, POST, and PUT.
acl-directives are a list of ACL directives separated by semicolons. There are two basic kinds of directives, a realm-directive and an access-directive. All directives begin with a force-keyword.
realm-directive
The syntax of a realm-directive is:force-keyword Authenticate In realm-definition
force-keyword is a keyword that has one of the following values:
realm definition is a string that gets displayed to the user. It has the form:
{
Database db-name;
Method auth-method-name;
}db-name is the name of an authentication database associated with a realm. The default for db-name uses the SuiteSpot LDAP settings.
auth-method-name is the name of an authentication method supported by the server (currently basic or SSL).
access-directive
An access-directive begins with a force-keyword, followed by either Allow or Deny. The syntax of an access-directive is:force-keyword Allow|Deny authorization-list
force keyword is a keyword that has one of the following values:
authorization-list is the list of users and hosts to which the access-directive applies. It is actually a list of authorization-spec constructs, separated by commas.
Each authorization-spec must contain a user-list, and may contain a host-list. The form of an authorization-spec is:
user-list can be a user name, a group name, or a list of user and/or group names separated by commas and enclosed in parentheses. It can also be one of the special keywords, anyone or all. The keyword anyone indicates that the user's identity is not relevant to applying this directive. The keyword all indicates that any authenticated user in the current realm is matched by the directive.
host-list can be an ip-spec, a dns-spec, or a list of these separated by commas and enclosed in parentheses. An ip-spec specifies an IP host or network address, and consists of an IP address in dotted numeric notation, optionally followed by an IP netmask in dotted numeric notation. A dns-spec can be a fully-qualified domain name, or a partially-qualified domain name that begins with *. An dns-spec could be: "doon.mcom.com", "*.mcom.com", or "*".
Example 1
ACL readers (GET, HEAD) {
Default deny anyone at *;
Default allow anyone at *.mcom.com;
}In the above example, the name of the ACL is readers and the access rights it controls are the HTTP methods, GET and HEAD. Within the ACL are ACL directives which define the users who are denied and allowed GET and HEAD access. Each of the directives in this example begin with the word Default, which indicates that, by default, the directive applies to any client matching the criteria established by the directive. However, if the client also matches the criteria of a subsequent directive, then the that directive will override the previous directive.
The first directive in the previous example denies GET and HEAD access to any client matching its criteria. The criteria are the user name, anyone, at any host with a DNS name matching the pattern, "*". The user name, anyone, is a special name which places no requirements at all on the user identity of the client. It means that the server does not need to know the identity of the client user, so it will match unauthenticated clients. The DNS name pattern, "*", matches any client DNS name, so the net effect of this directive is that it will match any client, with or without authentication, from any host name.
By itself, the first directive denies access to anyone and everyone. However, the second directive allows access to a more selective set of clients, that is, clients with host names matching the pattern, *.mcom.com. The second directive also identifies anyone as the allowed user, indicating that the user name of the client is not relevant.
In summary, what this example does is restrict client access based only on the client host DNS name, denying access to all client hosts except those with DNS names ending with .mcom.com. We could have also identified the client hosts using IP addresses, specifying a netmask to indicate which bits of the IP address are required to match:
Example 2
ACL readers (GET, HEAD) {
Default deny anyone at 0.0.0.0 0.0.0.0;
Default allow anyone at
(
198.93.92.0 255.255.255.0, 198.93.93.0 255.255.255.0,
198.93.94.0 255.255.255.0, 198.93.95.0 255.255.255.0,
198.95.249.0 255.255.255.0, 198.95.250.0 255.255.255.0,
205.217.226.0 255.255.255.0, 205.217.228.0 255.255.255.0,
205.217.229.0 255.255.255.0, 205.217.230.0 255.255.255.0,
205.217.231.0 255.255.255.0, 205.217.232.0 255.255.255.0,
205.217.233.0 255.255.255.0, 205.217.234.0 255.255.255.0,
205.217.235.0 255.255.255.0, 205.217.236.0 255.255.255.0,
205.217.237.0 255.255.255.0, 205.217.238.0 255.255.255.0,
205.217.239.0 255.255.255.0, 205.217.240.0 255.255.255.0,
205.217.241.0 255.255.255.0, 205.217.242.0 255.255.255.0,
205.217.243.0 255.255.255.0, 205.217.244.0 255.255.255.0,
205.217.252.0 255.255.255.0, 205.217.254.0 255.255.255.0,
205.217.255.0 255.255.255.0
);
}Here 0.0.0.0 0.0.0.0 specifies an IP address and a netmask. With no bits set in the netmask, this specification will match any IP address, and therefore the first directive will have the effect of denying access to all clients.
The second directive in the above example allows access to any of the client hosts in the specified ranges. Notice that the list of IP address and netmask pairs is specified in parentheses. Because many different ranges of IP addresses are in use in the domain mcom.com, a list of IP address and netmask pairs must be given in order to identify the client hosts in this domain.
Example 3
ACL readers (GET, HEAD) {
Always allow anyone at webmaster.enterprise.com;
Default authenticate in {
Database enterprise.com;
Method SSL;
};
Default deny anyone at *;
Default allow all at *.enterprise.com;
Default deny contractors at *.enterprise.com;
}ACL directives are evaluated in the order in which they appear in an ACL definition. The word "Default" at the beginning of an ACL directive indicates that the effect of the directives is not immediate, and that the effect may be modified or even nullified by subsequent directives. In some cases, however, it may be desirable to have a directive which takes effect immediately. As shown in the previous example, replacing the word "Default" with the word "Always" makes the directive immediately effective.
This example immediately allows access to any user connecting from the host, webmaster.enterprise.com, without requiring authentication. When the client host is webmaster.enterprise.com, the directives following the first one are not evaluated.
Controlling Access with Client Certificates
If you have enabled SSL on your server, you can use client certificates in conjunction with access control. To do this, you must specify that a resource requires a client certificate to access it. When this feature is enabled on your server, users with certificate types their login name and password only the first time they attempt to access a restricted resource. Once their identity is established, the server maps their login name and password to that specific certificate. From then on, users no longer need to type their login name or password when accessing resources where client authentication is required. When users attempt to access a restricted resource, their client sends the server the client certificate, which the server checks against its list of mappings. If the certificate belongs to a user to whom you've granted access to the resource, the resource is served.
Note Requiring client authentication for controlling access to specific resources is different than requiring client authentication for all connections to the server, as described in "Setting Encryption Preferences" on page 228. Also be aware that requiring client certificates for all SSL connections does not automatically map the certificates to users in your databases. To do this, you must specify that a client certificate is required in order to access a specified resource, as described in Allowing Access to a Resource.
Restricting Access
After you have created the users you want to use in access control (see Managing Netscape Servers), you use the Restrict Access form to restrict user access to specified URLs.To change the access control for part of your server,
In the Server Manager, choose Server Preferences|Restrict Access. The Restrict Access form appears.
Use the drop-down list to choose a regular expression that matches the URLs you want to configure.
Turn access control off or on for the selected URLs by clicking either the Turn off access control or Turn on access control button.
- If an expression doesn't exist, click the Regular Expressions button and create an expression. For example, to change access to all URLs in the Netscape domain, type .*://.*\.netscape\.com/.* in the field. For more information on regular expressions, see "Understanding Regular Expressions" on page 44.
For both read and write access, set the default accessibility—allow or deny.
- Turning on access control causes more access control settings to appear on your screen.
Specify which users are the exceptions to the default accessibility for each access type by clicking the appropriate Permissions button.
- Read access allows a user only to view the file. Write access allows the user to change or delete the file, assuming the user also has access to the file through your server computer's operating system. (Technically, read includes these HTTP methods: GET, HEAD, POST, and INDEX. Write includes PUT, DELETE, MKDIR, RMDIR, and MOVE.)
- When you set these access defaults, they will apply to everyone attempting to read or write to files or directories in the URLs you specify. For example, you can allow users read access to the Netscape domain so they can download software through your proxy server.
Choose the response a client will see when access is denied. Under the Access Denied Response heading, click the Respond "Forbidden" button to send a message to the client saying that access to the requested file is forbidden.
- If the default access is allow, the Deny Access to a Resource form appears (see Denying Access to a Resource). If the default access is deny, the Allow Access to a Resource form appears (see Allowing Access to a Resource). After using those forms, the Server Manager returns you to the Restrict Access form.
Click the OK button and confirm your changes.
- Alternatively, you can click the "Respond with this html file" button and specify an absolute path and filename of an HTML file to send instead of sending the generic "Forbidden" message. Whether or not you specify a file, the server also sends the HTTP error code 404 Not Found.
Note If you have enabled access control for your server and you want to password-protect local files such as the PAC file, add the following line to the obj.conf file:
Denying Access to a Resource
In the Restrict Access form, you set the default read and write access of a resource (a regular expression of matching URLs). If you set read or write access to allow all access by default, you can specify exceptions by clicking the Permissions button. The Deny Access to a Resource form appears.When determining who is denied access, you can specify users from specified host names or IP addresses.
First you must specify how host names are processed. If you want to deny users from only the exact host names you'll specify, click Include specified names only. However, if you also want to deny users from alias domains of your specified host names, click Include aliases of specified names.
To deny users from specific host names or IP addresses, type a comma-separated list of host names or IP addresses in the text fields. Restricting by host name is more flexible than restricting by IP address—if a user's IP address changes, you won't have to update this list. However, restricting by IP address is more reliable—if a DNS lookup fails for a connected client, host name restriction cannot be used.
The host name and IP addresses should be specified with a wildcard pattern or a comma-separated list. The wildcard notations you can use are specialized; you can only use the * character. Also, for the IP address, the * must replace an entire byte in the address. That is, 198.95.251.* is acceptable, but 198.95.251.3* is not. When the * character appears in an IP address, it must be the rightmost character. For example, 198.* is acceptable, but 198.*.251.30 is not.
For host names, the * must also replace an entire component of the name. That is, *.netscape.com is acceptable, but *sers.netscape.com is not. When the * appears in a host name, it must be the leftmost character. For example, *.netscape.com is acceptable, but users.*.com is not.
Allowing Access to a Resource
In the Restrict Access form described on page 69, you set the default read and write access of a resource. If you set read or write access to deny all access by default, you can specify exceptions by clicking the Permissions button. The Allow Access to a Resource form appears.When determining who is allowed access, you can specify two types of users:
You specify both types of users in the Allow Access to a Resource form.
If all types of user authentication are used, the server checks the user's information in the following order (if the criteria in either step 1 or step 2 are met, the client skips the other steps and is allowed access).
Is the client's IP address automatically allowed?
When a request for a URL comes in, the server knows the IP address from which the request is coming. Once the server has this address, it uses DNS to look up the host name that corresponds to that IP address.Is the client's host name automatically allowed?
Is the client identified (through password) as one of the allowed users from your database?
Is the client's IP address allowed if the user is one of the allowed users from your database?
Is the client's host name allowed if the user is one of the allowed users from your database?
If you specify from which host names to allow users, decide how you want the host names processed. If you want to allow only users from the exact host names you specify, click Include specified names only. However, if you also want to accept users from alias domains of your specified host names, click Include aliases of specified names.
To allow users from specific host names or IP addresses, enter a wildcard pattern of host names or IP addresses in text fields. Restricting by host name is more flexible than restricting by IP address—if a user's IP address changes, you won't have to update this list. In contrast, restricting by IP address is more reliable—if a DNS lookup fails for a connected client, host name restriction cannot be used.
Users who are allowed access by virtue of their host name or IP address (as in steps 1 and 2 on page 72) are not prompted for a login name or password. All other users are asked for that information.
To allow access to the users listed in your database (LDAP directory), choose the user database containing the appropriate users.
Note You can select whether your proxy server will use a directory server or a local database on the Global Settings page in the administration server.
Choose whether to allow everyone from that database or to allow only certain groups and users.
Using a comma-separated list, specify the groups in the Groups field or the users in the Users field.
To further restrict access, specify any additional host names or IP addresses from which the users in the database must connect. These host names and IP Addresses fields can be left blank if your database users can be from any host names or IP addresses.
- For example, if your database contains Bob, Juan, Margaret, and Joe but you want only Bob and Margaret to have access to this section, type Bob,Margaret. If you leave this entry blank, all users from the database are allowed access.
Specify the message that a user sees when asked for a login name and password by typing it in the Login Prompt field.
Be sure to click OK in the Restrict Access form when you have finished modifying access control for part of your server.
Previous Contents Index DocHome Next
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.
Last Updated September 27, 2001