Oracle iPlanet Web Server 7.0.9 Administrator's Guide

Working With the Authentication Database

The Authentication Database, also referred to as auth-db, represents a database of known users and the mechanism for authenticating client requests against that database. The server can have multiple auth-db entries configured at the same time and these may be of the same type. The auth-db user databases are used by the ACL processing module.

The server supports the following authentication databases:

LDAP — The user data is stored in an LDAP directory server, such as Oracle Directory Server Enterprise Edition.
File — The user data is stored in a disk file. This auth-db is particularly convenient for development or small deployments where no centralized user management is available (or desired). The file auth-db supports several different file formats:
1. keyfile — The keyfile format stores a list of users (and optional group memberships for each user). The password is stored as a one-way (unrecoverable) hash. This is the default format.
2. digestfile — The digestfile is very similar to the keyfile and also supports the HTTP Digest authentication method.
3. htaccess — The htaccess is a legacy format and should never be used for new installations or adding new users.
PAM — PAM is the new auth-db supported by Web Server 7.0.9. The PAM auth-db delegates the authentication to the Solaris PAM stack, this enables existing Solaris users on the web server system to authenticate to the web server as well.

Note –
PAM auth-db is only supported in Solaris 9 and 10 (or higher) and the web server instance must be running as root.

Kerberos- The gssapi authentication method works with a Kerberos user repository. Web Server 7.0 Update 7 release introduces a suitable auth-db of type Kerberos for use with the gssapi authentication method. The gssapi authentication can only be used with a Kerberos auth-db and vice versa. Compatible browsers (such as IE and Firefox) can authenticate using this method if the user running the browser has a valid Kerberos ticket. The protocol is described in the (now expired) IETF draft draft-brezak-spnego-http-04.txt.

The gssapi authentication method and the Kerberos auth-db are only supported in Solaris (the client browser may be on any Kerberos-enabled platform). The Kerberos auth-db is configured in server.xml as are all other auth-db elements:

<auth-db>
     <enabled>1</enabled>1>
     <name>my-kerberos</name>
     <url>kerberos</url>
</auth-db>

The default web server principal is "HTTP/hostname" where hostname is the server's hostname. The Kerberos auth-db supports two optional properties which can be used to modify this default:

servicename Default is HTTP

hostname Default is the hostname associated with the request.

For example, the configuration below is equivalent to not specifying servicename:

<auth-db>
      <enabled>1</enabled>
      <name>my-kerberos</name>
      <url>kerberos</url>
      <property>
      <name>servicename</name>
      <value>HTTP</value>
      </property>
</auth-db>

The above auth-db element can be added in GUI. To configure perform the following tasks:

1. Click the Edit Configuration link from Common Tasks Page

2. Click the created configuration.

3. Click the Access Control tab.

4. Under the Authentication Databases tab click New button.

5. Under the Database type Kerberos type will be visible. This option is visible only on Solaris platforms.

6. Enter the values and click on OK button to create auth-db of type Kerberos

In order to use the Kerberos authentication, the web server instance must have access to a Kerberos keytab file containing the key for this HTTP/hostname (or as given in the auth-db configuration) principal. Refer to the ktadd command of kadmin(1M) for information on creating this file. By default, the server expects to find a file named keytab in the config directory of the instance. This name and location can be changed with the optional <krb5-keytab-file> element in server.xml.

The following server.xml configuration is thus equivalent to omitting the <krb5-keytab-file> element (all file paths in server.xml are relative to the config directory of the instance):

<server>
  ...
<krb5-keytab-file>keytab</krb5-keytab-file>
...
</server>

The above needs to be manually added in server.xml if one needs to override the default location.

A sample ACL entry which instructs the server to require Kerberos authentication for the content under /krb5:

acl "uri=/krb5/";
authenticate (user) {
    method = "gssapi";
    database = "my-kerberos";
};
deny (all) user="anyone";
allow (all) user="all";

Creating an Authentication Database

FTo create an authentication database through the Administration Console, click Configurations > Configuration Name > Access Control > Authentication Databases > New button. Check out the Administration Console Inline help for field descriptions. Based on the selected Authentication Database, the fields change. For example, for PAM based Authentication DB, only the authentication DB name is required.

The options required to create an Authentication Database are enumerated here:

LDAP	Authentication Database Name Host Name Port Base DN
Key FIle	Authentication Database Name File Path
Digest File	Authentication Database Name File Path
PAM	Authentication Database Name
Kerberos	Authentication Database Name

To create an authentication database through CLI, execute the following command.

wadm> create-authdb --user=admin --password-file=admin.pwd 
--host=serverhost --port=8989 --config=config1 
--url=ldap://ldapserver.com:20002/dc=xxx,dc=sun,dc=com LDAP1

See CLI Reference, create-authdb(1).

In the previous example, a URL has been specified for the authentication database. The type of authentication database is specified in this URL scheme. For example, ldap://ds.example.come/dc=example,dc=com configures an LDAP directory server as an authentication database.