Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Web Proxy Server 4.0.1 Administration Guide 

Chapter 8
Controlling Access to Your Server

This chapter describes how to control access to the Administration Server and the data served by the Proxy Server. Access can be restricted to all data served by the server, or to specific URLs it serves. For example, you can specify that only certain people access specific URLs, or that everyone except those people can see the files. You might allow all clients to access URLs for HTTP, but allow only restricted access to FTP. You could also restrict URLs based on host names or domain names, such as when you have a Proxy Server serving many internal web servers, but want only specific people to access a confidential research project stored on one of those servers.

Before access control can be used on the Administration Server, you must enable distributed administration and configure an administration group in your LDAP database. The information in this chapter is based on the assumption that those tasks have been performed.

This chapter contains the following sections:

What is Access Control?

Access control enables you to determine who can access the Proxy Server, and what parts of the server they can access. You can control access to the entire server or to just parts of the server, such as directories, files, file types, and so on. When an incoming request is evaluated, access is determined based on a hierarchy of rules called access control entries (ACEs). Proxy Server looks for matching entries to determine whether access should be granted or denied. Each ACE specifies whether the server should continue to the next entry in the hierarchy. The collection of ACEs is called an access control list (ACL). When a request is received, the obj.conf file is checked 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 is allowed or denied based on:

This section contains the following topics:

Access Control for User-Group

You can limit access to your server to certain users or groups. User-Group access control requires users to enter a user name and password before gaining access to the server. The server compares the information in a client certificate, or the client certificate itself, with a directory server entry.

The Administration Server uses only Basic authentication. To require client authentication on the Administration Server, you must manually edit the ACL files in obj.conf, changing the method to SSL.

User-Group authentication is performed by the directory service configured for a server. For more information, see Configuring Directory Services.

The information a directory service uses to implement access control can come from either of the following sources:

When the server uses an external LDAP-based directory service, the following types of User-Group authentication methods are supported for server instances:

When the server uses an internal file-based directory service, the User-Group authentication methods supported for server instances includes the following:

User-Group authentication requires users to authenticate themselves before gaining access. With authentication, users verify their identity by entering a user name and password, by using a client certificate, or with the Digest authentication plug-in. Using client certificates requires encryption.

Default Authentication

Default authentication is the preferred method. The Default setting uses the default method in the obj.conf file, or Basic if there is no setting in obj.conf. If Default is selected, the ACL rule does not specify a method in the ACL file. Choosing Default enables you to easily change the methods for all ACLs by editing one line in the obj.conf file.

Basic Authentication

Basic authentication requires users to enter a user name and password to access the server. It is the default setting. You must create and store a list of users and groups in an LDAP database, such as the Sun Java System Directory Server, or in a file. You must use a directory server installed on a different server root than your Proxy Server, or a directory server installed on a remote computer.

When users attempt to access a resource that has User-Group authentication, users are prompted to enter a user name and password. The server receives this information encrypted or unencrypted, depending on whether encryption is turned on for your server (SSL is enabled).

Caution

Using Basic authentication without SSL encryption sends the user name and password in unencrypted text across the network. The network packets could be intercepted, and the user name and password could be pirated. Basic authentication is most effective when combined with SSL encryption, Host-IP authentication, or both. Using Digest authentication eliminates this problem.

After authenticating, the user then sees:

You can customize the message received by unauthorized users. For more information, see Responding When Access is Denied.

SSL Authentication

The server can confirm users’ identities with security certificates in two ways:

When the server is configured to use certificate information for authenticating the client, the server:

Requiring client authentication for controlling access to specific resources differs from requiring client authentication for all connections to the server. If the server is configured to require client authentication for all connections, the client must only present a valid certificate issued by a trusted CA. If the server is configured to use the SSL method for authentication of users and groups, the following must happen:

When you require client authentication with access control, SSL ciphers must be enabled for your Proxy Server. See Using Certificates and Keys for more information about enabling SSL.

To successfully gain access to an SSL-authenticated resource, the client certificate must be from a CA trusted by the Proxy Server. The client certificate must be published in a directory server if the Proxy Server’s certmap.conf file is configured to compare the client’s certificate in the browser with the client certificate in the directory server. However, the certmap.conf file can be configured to only compare selected information from the certificate to the directory server entry. For example, you could configure certmap.conf to only compare the user ID and e-mail address in the browser certificate with the directory server entry. For more information about certmap.conf and certificate mapping, see Using Certificates and Keys. Also see the Proxy Server Configuration File Reference.

Digest Authentication

Proxy Server can be configured to perform Digest authentication using either an LDAP-based or a file-based directory service.

Digest authentication allows users to authenticate based on user name and password without sending the user name and password as cleartext. The browser uses the MD5 algorithm to create a digest value using the user's password and some information provided by the Proxy Server.

When the server uses an LDAP-based directory service to perform Digest authentication, this digest value is also computed on the server side using the Digest authentication plug-in, and compared against the digest value provided by the client. If the digest values match, the user is authenticated. For this to work, your directory server must have access to the user's password in cleartext. Sun Java System Directory Server includes a reversible password plug-in using a symmetric encryption algorithm to store data in an encrypted form that can later be decrypted to its original form. Only the Directory Server holds the key to the data.

For LDAP-based Digest authentication, you must enable the reversible password plug-in and the Digest authentication-specific plug-in included with Proxy Server. To configure your Proxy Server to process Digest authentication, set the digestauth property of the database definition in the dbswitch.conf file, found in server_root/userdb/.

The server tries to authenticate against the LDAP database based upon the ACL method specified, as shown in Table 8-1. If you do not specify an ACL method, the server uses either Digest or Basic when authentication is required, or Basic if authentication is not required.

The following table lists Digest authentication that is and is not supported by the authentication database.

Table 8-1  Digest Authentication Challenge Generation

ACL Method

Supported by Authentication Database

Not Supported by Authentication Database

Default

None specified

Digest and Basic

Basic

Basic

Basic

Basic

Digest

Digest

ERROR

When processing an ACL with method=digest, the server attempts to authenticate by:

Installing the Digest Authentication Plug-in

For Digest authentication using an LDAP-based directory service, you must install the Digest authentication plug-in. This plug-in computes a digest value on the server side, and compares this against the digest value provided by the client. If the digest values match, the user is authenticated.

If you are using a file-based authentication database, you do not need to install the Digest authentication plug-in.

Installing the Digest Authentication Plug-in on UNIX

The Digest authentication plug-in consists of a shared library found in both:

To install the Digest authentication plug-in on UNIX

  1. Make sure this shared library resides on the same server computer on which the Sun Java System Directory Server is installed.
  2. Make sure you know the Directory Manager password.
  3. Modify the libdigest-plugin.ldif file changing all references to /path/to to the location where you installed the digest plug-in shared library.
  4. To install the plug-in, enter the command:

    5. % ldapmodify -D "cn=Directory Manager" -w password -a < libdigest-plugin.ldif

Installing the Digest Authentication Plug-in on Windows

You must copy several .dll files from the Proxy Server installation to your Sun Java System Directory Server server computer for the Directory Server to start properly with the Digest plug-in.

To install the Digest authentication plug-in on Windows

  1. Access the shared libraries in Proxy Server in:

    2. server_root\bin\proxy\bin

  2. Copy the files:
    • nsldap32v50.dll
    • libspnr4.dll
    • libplds4.dll
  3. Paste them into either:
    • \Winnt\system32
    • The Sun Java System Directory Server install directory: server_root\bin\sldap\server
Setting the Sun Java System Directory Server to Use the DES Algorithm

The DES algorithm is needed to encrypt the attribute where the digest password is stored.

To set the Directory Server to use the DES algorithm

  1. Launch the Sun Java System Directory Server Console.
  2. Open your iDS 5.0 instance.
  3. Select the Configuration tab.
  4. Click the + sign next to plug-ins.
  5. Select the DES plug-in.
  6. Choose Add to add a new attribute.
  7. Enter iplanetReversiblePassword.
  8. Click Save.
  9. Restart your Sun Java System Directory Server instance.

    Note

    To set a Digest authentication password in the iplanetReversiblePassword attribute for a user, your entry must include the iplanetReversiblePasswordobject object.

Other Authentication

You can create a custom authentication method using the access control API.

Access Control for Host-IP

You can limit access to the Administration Server and its files and directories by making them available only to clients using specific computers. You specify host names or IP addresses for the computers you want to allow or deny. Access to a file or directory using Host-IP authentication appears seamless to the user. Users can access the files and directories immediately, without entering a user name or password.

Because more than one person may use a particular computer, Host-IP authentication is more effective when combined with User-Group authentication. If both methods of authentication are used, a user name and password will be required for access.

Host-IP authentication does not require DNS (Domain Name Service) to be configured on your server. If you choose to use Host-IP authentication, you must have DNS running in your network, and your server must be configured to use it. To enable DNS, access the Server Manager for your server, click the Preferences tab, and then click Configure System Preferences. You will see the DNS settings.

Enabling DNS degrades the performance of Proxy Server because the server is forced to perform DNS lookups. To reduce the effects of DNS lookups on your server’s performance, resolve IP addresses only for access control and CGI instead of resolving the IP address for every request. To do this, specify the following in obj.conf:

AddLog fn="flex-log" name="access" iponly=1

Using Access Control Files

When you use access control on the Administration Server or the files or directories on the server, the settings are stored in a file with the extension .acl. Access control files are stored in the directory server_root/httpacl, with server_root being the location where the server is installed. For example, if you installed the server in /usr/Sun/Servers, the ACL files for both the Administration Server and each server instance configured on your server would be located in /usr/Sun/Servers/httpacl/.

The main ACL file is generated-proxy-serverid.acl. The temporary working file is genwork-proxy-serverid.acl. If you use the Administration Server to configure access, you will have these two files. However, if you want more complex restrictions, you can create multiple files and reference them from the server.xml file. A few features are also available only by editing the files, such as restricting access to the server based on the time of day or day of the week.

For more information about access control files and their syntax, see ACL File Syntax. For more information about server.xml, see the Proxy Server Configuration File Reference.

Configuring the ACL User Cache

By default, Proxy Server caches user and group authentication results in the ACL user cache. You can control the amount of time the ACL user cache is valid by using the ACLCacheLifetime directive in the magnus.conf file. Each time an entry in the cache is referenced, its age is calculated and checked against ACLCacheLifetime. The entry is not used if its age is greater than or equal to the ACLCacheLifetime. The default value is 120 seconds. Setting the value to 0 (zero) turns the cache off. If you use a large number for this value, you may need to restart Proxy Server every time you make changes to the LDAP entries. For example, if this value is set to 120 seconds, Proxy Server might be out of sync with the LDAP directory for as long as two minutes. Only set a large value if your LDAP directory is not likely to change often.

Using the magnus.conf parameter of ACLUserCacheSize, you can configure the maximum number of entries that can be held in the cache. The default value for this parameter is 200. New entries are added to the head of the list, and entries at the end of this list are recycled to make new entries when the cache reaches its maximum size.

You can also set the maximum number of group memberships that can be cached per user entry using the magnus.conf parameter ACLGroupCacheSize. The default value for this parameter is 4. Unfortunately, non-membership of a user in a group is not cached, and results in several LDAP directory accesses on every request.

Controlling Access with Client Certificates

If SSL is enabled on your server, client certificates can be used in conjunction with access control. To do this, you must specify that a client certificate is required to access a specific resource. When this feature is enabled on your server, users with a certificate enter their 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 enter their login name or password when accessing resources for which 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 have granted access, 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. 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 to access a specified resource.

How Access Control Works

When the server receives a request for a page, it uses the rules in the ACL file to determine if access should be granted. The rules can reference the host name or IP address of the computer sending the request. The rules can also reference users and groups stored in the LDAP directory.

The following example shows the possible contents of an ACL file, and provides examples of access control rules.

version 3.0;

# The following "es-internal" rules protect files such

# as icons and images related to Sun Java System Web Proxy Server.

# These "es-internal" rules should not be modified.

  acl "es-internal";

  allow (read, list, execute,info) user = "anyone";

  deny (write, delete) user = "anyone";

# The following rules deny access to the directory "web"

# to everyone not in the directory server and deny everyone

# in the directory server who is not in GroupB.

# Only the users in GroupB are allowed read, execute, list,

# and info permissions. GroupA cannot gain access to the

# directory "web" even though (in the ACL rule below) they

# can access the directory “my_stuff”. Furthermore, members

# of GroupB cannot write or delete files.

  acl "path=/export/user/990628.1/docs/my_stuff/web/";

  authenticate (user,group) {

     database = "default";

     method = "basic";

  };

  deny (all)

  (user = "anyone");

  allow (read,execute,list,info)

  (group = "GroupB");

# The following rule denies everyone not in the directory

# server and denies everyone in the directory server except

# users with the ID of "SpecificMemberOfGroupB". The ACL rule

# in this setting also has a requirement that the user

# connect from a specific IP address. The IP address setting

# in the rule is optional, and has been added for extra

# security. Also, this ACL rule has a Customized prompt

# of "Presentation Owner". This Customized prompt appears

# in the username and password dialog box in the client's

# browser.

  acl "path=/export/user/990628.1/docs/my_stuff/web/presentation.html";

  authenticate (user,group) {

     database = "default";

     method = "basic";

     prompt = "Presentation Owner";

  };

  deny (all)

  (user = "anyone" or group = "my_group");

  allow (all)

  (user = "SpecificMemberOfGroupB") and

  (ip = "208.12.54.76");

# The following ACL rule denies everyone not in the directory

# server and everyone in the directory server except for

# GroupA and GroupB access to the directory “my_stuff”

  acl "path=/export/user/990628.1/docs/my_stuff/";

  authenticate (user,group) {

     database = "default";

     method = "basic";

  };

  deny (all)

  (user = "anyone");

  allow (read,execute,list,info)

  (group = "GroupA,GroupB");

For example, if a user requests the URL: http://server_name/my_stuff/web/presentation.html

Proxy Server first checks access control for the entire server. If the ACL for the entire server is set to continue, the server checks for an ACL for the directory my_stuff. If an ACL exists, the server checks the ACEs within the ACL, and then moves on to the next directory. This process continues until an ACL is found that denies access, or until the final ACL for the requested URL (in this case, the file presentation.html) is reached.

To set up access control for this example using the Server Manager, you could create an ACL for the file only, or for each resource leading to the file. That is, one for the entire server, one for the my_stuff directory, one for the my_stuff/web directory, and one for the file.

Note

If more than one ACL matches, the server uses the last ACL statement that has a match.

Setting Access Control

This section describes the process of restricting access. You can set global access control rules for all servers, and also individually for specific servers. For instance, a human resources department might create ACLs allowing all authenticated users to view their own payroll data, but restrict access for the purpose of updating data to human resources personnel responsible for payroll.

This section contains the following topics:

Note

Distributed administration must be configured and activated before global access control can be set.

Setting Access Control Globally

To set access control for all servers
  1. Access the Administration Server and click the Global Settings tab.
  2. Click the Administer Access Control link.
  3. Select the administration server (proxy-admserv) from the drop-down list, click Go to load data, and then click New ACL (or Edit ACL).
  4. Authenticate if prompted. The Access Control Rules For page displays. The Administration Server has two lines of default access control rules, which cannot be edited.
  5. Select Access Control Is On, if not already selected.
  6. To add a default ACL rule to the bottom row of the table, click the New Line button. To change the position of an access control restriction, click the up or down arrow.
  7. Click Anyone in the Users/Groups column. The User/Group page displays in the lower frame.
  8. Select the users and groups to which you will allow access, and click Update. Clicking the List button for Group or User provides lists from which to choose. For more information about the settings, see the online Help. Also see Specifying Users and Groups.
  9. Click Anyplace in the From Host column. The From Host page displays in the lower frame.
  10. Specify the host names and IP addresses allowed access, and click Update. For more information about the settings, see the online Help. Also see Specifying the From Host.
  11. Click All in the Programs column. The Programs page displays in the lower frame.
  12. Select the Program Groups or enter the specific file name in the Program Items field to which you will allow access, and click Update. For more information about the settings, see the online Help. Also see Restricting Access to Programs.
  13. (Optional) Click the X in the Extra column to add a customized ACL expression. The Customized Expressions page displays in the lower frame. For more information, see Writing Customized Expressions.
  14. Select the checkbox in the Continue column, if not already selected. The server evaluates the next line before determining if the user is allowed access. When creating multiple lines, work from the most general restrictions to the most specific.
  15. (Optional) Click the trash can icon to delete the corresponding line from the access control rules.
  16. (Optional) Click the Response When Denied link to specify the response a user receives when denied access. The Access Deny Response page displays in the lower frame. Select the desired response, specify additional information if appropriate, and then click Update. For more information about the settings, see Responding When Access is Denied.
  17. Click Submit to store the new access control rules in the ACL file, or Revert to reset elements in the page to the values they contained before changes were made.

Setting Access Control for a Server Instance

You can create, edit, or delete access control for a specific server instance using the Server Manager. If deleting, do not delete all ACL rules from the ACL files. At least one ACL file containing a minimum of one ACL rule is required to start the server. Deleting all ACL rules and restarting the server will result in a syntax error.

To set access control for a server instance
  1. Access the Server Manager for the server instance and click the Preferences tab.
  2. Click the Administer Access Control link.
  3. Select an ACL using one of the following methods:
    • Select A Resource displays resources that use ACLs to restrict access. Select a resource from the drop-down list, or click Regular Expression to specify a regular expression. For more information, see Managing Templates and Resources. in the Proxy Server Administration Guide.
    • Select An Existing ACL lists all ACLs that are enabled. Existing ACLs that are not enabled do not display in this list. Make your selection from the drop-down list.
    • Type In The ACL Name enables you to create named ACLs. Use this option only if you are familiar with ACL files. You must manually edit obj.conf if you want to apply named ACLs to resources. For more information, see ACL File Syntax.
  4. Click the corresponding Edit button. The Access Control Rules For page displays.
  5. Select Access Control Is On, if not already selected.
  6. To add a default ACL rule to the bottom row of the table, click the New Line button. To change the position of an access control restriction, click the up or down arrow.
  7. To edit the ACL for this server instance, click the action in the Action column. The Allow/Deny page displays in the lower frame.
  8. Select Allow if not already selected as the default, and click Update. For more information about Allow or Deny, see Setting the Action.
  9. Click Anyone in the Users/Groups column. The User/Group page displays in the lower frame.
  10. Select the users and groups to which you will allow access, specify authentication information, and then click Update. Clicking the List button for Group or User provides lists from which to choose. For more information about the settings, see the online Help. Also see Specifying Users and Groups.
  11. Click Anyplace in the From Host column. The From Host page displays in the lower frame.
  12. Specify the host names and IP addresses allowed access, and click Update. For more information about the settings, see the online Help. Also see Specifying the From Host.
  13. Click All in the Rights column. The Access Rights page displays in the lower frame.
  14. Specify access rights for this user, and then click Update. For more information, see Restricting Access to Programs.
  15. (Optional) Click the X under the Extra column to add a customized ACL expression. The Customized Expressions page displays in the lower frame. For more information, see Writing Customized Expressions.
  16. Select the checkbox in the Continue column, if not already selected. The server evaluates the next line before determining if the user is allowed access. When creating multiple lines, work from the most general restrictions to the most specific.
  17. (Optional) Click the trash can icon to delete the corresponding line from the access control rules. Do not delete all ACL rules from the ACL files. At least one ACL file containing at least one ACL rule is required to start the server. If you delete all ACL rules in the ACL files and try to restart the server, you will receive a syntax error.
  18. (Optional) Click the Response When Denied link to specify the response a user receives when denied access. The Access Deny Response page displays in the lower frame. Select the desired response, specify additional information if appropriate, and then click Update. For more information about the settings, see Responding When Access is Denied.
  19. Click Submit to store the new access control rules in the ACL file, or Revert to reset elements in the page to the values they contained before changes were made.

Selecting Access Control Options

The following topics describe the various options you can select when setting access control. For the Administration Server, the first two lines are set as defaults, and cannot be edited.

This section contains the following topics:

Setting the Action

You can specify the action the server takes when a request matches the access control rule.

The server goes through the list of access control entries (ACEs) to determine the access permissions. For example, the first ACE is usually to deny everyone. If the first ACE is set to continue, the server checks the second ACE in the list, and if it matches, the next ACE is used. If Continue is not selected, everyone is denied access to the resource. The server continues down the list until it reaches either an ACE that does not match, or one that matches but does not continue. The last matching ACE determines if access is allowed or denied.

Specifying Users and Groups

With user and group authentication, users are prompted to enter a user name and password before they can access the resource specified in the access control rule.

Proxy Server checks lists of users and groups stored either in an LDAP server, such as Sun Java System Directory Server, or in an internal file-based authentication database.

You can allow or deny access to everyone in the database, you can allow or deny specific people by using wildcard patterns, or you can select who to allow or deny from lists of users and groups.

The following elements are displayed for Users/Groups on the Access Control Rules For page in the user interface.

Specifying the From Host

You can restrict access to the Administration Server based on which computer the request comes from.

The following elements are displayed for From Host on the Access Control Rules For page in the user interface.

If the Only From option is selected, enter a wildcard pattern or a comma-separated list in the Host Names or IP Addresses fields. Restricting by host name is more flexible than by IP address. If a user’s IP address changes, you do not need to update this list. Restricting by IP address, however, is more reliable. If a DNS lookup fails for a connected client, host name restriction cannot be used.

You can only use the * wildcard notation for wildcard patterns that match the computers’ host names or IP addresses. For example, to allow or deny all computers in a specific domain, you would enter a wildcard pattern that matches all hosts from that domain, such as *.example.com. You can set different host names and IP addresses for superusers accessing the Administration Server.

For host names, the * must replace an entire component of the name. That is, *.example.com is acceptable, but *users.example.com is not. When the * displays in a host name, it must be the leftmost character. For example, *.example.com is acceptable, but users.*.com is not.

For the IP address, the * must replace an entire byte in the address. For example, 198.95.251.* is acceptable, but 198.95.251.3* is not. When the * displays in an IP address, it must be the rightmost character. For example, 198.* is acceptable, but 198.*.251.30. is not.

Restricting Access to Programs

Access to programs can only be restricted by the Administration Server. Restricting access to programs allows only specified users to view the Server Manager pages, and determines if those users can configure that server. For example, you might allow some administrators to configure the Users and Groups section of the Administration Server, but deny access to the Global Settings section.

You can configure different users to access different functional domains. Once a user is given access to a few selected functional domains, after the user logs in, Administration Server pages from only those functional domains are available to that user.

The following elements are displayed for Programs on the Access Control Rules For page in the user interface.

Setting Access Rights

Access rights can only be set by the Server Manager for a server instance. Access rights restrict access to files and directories on your server. In addition to allowing or denying all access rights, you can specify a rule that allows or denies partial access rights. For example, you could allow users read-only access rights to your files so they can view the information but not change the files.

The following elements are displayed for Rights on the Access Control Rules For page in the user interface.

Writing Customized Expressions

You can enter custom expressions for an ACL. Select this option only if you are familiar with the syntax and structure of ACL files. A few features are available only by editing the ACL file or creating custom expressions. For example, you can restrict access to your server depending on the time of day, day of the week, or both.

The following customized expression shows how you could restrict access by time of day and day of the week. This example assumes you have two groups in your LDAP directory. The Regular group gets access Monday through Friday, 8:00 am to 5:00 pm. The Critical group gets access all the time.

allow (read)
{
  (group=regular and dayofweek=”mon,tue,wed,thu,fri”);
  (group=regular and (timeofday>=0800 and timeofday<=1700));
  (group=critical)
}

For more information about valid syntax and ACL files, see ACL File Syntax.

Turning Access Control Off

When you deselect the option labeled Access Control Is On on the Access Control Rules For page, you receive a prompt asking if you want to erase records in the ACL. When you click OK, the ACL entry for that resource is deleted from the ACL file.

If you want to deactivate an ACL, comment out the ACL lines in the file generated-proxy-serverid.acl by using # signs at the start of each line.

From the Administration Server, you could create and turn on access control for a specific server instance and leave it off (the default) for other servers. For example, you could deny all access to the Server Manager pages from the Administration Server. With distributed administration on and access control off by default for any other servers, administrators could still access and configure the other servers, but could not configure the Administration Server.

Responding When Access is Denied

Proxy Server provides a default message when access is denied, and you can customize the response if desired. You can also create a different message for each access control object.

By default, for the Administration Server, users receive the Permission Denied message in server_root/httpacl/admin-denymsg.html.

To change the Access Denied message
  1. Click the Response When Denied link on the Access Control Rules For page.
  2. Select the desired response, enter additional information if appropriate (make sure users have access to the response to which they are redirected), and then click Update.
  3. Click Submit to save your changes, or Revert to reset the elements in the page to the values they contained before your changes.

Limiting Access to Areas of Your Server

This section describes some commonly used restrictions to a server and its contents. The steps for each procedure detail the specific actions you must take. However, you still must complete the steps described in Setting Access Control for a Server Instance.

This section contains the following topics:

Restricting Access to the Entire Server

You may want to allow access to users in a group who access the server from computers in a subdomain. For instance, you may have a server for a company department that you only want users to access from computers in a specific subdomain of your network.

To restrict access to the entire server

Using the steps described for setting access control for a server instance (see Setting Access Control for a Server Instance), do the following:

  1. Access the Server Manager for the server instance.
  2. On the Preferences tab, click the Administer Access Control link.
  3. Select the entire server from the drop-down list, click Select, and then click the corresponding Edit button. The Access Control Rules For page displays.
  4. Add a new rule to deny access to all.
  5. Add another new rule to allow access to a specific group.
  6. Use From Host to specify the host names and IP addresses you want to restrict.
  7. Click Submit to save your changes.

Restricting Access to a Directory (Path)

You can allow users in a group to read or run applications in directories, and the subdirectories and files, that are controlled by an owner of the group. For example, a project manager might update status information for a project team to review.

To restrict access to directories

Using the steps described for setting access control for a server instance (see Setting Access Control for a Server Instance), do the following:

  1. Access the Server Manager for the server instance.
  2. On the Preferences tab, click the Administer Access Control link.
  3. Select the desired resource from the drop-down list and click Edit.
  4. Create a new rule and leave the defaults to deny access to everyone from everywhere.
  5. Create another new rule allowing users in a specific group to have read and execute rights only.
  6. Create a third new rule to allow a specific user to have all rights.
  7. Deselect Continue for the last two rules.
  8. Click Submit to save your changes.

Restricting Access to a File Type

You can limit access to file types. For example, you might want to allow only specific users to create programs that run on your server. Anyone would be able to run the programs, but only specified users in the group would be able create or delete them.

To restrict access to file types

Using the steps described for setting access control for a server instance (see Setting Access Control for a Server Instance), do the following:

  1. Access the Server Manager for the server instance.
  2. On the Preferences tab, click the Administer Access Control link.
  3. Click Regular Expression in the Select A Resource section, and specify the regular expression. For example: *.cgi.
  4. Click Edit.
  5. Create a new rule to allow read access to all users.
  6. Create another rule that allows write and delete access only to a specified group.
  7. Click Submit to save your changes.

For file type restriction, you would leave both Continue boxes selected. If a request for a file comes in, the server then checks the ACL for the file type first.

A Pathcheck function is created in obj.conf that may include wildcard patterns for files or directories. The entry in the ACL file would appear as follows: acl"*.cgi";

Restricting Access Based on Time of Day

You can restrict write and delete access to the server during specified hours or on specified days.

To restrict access based on time of day

Using the steps described for setting access control for a server instance (see Setting Access Control for a Server Instance), do the following:

  1. Access the Server Manager for the server instance.
  2. On the Preferences tab, click the Administer Access Control link.
  3. Select the entire server from the drop-down list in the Select A Resource section, and click Edit.
  4. Create a new rule allowing read and execute rights to all. This means that if a user wants to add, update, or delete a file or directory, this rule does not apply and the server searches for another rule that matches.
  5. Create another new rule denying write and delete rights to all.
  6. Click the X link to create a customized expression.
  7. Enter the days of the week and the times of day to be allowed. For example:

    8. user = "anyone" and
    dayofweek = "sat,sun" or
    (timeofday >= 1800 and
    timeofday <= 600)

  8. Click Submit to save your changes. Any errors in the custom expression produce an error message. Make corrections and submit again.

Restricting Access Based on Security

You can configure SSL and non-SSL listen sockets for the same server instance. Restricting access based on security allows you to create protection for resources that should only be transmitted over a secure channel.

To restrict access based on security

Using the steps described for setting access control for a server instance (see Setting Access Control for a Server Instance), do the following:

  1. Access the Server Manager for the server instance.
  2. On the Preferences tab, click the Administer Access Control link.
  3. Select the entire server from the drop-down list in the Select A Resource section, and click Edit.
  4. Create a new rule allowing read and execute rights to all. This means that if a user wants to add, update, or delete a file or directory, this rule does not apply and the server searches for another rule that matches.
  5. Create another new rule denying write and delete rights to all.
  6. Click the X link to create a customized expression.
  7. Enter ssl="on". For example:

    8. user = "anyone" and ssl="on"

  8. Click Submit to save your changes. Any errors in the custom expression produce an error message. Make corrections and submit again.

Securing Access to Resources

This section describes the additional tasks you must perform to secure access control with Proxy Server, after enabling distributed administration.

This section contains the following topics.

Securing Access to Server Instances

To configure Proxy Server to control access to server instances, edit the server_root/httpacl/*.proxy-admserv.acl files to specify the user to whom you want to grant access control privileges. For example:

acl "proxy-server_instance";
authenticate (user,group) {
database = "default";
method = "basic";
};
deny absolute (all) user != "UserA";

Enabling IP-based Access Control

If the access control entry that refers to the ip attribute is located in the ACL files related to the Administration Server (gen*.proxy-admserv.acl), complete Steps 1 and 2 below.

If the access control entry that refers to the ip attribute is located in the ACL files related to a server instance, complete only Step 1 below for that particular ACL.

To enable IP-based access control
  1. Edit the server_root/httpacl/gen*.proxy-admserv.acl files to add ip to the authentication list, in addition to user and group, as shown below:

    2. acl "proxy-admserv";
    authenticate (user,group,ip) {
    database = "default";
    method = "basic";
    };

  2. Add the following access control entry:

    3. deny absolute (all) ip !="ip_for_which_access_is_allowed";

    For example:

    acl "proxy-admserv";
    authenticate (user,group,ip) {
    database = "default";
    method = "basic";
    };
    deny absolute (all) ip !="205.217.243.119";

Creating ACLs for File-based Authentication

Proxy Server supports the use of file-based authentication databases, which store user and group information in text format in flat files. The ACL framework is designed to work with the file authentication database.

Note

Proxy Server does not support dynamic flat files. The flat file database is loaded when the server starts up. Any changes to the files come into effect only when the server is restarted.

This section contains the following topics:

An ACL entry can reference a user database using the database keyword. For example:

acl "default";
  authenticate (user) {
...
  database="myfile";
...
};

The server_root/userdb/dbswitch.conf file contains an entry that defines the file authentication database and its configuration. For example:

directory myfiledb file
myfiledb:syntax keyfile
myfiledb:keyfile /path/to/config/keyfile

The following table lists the parameters supported by the file authentication database.

Table 8-2  Parameters Supported by the File Authentication Database

Parameter

Description

syntax

(Optional) Value is either keyfile or digest. If not specified, defaults to keyfile.

keyfile

(Required if syntax=keyfile) Path to the file containing user data.

digestfile

(Required if syntax=digest) Path to the file containing user data for Digest authentication.

Caution

The maximum length of a line in a file authentication database file is 255. If any line exceeds this limit, the server fails to start and an error is logged in the log file.

Note

Make sure a file-based authentication directory service is already configured before attempting to set ACLs using a file-based authentication database. For more information, see Configuring Directory Services.

Creating ACLs for Directory Services Based on File Authentication

To create ACLs for directory services based on file authentication
  1. Access the Server Manager for the server instance.
  2. On the Preferences tab, click the Administer Access Control link.
  3. Select the ACL file from the drop-down list, and click Edit.
  4. In the Access Control Rules For page, click the Users/Groups link for the ACL entry you want to edit. The User/Group page displays in the lower frame.
  5. From the drop-down list under Authentication Database, specify the key file database.
  6. Click Update, and then click Submit to save your changes.

When you set an ACL against a key file-based file authentication database, the dbswitch.conf file is updated with an ACL entry, such as the sample entry given below:

version 3.0;
acl "default";
authenticate (user) {
     prompt = "Sun Java System Proxy Server 4.0";
     database = "mykeyfile";
     method = "basic";
};
deny (all) user = "anyone";
allow (all) user = "all";

Creating ACLs for Directory Services Based on Digest Authentication

The file authentication database also supports a file format suitable for use with Digest authentication, per RFC 2617. A hash based on the password and realm is stored. Cleartext passwords are not maintained.

To create ACLs for directory services based on Digest authentication
  1. Access the Server Manager for the server instance.
  2. On the Preferences tab, click the Administer Access Control link.
  3. Select the ACL file from the drop-down list, and click Edit.
  4. In the Access Control Rules For page, click the Users/Groups link for the ACL you want to edit. The User/Group page displays in the lower frame.
  5. From the drop-down list under Authentication Database, specify the digest database.
  6. Click Update, and then click Submit to save your changes.

When you set an ACL against a Digest authentication-based file authentication database, the dbswitch.conf file is updated with an ACL entry, such as the sample entry given below:

version 3.0;
acl "default";
authenticate (user) {
     prompt = "filerealm";
     database = "mydigestfile";
     method = "digest";
};

deny (all) user = "anyone";
allow (all) user = "all";



Previous      Contents      Index      Next     

Part No: 819-3650-10.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.