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:
An internal flat file-type database
An external LDAP database
When the server uses an external LDAP-based directory service, the following types of User-Group authentication methods are supported for server instances:
Default
Basic
SSL
Digest
Other
When the server uses an internal file-based directory service, the User-Group authentication methods supported for server instances include the following:
Default
Basic
Digest
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 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 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 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 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).
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.
The server can confirm users’ identities with security certificates in two ways:
Using the information in the client certificate as proof of identity
Verifying a client certificate published in an LDAP directory (additional)
When the server is configured to use certificate information for authenticating the client, the server performs the following actions:
Checks to determine whether the certificate is from a trusted CA (Certificate Authority). If not, the authentication fails and the transaction ends. To learn how to enable client authentication, see Setting Security Preferences.
Maps the certificate to a user’s entry using the certmap.conf file, if the certificate is from a trusted CA. To learn how to configure the certificate mapping file, see Using the certmap.conf File.
Checks the ACL rules specified for that user if the certificate maps correctly. Even if the certificate maps correctly, ACL rules can deny access to the user.
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:
The client must present a valid certificate issued by a trusted CA
The certificate must be mapped to a valid user in LDAP
The access control list must evaluate properly
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 Sun Java System Web Proxy Server 4.0.6 Configuration File Reference.
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. 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/.
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:
Checking for the Authorization request header. If the header is not found, a 401 response is generated with a Digest challenge, and the process stops.
Checking for the Authorization type. If the Authentication type is Digest, the server then performs the following actions:
Checks nonce. If the nonce is not a valid, fresh nonce generated by this server, a 401 response is generated, and the process stops. If the nonce is stale, a 401 response is generated with stale=true, and the process stops.
The time the nonce remains fresh can be configured by changing the value of the parameter DigestStaleTimeout in the magnus.conf file, located in server-root/proxy-server_name/config/. To set the value, add the following line to magnus.conf:
DigestStaleTimeout seconds
where seconds represents the number of seconds the nonce remains fresh. After the specified seconds elapse, the nonce expires and new authentication is required from the user.
Checks the realm. If the realm does not match, a 401 response is generated, and the process stops.
Checks the existence of the user in the LDAP directory if the authentication directory is LDAP-based, or checks existence of the user in the file database if the authentication directory is file-based. If the user is not found, a 401 response is generated, and the process stops.
Gets the request-digest value from the directory server or file database and checks for a match to the client’s request-digest. If no match is found, a 401 response is generated, and the process stops.
Constructs the Authorization-Info header and inserts this header into server headers.
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.
The Digest authentication plug-in consists of a shared library and a ldif file:
Make sure this shared library resides on the same server computer on which the Sun Java System Directory Server is installed.
Make sure you know the Directory Manager password.
Modify the libdigest-plugin.ldif file changing all references to /path/to to the location where you installed the digest plug-in shared library.
To install the plug-in, type the command:
% ldapmodify -D "cn=Directory Manager" -w password -a < libdigest-plugin.ldif
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.
Access the shared libraries in Proxy Server in server-root\bin\proxy\bin.
Copy the files nsldap32v50.dll, libspnr4.dll, and libplds4.dll onto the appropriate directory:
Paste them into either:
The DES algorithm is needed to encrypt the attribute where the digest password is stored.
Launch the Sun Java System Directory Server Console.
Open your Sun ONE Directory Server 5.1 SP1 (or later version) instance.
Select the Configuration tab.
Click the + sign next to plug-ins.
Select the DES plug-in.
Choose Add to add a new attribute.
Type iplanetReversiblePassword.
Click Save.
Set a Digest authentication password.
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.
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 |
# ldapmodify -D “cn={CN_Value}” -w <password> -a <ldif_file_name>
Restart your Sun Java System Directory Server instance and verify that the user attributes are added to the Directory Server database.
You can create a custom authentication method using the access control API.