test

Oracle iPlanet Web Proxy Server 4.0.14 Administration Guide

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 just to 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 the following items:

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 provide 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 include the following:

User-Group authentication requires users to authenticate themselves before gaining access. With authentication, users verify their identity by providing 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 no setting in exists 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 provide a user name and password to access the server. Basic authentication is the default setting. You must create and store a list of users and groups in an LDAP database, such as the Oracle Directory Server Enterprise Edition, 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 provide 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).

Note –

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.

If the authentication is successful, the user sees the requested resource. If the user name or password is invalid, the system issues a message denying access.

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 performs the following actions:

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 actions must happen:

When you require client authentication with access control, SSL ciphers must be enabled for your Proxy Server. See Chapter 5, 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 compare only selected information from the certificate to the directory server entry. For example, you could configure certmap.conf to compare only the user ID and email address in the browser certificate with the directory server entry. For more information about certmap.conf and certificate mapping, see Chapter 5, Using Certificates and Keys. Also see Oracle iPlanet Web Proxy Server 4.0.14 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 clear text. The browser uses the MD5 algorithm to create a digest value using the users 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 clear text. Oracle Directory Server Enterprise Edition 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 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/.

Here is a sample dbswitch.conf file.


directory default ldap://<host_name>:<port>
default:binddn cn=Directory Manager
default:encoded bindpw ***********
default:digestauth on

or


directory default ldap://<host_name>:<port>/
default:binddn cn=Directory Manager
default:encoded bindpw ***********
default:digestauthstate on

The server tries to authenticate against the LDAP database based upon the ACL method specified, as shown in Digest Authentication. 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 performing the following actions:

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 value 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 and a ldif file:

ProcedureTo Install the Digest Authentication Plug-in on UNIX

Before You Begin

  1. To install the plug-in, type the command:

    % 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 Oracle Directory Server Enterprise Edition server computer for the Directory Server to start properly with the Digest plug-in.

ProcedureTo Install the Digest Authentication Plug-in on Windows

  1. Access the shared libraries in Proxy Server in server-root\bin\proxy\bin.

  2. Copy the files nsldap32v50.dll, libspnr4.dll, and libplds4.dll onto the appropriate directory:

  3. Paste them into either:

    • \Winnt\system32

      • The Oracle Directory Server Enterprise Edition install directory: server-root\bin\sldap\server

Setting Oracle Directory Server Enterprise Edition to Use the DES Algorithm

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

ProcedureTo Set Directory Server to Use the DES algorithm

  1. Launch the Directory Server Console.

  2. Open your Directory Server 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. Type iplanetReversiblePassword.

  8. Click Save.

  9. Set a Digest authentication password.

    Note –

    The server uses the iplanetReversiblePassword attribute which is in the object class iplanetReversiblePassword. To use a Digest authentication password in the iplanetReversiblePassword attribute for a user, your entry must include the iplanetReversiblePasswordobject object.

    This can be done using ldapmodify or using the Directory Server administration interface.

    Using ldapmodify —

    Create a file digest.ldif to store the LDAP commands. Adding the password is a two-step process.

    1. Add the object class to the digest.ldif.

      The file looks similar to the following (you can have more ldif files based on the Directory Server users and the ACL):


      dn:uid=user1,dc=india,dc=sun,dc=com
changetype:modify
add:objectclass
objectclass:iplanetReversiblePasswordobject

dn:uid=user1,dc=india,dc=india,dc=sun,dc=com
changetype:modify
add:iplanetReversiblePassword
iplanetReversiblePassword:user1

    2. # ldapmodify -D “cn={CN_Value}” -w <password> -a <ldif_file_name>

  10. Restart your Oracle Directory Server Enterprise Edition instance and verify that the user attributes are added to the Directory Server database.

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 might 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 set this limitation, 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 Chapter 18, ACL File Syntax. For more information about server.xml, see the Oracle iPlanet Web Proxy Server 4.0.14 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 through 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 might 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. Non-membership of a user in a group is not cached, which 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. 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.

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 set this mapping, you must specify that a client certificate is required to access a specified resource.