Sun ONE logo      Previous      Contents      Index      Next     

Sun ONE Application Server 7 Administrator's Guide to Security

Chapter 5
Administering HTTP Server Access Control

This section provides information on the mechanisms and procedures used for controlling access to HTTP server resources.

Note

The content in this chapter cannot be applied to J2EE applications. For J2EE application development, refer to the J2EE security mechanisms as described in the J2EE specifications and the Sun ONE Application Server Developer’s Guide.

This section addresses the following topics:

About HTTP Server Access Control

Access control is the means of securing your Sun ONE Application Server by controlling who and what has access to it. For example, you can specify who has full control of all the servers installed on a machine and who has partial control of one or more servers.

Note

Before you can apply access control on the Admin Server set up an administration group. The instructions in this section assume you have already defined users and groups in your directory database.

Access is allowed or denied based on:

The security mechanisms that control access to your HTTP server include various authentication restrictions and ACL files.

This section addresses the following topics:

HTTP Server User-Group Authentication

User-Group authentication requires that users authenticate themselves before access can be granted. This is done by entering a user name and password, using a client certificate, or a using the digest authentication plug-in. The Sun ONE Application Server receives this information encrypted or unencrypted, depending on whether encryption is turned on for your server.

Note

In J2EE applications, user-group authentication is provided through realms (security domains). For information on developing realms for J2EE application security, refer to the Sun ONE Application Server Developer’s Guide.

The default authentication used is the default method you specify in the obj.conf file, or Basic authentication if there is no setting in the obj.conf file.

If you select Default as your authentication method, the ACL rule doesn’t specify a method in the ACL file. Choosing Default allows you to easily change the methods for all ACLs by editing one line in the obj.conf file.

Using the default is the preferred method.

There are three User-Group authentication methods, all of which require a directory server:

Basic Authentication

Basic authentication requires a user to enter a user name and password to access your Sun ONE Application Server or web site. You must first create and store a list of users and groups in an LDAP database, such as the Sun ONE Directory Server. The directory server must be installed on a different server root than your Sun ONE Application Server, or on a directory server installed on a remote machine.

Basic authentication is the default setting.

Note

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

SSL Authentication

SSL authentication requires that the Sun ONE Application Server confirm user identities using the users’ security certificates. This can happen in two ways:

When you set the server to use certificate information for authenticating the client, the Sun ONE Application Server does the following:

User-Group SSL Authentication

If you set the server’s access control to use the User-Group SSL authentication method, the following must be true:

Client SSL Authentication to Specific Resources

Requiring client authentication for controlling access to specific resources differs from requiring client authentication for all connections to the server. If you set the server to require client authentication for all connections, the client only needs to present a valid certificate issued by a trusted CA. To learn how to turn on client authentication, see "Setting Up Client Authentication"..

When you require client SSL authentication, you need to have SSL ciphers enabled for your server. Refer to "Enabling SSL and TLS" for further information.

To successfully gain access to an SSL-authenticated resource, the client certificate must be from a CA trusted by the server. The client certificate needs to be published in a directory server if the 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 the certmap.conf file to compare only the user ID and email address in the browser certificate with the directory server entry. To learn more about the certmap.conf file and certificate mapping, see "Working with the certmap.conf File".

Note

Only the User-Group SSL authentication method requires modifying the certmap.conf file (because the certificate is checked against the directory database); requiring client authentication for all connections to the server does not. If you choose to use client certificates, you should increase the value of the AcceptTimeout directive in the init.conf file.

Digest Authentication

Digest authentication allows the user 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. 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 needs access to the user's password in cleartext. The Sun ONE Directory Server includes a reversible password plug-in that uses a symmetric encryption algorithm to store data in an encrypted form. Later the data can be decrypted to its original form. Only the Sun ONE Directory Server holds the key to the data.

When processing an ACL with method=digest, the server attempts to authenticate using the following process:

The server tries to authenticate against the directory database based on the ACL method as specified in the following table.

Table 5-1  Digest Authentication Challenges

ACL Method
Configured

Authentication DB Supports Digest Authentication

Authentication DB Does Not Support Digest Authentication

Default
None specified

Digest and Basic

Basic

Basic

Basic

Basic

Digest

Digest

ERROR

For more information, refer to "Implementing Host-IP Authentication".

Host-IP Authentication

Host-IP access control is a method of limiting access to the Admin Server, or the files and directories on your web site by making them available only to clients using specific computers. You do this by specifying the hostnames or IP addresses for the computers that you want to allow or deny access to. You can use wildcard patterns to specify multiple computers or entire networks.

Host-IP authentication appears seamless to users, who can access the files and directories immediately without entering a user name or password. Further information can be found in "Implementing Host-IP Authentication".

Access Control List (ACL) Files

ACL files are text files that contain lists identifying who can access the resources stored on your Sun ONE Application Server. By creating a hierarchy of rules called access control entries (ACEs) you can allow or deny access to individuals, groups, or other entities such as particular servers or applications. Each ACE specifies whether or not the server should check the next ACE in the hierarchy. The collection of ACEs you create is called an access control list (ACL).

By default, the Sun ONE Application Server uses a single ACL file that contains all the lists for accessing your server. As an alternative to this default, you can create multiple ACL files and reference them in the obj.conf file.

When the Sun ONE Application Server receives a request for a page, the server uses the rules in the ACL file to determine if it should grant access or not. The rules can reference the hostname or IP address of the computer sending the request. The rules can also reference users and groups stored in an LDAP directory such as the Sun ONE Directory Server.

After determining which virtual server to use for an incoming request, the Sun ONE Application Server determines if any ACLs are configured for that virtual server. If ACLs are found that apply to the current request, the Sun ONE Application Server evaluates their ACEs to determine whether access should be allowed (granted) or denied (refused).

Information on using ACLs is contained in "Working With ACL Files".

Client Authentication

When client authentication is enabled, the client’s certificate is required before the server will send a response to a query. The Sun ONE Application Server supports authenticating client certificates by matching the CA in the client certificate with a CA trusted for signing client certificates.

When the Sun ONE Application Server receives a request from a client, it asks for the client’s certificate before proceeding. Some clients send the client certificate to the server along with the request.

Note

Before mapping client certificates to LDAP, you need to set up the required ACLs. More information on access control can be found in "Working With ACL Files".

  1. The Sun ONE Application Server tries to match the CA to the list of trusted CAs in the Admin Server.

    2. If there isn’t a match, the Sun ONE Application Server ends the connection.

  2. If there is a match, the server continues processing the request.
  3. After verifying the certificate is from a trusted CA, the server maps the certificate to an LDAP entry by:
    • Mapping the issuer and subject DN from the client certificate to a branch point in the LDAP directory.
    • Searching the LDAP directory for an entry that matches the information about the subject (end-user) of the client certificate.

      • The server uses a certificate mapping file called certmap.conf to determine how to do the LDAP search. The mapping file tells the server what values to take from the client certificate (such as the user’s name, email address, and so on). The server uses these values to search for a user entry in the LDAP directory, but first the server needs to determine where in the LDAP directory it needs to start its search. The certificate mapping file tells the server where to start.

    • (Optional) Verifying the client certificate with one in the LDAP entry that corresponds to the DN.
  4. Once the server knows where to start its search and what it needs to search for, it performs the search in the LDAP directory. If it finds no matching entry or more than one matching entry, and the mapping is not set to verify the certificate, the search fails.

    5. You can specify the expected behavior in the ACL. For example, you can specify that Sun ONE Application Server accepts only you if the certificate match fails. For more information regarding how to set the ACL preferences, see .

  5. After the server finds a matching entry and certificate in the LDAP directory, it can use that information to process the transaction. For example, some servers use certificate-to-LDAP mapping to determine access to a server.

Information on implementation is contained in "Setting Up Client Authentication".

Implementing Digest Authentication

If you are unfamiliar with how Digest authentication works, refer to "Digest Authentication".

For Digest authentication, you need to enable the reversible password plug-in and the digestauth-specific plug-in included with the Sun ONE Application Server. To configure your server to process Digest authentication, you will need to set the digestauth property of the database definition in the dbswitch.conf file.

The tasks required for implementing User-Group Digest authentication are addressed in the following sections:

Installing the Digest Authentication Plug-in

The Digest authentication plug-in consists of a shared library found in both libdigest-plugin.lib and libdigest-plugin.ldif.

Digest Authentication on UNIX

To install the Digest authentication plug-in on UNIX, perform the following steps:

  1. Make sure this shared library resides on the same server machine that the Sun ONE Directory Server is installed on.
  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 following command:

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

Digest Authentication on Windows

To install the Digest authentication plug-in on Windows, perform the following steps:

Note

You will need to copy several .dll files from the Sun ONE Application Server installation to your Sun ONE Directory Server machine in order for the Sun ONE Directory Server to start properly with the Digest plug-in.

  1. Access the shared libraries in the Sun ONE Application Server installation in:

    2. install_dir\bin

  2. Copy the files:
    • nsldap32v50.dll
    • libnspr4.dll
    • libplds4.dll
  3. Paste them into either:
    • \Winnt\system32
    • Sun ONE Directory Server installation directory: [server_root]\bin\sldap\server

Setting the Sun ONE 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 Sun ONE Directory Server to use the DES algorithm, perform the following steps:

  1. Launch the Sun ONE Directory Server Console.
  2. Open your Sun ONE Directory Server instance.
  3. Select the Configuration tab.
  4. Click the + sign next to plug-ins.
  5. Select the DES plug-in.
  6. To add a new attribute, choose Add.
  7. Enter iplanetReversiblePassword.
  8. Click Save.
  9. Stop and start the server for changes to take effect.

    10. .

    Note

    In order to set a digest authentication password in the iplanetReversiblePassword attribute for a user, your entry must include the iplanetReversiblePasswordobject object.

Implementing Host-IP Authentication

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

Host-IP authentication does not require DNS to be configured on your Sun ONE Application Server, but you must have DNS running in your network and your Sun ONE Application Server must be configured to use it.

Note

You can enable DNS on the HTTP Server->Tuning page of the Administration interface.

Enabling DNS degrades the performance of the Sun ONE Application Server because the server is required to do DNS look-ups. To reduce the impact of DNS look-ups on your Sun ONE Application Server performance, resolve IP addresses only for access control and CGI instead of resolving IP addresses for every request. To minimize DNS impact, append iponly=1 to AddLog fn="flex-log" name="access" in your obj.conf file:

Working With ACL Files

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

Access control files are stored in the directory instance_dir/config where instance_dir is the name of the instance. For example, the access control files for the initial server instance are stored in the install_dir/domains/domain1/server1/config directory.

The following topics are addressed in this section:

ACL File Syntax

ACL files must follow a specific format and syntax. A typical ACL definition in the ACL list is made up of a number of statements about type, the authentication method, and the authorization method.

A snippet from an ACL file might look like this:

version 3.0;
# The "default" rules apply to the entire document
  acl "default";
  authenticate (user,group) {
  database = "default";
  method = "basic";
  };
  deny (all)
  user = "anyone");
  allow (read,execute,list,info)
  (user = "all");
  };

The components of this snippet include:

Input strings can contain the following characters:

If you use any other characters, you must use double quotation marks (“) around the characters.

Type Statement

Each ACL definition in the file contains a statement that identifies what type of ACL it is. This type can be one of the following:

A type line begins with the letters acl, followed by the type information in double quotation marks, ended by a semicolon. The type information for each ACL must be a unique name—even among different ACL files. The following lines are examples of several different types of ACLs:

Path and URI ACLs can include wildcards at the end of the entry. For example: /a/b/*. Wildcards placed anywhere except at the end of the entry will not work.

Authentication Statement

Optionally, ACLs can specify the authentication method the Sun ONE Application Server must use when processing the ACL. There are three general methods:

Each authentication statement specifies what attributes (users, groups, or both users and groups) the Sun ONE Application Server must authenticate.

Examples

Specifies Basic authentication with users matched to individual users in the database or directory:

  authenticate (user) {
    method = "basic"; 
  };

Specifies the User-Group SSL authentication method:

  authenticate (user, group) {
    method = "ssl"; 
  };

Allows access to any user whose user name begins with the letters sales:

  authenticate (user) {
  allow (all)
    user = sales*
  };

Authorization Statement

An authorization statement specifies who is allowed or denied access to a server resource. Each ACL entry can include one or more authorization statements. Use the following syntax when writing authorization statements:

Each line starts with the keyword allow or deny.

Because of the hierarchy of rules, it is usually a good idea to deny access to everyone in the top-level rule, then specifically allow access for users, groups, or computers in subsequent rules.

Scenario

If you allow full access to a directory called /my_stuff, then you want a subdirectory called /my_stuff/personal that will allow access to only a few users, the access control on the subdirectory won’t work—everyone allowed access to the /my_stuff directory will also be allowed access to the /my_stuff/personal directory. To prevent this, first create a rule for /my_stuff/personal that denies access to everyone, then allow access for the few users you specify.

Note

In some cases, if you set the default ACL to deny access to everyone, then your other ACL rules won’t need a deny all rule.

The following authorization statement denies access to everyone:

  deny (all)
    user = "anyone";

The following sections are association with authorization statements:

Hierarchy of Authorization Statements

ACLs have a hierarchy based on the resource. For example, if the Sun ONE Application Server receives a request for the document (URI)
/my_stuff/web/presentation.html, the server builds a list of ACLs that apply for this URI.

All statements are evaluated in order, unless absolute ACL statements are present. If an absolute allow or absolute deny statement evaluates to true, the server stops processing and accepts this result.

If there are multiple ACLs that match, the Sun ONE Application Server uses the last statement that matches. However, if you use an absolute statement, the server stops looking for other matches and uses the ACL containing the absolute statement. If you have two absolute statements for the same resource, the Sun ONE Application Server uses the first one in the file and stops looking for other resources that match.

The following example stops searching when it reaches the absolute "joe", even if there might be additional users named joe:

version 3.0;
acl "default";
authenticate (user,group) {
  prompt="Sun ONE Application Server";
};
allow (read,execute,list,info)
  user = "anyone";
allow (write,delete)
  user = "all";
acl "uri=/my_stuff/web/presentation.html";
deny (all)
  user = "anyone";
allow (all)
  user = "joe";

Attribute Expressions

An attribute expression defines who is allowed or denied access based on their user name, group name, host name, or IP address. The following are examples of how access is given to different people or computers:

You can also restrict access to your server by time of day (based on the local time on the server) using the timeofday attribute. Refer to "Restricting Access Based on Time of Day" for additional information.

For example, the timeofday attribute can restrict access to certain users during specific hours.

Note

Use 24-hour time to specify times. For example, use 0400 to specify 4:00 a.m. or 2230 for 10:30 p.m.

Example

Restricts access to a group of users called guests between 8:00 a.m. and 4:59 p.m:

  allow (read
    (group="guests") and 
    (timeofday<0800 or timeofday=1700);

You can also restrict access by day of the week using the dayofweek attribute with the following three-letter abbreviations to specify days of the week: Sun, Mon, Tue, Wed, Thu, Fri, Sat.

Example

Allows access for users in the premium group any day and any time. Users in the discount group get access all day on weekends and on weekdays anytime except 8am-4:59pm.

Operators

You can use various operators in attribute expressions. Parentheses delineate the operator order of precedence. With user, group, DNS, and IP, you can use the following operators:

With the timeofday and dayofweek attributes, you can use:

Sample ACL File

The following sample ACL file contains the two default entries for the Admin Server (admin-server), plus an additional entry that allows users in the admin-reduced group to access the Admin Server.

 

version 3.0;

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

# as icons and images related to Sun ONE Application 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 "default" rules apply to the entire document

# directory of Sun ONE Application Server. In this example, the rules

# are set up so that "all" users in the directory server are

# allowed to read, execute, list, and get information.

# The "all" users are not allowed to write to or delete any files.

# All clients that accesses the document directory of the web

# server will be required to submit a username and password

# since this example is using the "basic" method of

# authentication. A client must be in the directory server

# to gain access to this default directory since "anyone"

# not in the directory server is denied, and "all" in the

# directory server are allowed.

  acl "default";

  authenticate (user,group) {

     database = "default";

     method = "basic";

  };

  deny (all)

  (user = "anyone");

  allow (read,execute,list,info)

  (user = "all");

# 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 can not gain access to the

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

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

# of GroupB can not 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

# user 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; it has been added to 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");

 

Example

If a user requests: http://server_name/my_stuff/web/presentation.html, the Sun ONE Application Server first checks access control for the entire server. If the ACL for the entire server was set to continue, the server would check for an ACL for the directory my_stuff. If an ACL exists, the server checks the ACEs within the ACL, 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.

Writing Customized ACL Expressions

You can enter custom expressions for an ACL. There are a few features that are available only by editing the ACL file or by creating custom expressions. For example, you can restrict access to your server depending on the time of day, day of the week, or both.

Note

Only select this option if you are familiar with the syntax and structure of ACL files.

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 is allowed access Monday through Friday, 8:00am to 5:00pm. The critical group is allowed 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)
}

Setting Up Client Authentication

Note

Certificate expired—If the certificate has expired, the Sun ONE Application Server logs an error, rejects the certificate, and returns a message to the client. You can view which certificates have expired in the Admin Server Manage Certificates page.

You can set up client authentication for the Admin Server or for a server instance.Instructions are contained in the following sections:

Setting Client Authentication for the Admin Server

To set up client authentication at the Admin Server level:

  1. Access the Admin Server and select the HTTP Listener tab in the right pane.

    2. The Admin Server HTTP Listener page is displayed.

    Figure 5-1  HTTP Listener Page for the Admin Server
    This screen capture shows the HTTP Listeners setup page for the Admin Server.

  2. Click SSL/TLS Enabled to turn security on (default is off).
  3. Click Client Authentication Enabled to turn client authentication on (default is off).
  4. Click Save.
  5. Select the Control tab on the right pane and click Apply Changes.

    6. Figure 5-2  Admin Server Control Page
    This screen capture shows the Admin Server Control page. Click Apply Changes for any Admin Server-wide changes.

  6. Stop and start the server for changes to take effect.

    7. To start the Admin Server, go to install_dir/domains/domain1/admin-server/bin/startserv

Setting Client Authentication for a Server Instance

To set up client authentication at the Server Instance level:

  1. Access the App Server Instance and select the server instance in the left pane.
  2. Expand HTTP Server in the left pane and click HTTP Listeners.

    3. The HTTP Listener page is displayed, listing the listener instances.

  3. Select the instance you want.

    4. The HTTP Listener page for that instance is displayed.

    Figure 5-3  HTTP Listeners for an App Server Instance Page
    This screen capture shows the HTTP Listeners setup page for a server instance.

  4. Click the SSL/TLS Enabled checkbox to turn security on (default is off).
  5. Click the Client Authentication Enabled checkbox to turn it on (default is off).
  6. Click Save.
  7. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  8. Stop and start the server for changes to take effect.

    9. .

    Note

    There is a single certificate trust database per Sun ONE Application Server instance. All the secure virtual servers running under that server instance share the same list of trusted client CAs. If two virtual servers require different trusted CAs, these virtual servers should be run in different server instances with separate trust databases.

Working with the certmap.conf File

Certificate mapping is the mechanism by which a server looks up a user entry in the LDAP directory. You can use the certmap.conf file to configure how a certificate, designated by name, is mapped to an LDAP entry. You edit this file and add entries to match the organization of your LDAP directory and to list the certificates you want your users to have. Users can be authenticated based on user ID, email, or any other value used in the subjectDN. Specifically, the mapping file provides the following information:

The certificate mapping file is located here:

The file contains one or more named mappings, each applying to a different CA. A mapping has the following syntax:

The first line specifies a name for the entry and the attributes that form the DN found in the CA certificate. The name is arbitrary; you can define it to be whatever you want. However, issuerDN must exactly match the issuer DN of the CA who issued the client certificate. For example, the following two issuerDN lines differ only in the spaces separating the attributes, but the server treats these two entries as different:

The following topics address the certmap.conf file:

Default Properties

The second and subsequent lines in the named mapping match properties with values. The certmap.conf file has six default properties (you can use the certificate API to customize your own properties):

For more information on these properties, refer to the examples described in .

Creating Custom Properties

You can use the client certificate API to create your own properties. For information on programming and using the client certificate API, see the Sun ONE Application Server Developer’s Guide to NSAPI.

Once you have a custom mapping, reference the mapping as follows:

<name>:library <path_to_shared_library>
<name>:InitFn <name_of_init_function

For example:

Sample Mappings

The certmap.conf file should have at least one entry. The following examples illustrate the different ways you can use the certmap.conf file.

Example 1

This example represents a certmap.conf file with only one default mapping:

Using this example, the server starts its search at the LDAP branch point containing the entry ou=<orgunit>, o=<org>, c=<country> where the text in <> is replaced with the values from the subject’s DN in the client certificate.

The server then uses the values for the email address and user ID from the certificate to search for a match in the LDAP directory. When it finds an entry, the server verifies the certificate by comparing the one the client sent to the one stored in the directory.

Example 2

This example file has two mappings, one for default and another for the US Postal Service:

When the server gets a certificate from anyone other than the US Postal Service, it uses the default mapping, which starts at the top of the LDAP tree and searches for an entry matching the client’s email and user ID. If the certificate is from the US Postal Service, the server starts its search at the LDAP branch containing the organizational unit and searches for matching email addresses. If the certificate is from the USPS, the server verifies the certificate; other certificates are not verified.

Caution

The issuer DN (that is, the CA’s information) in the certificate must be identical to the issuer DN listed in the first line of the mapping. In the previous example, a certificate from an issuer DN that is o=United States Postal Service,c=US won’t match because there isn’t a space between the o and the c attributes.

Example 3

The following example uses the CmapLdapAttr property to search the LDAP database for an attribute called certSubjectDN whose value exactly matches the entire subject DN taken from the client certificate.

If the client certificate subject is:

the server first searches for entries that contain the following information:

If one or more matching entries are found, the server proceeds to verify the entries. If no matching entries are found, the server uses DNComps and FilterComps to search for matching entries.

In this example, the server would search for uid=Walt Whitman in all entries under o=LeavesOfGrass Inc, c=US.

Note

This example assumes the LDAP directory contains entries with the attribute certSubjectDN.

ACL/ACE Settings

The following topics are addressed in this section:

Setting to Allow or Deny

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

The server goes through the list of ACEs to determine access permission. For example, the first ACE is usually to deny access to everyone. If continue is not checked, everyone is denied access to the resource.

If the first ACE is set to continue, the server checks the second ACE in the list, and if it matches, goes to the next ACE. The server continues down the list until it reaches either an ACE that doesn’t match, or an ACE that matches but is set to not continue. The last matching ACE determines if access is allowed or denied.

Setting for User-Group Authentication

With User-Group authentication, users are prompted to enter a user name and password before they can access the resource specified in the access control rule. The Sun ONE Application Server checks the lists of users and groups stored in your LDAP server.

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.

Specifying the From Host

You can restrict access to the Admin Server or your web site based on which computer the request comes from.

If you select the Only from option, enter a wildcard pattern or a comma-separated list in the Host Names or IP Addresses fields. Restricting by hostname is more flexible than by IP address: if a user’s IP address changes, you won’t need to update this list. Restricting by IP address, however, is more reliable: if a DNS lookup fails for a connected client, hostname 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 *.sun.com. You can set different hostnames and IP addresses for superusers accessing the Admin Server.

For more information, refer to "Implementing Host-IP Authentication".

Note

For hostnames, the * must replace an entire component of the name. For example, *.sun.com is acceptable, but *users.sun.com is not. When the * appears in a hostname, it must be the leftmost character. For example, *.sun.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 * appears in an IP address, it must be the right-most character. For example, 198.* is acceptable, but not 198.*.251.30.

Setting Access Rights

Access rights restrict access to files and directories on your web site. In addition to allowing or denying all access rights, you can specify a rule that allows or denies partial access rights. For example, you can allow users read-only access to your files, so they can view the information, but deny them write access, so they cannot change the files.

Referencing ACL Files in the obj.conf File

If you have named ACLs or created separate ACL files, you can reference them in the obj.conf file. Do this in the PathCheck directive using the check-acl function. The line has the following syntax:

The aclname is the unique name of an ACL as it appears in any ACL file.

For example, you might add the following lines to your obj.conf file if you want to restrict access to a directory using the ACL named testacl:

In the previous example, the first line is the object that states which server resource you want to restrict access to. The second line is the PathCheck directive that uses the check-acl function to bind the ACL name (testacl) to the object in which the directive appears.

The testacl ACL can appear in any ACL file referenced in the init.conf file.

Configuring the ACL User Cache

By default, the Sun ONE Application Server caches user and group authentication results in the ACL user cache. This section describes the ACL user cache directives that are contained in the init.conf file:

ACLCacheLifetime

ACLCacheLifetime determines the number of seconds before cache entries expire. 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. If this value is set to 0, the cache is turned off.

If you use a large number for this value, you may need to restart the Sun ONE Application Server when you make changes to the LDAP entries. For example, if this value is set to 120 seconds, the Sun ONE Application Server might be out of sync with the LDAP server for as long as two minutes. If your LDAP is not likely to change often, use a large number. Default value is 120.

ACLUserCacheSize

ACLUserCacheSize determines the number of users in the User Cache. New entries are added to the head of the list; entries at the end of this list are recycled to make new entries when the cache reaches its maximum size.

Default value is 200.

ACLGroupCacheSize

ACLGroupCacheSize determines how many group IDs can be cached for a single UID/cache entry. Unfortunately non-membership of a user in a group is not cached, and will result in several LDAP directory accesses on every request. Default value is 4.

For more information on ACL file directives, see the Sun ONE Application Server Administrator’s Configuration File Reference.

Setting Access Control for a Server Instance

You can create, edit, or delete access control for a specific server instance.

Note

If deleting, you should not delete all the 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 create access control for a server instance, perform the following steps:

  1. Access App Server Instance and HTTP Server.
  2. Select ACLs.

    3. The ACLs page displays the existing ACLs.

  3. Click the ACL File to edit.

    4. The Edit ACL file page is displayed.

    Figure 5-4  ACL File Page
    This screen capture shows the ACL file you have selected.

  4. Click the Edit ACL File button.

    5. The Access Control List Management page is displayed.

    Figure 5-5  ACL List Management Page
    This screen capture shows options for editing an ACL file.

  5. Under the Option column choose one:
    • Add and enter the ACL file location.
    • Edit and select the ACL file from the drop-down menu.
    • Delete from the drop-down menu and select the ACL file.

      • The Access Control List Management page offers three options.

  6. Select one of the following:
    • Pick a resource—To specify a wildcard pattern for files or directories (such as *.html), choose a directory or a file name to restrict, or browse for a file or directory.
    • Pick an existing ACL—To select from a list of all the ACLs you have enabled. Existing ACLs you have not enabled will not appear in this list.
    • Type in the ACL name—To specify the named ACL.

      • Note

      Use this option only if you’re familiar with ACL files. You’ll need to manually edit the obj.conf file if you want to apply named ACLs to resources.

      The following table lists the resource wildcards you can use. The left column lists the resource wildcard and the right column describes its functionality.

      Table 5-3  Server Resource Wildcards 

      Resource wildcard

      What it means

      Default

      A named ACL created during installation that restricts write access so only users in the LDAP directory can publish documents.

      Entire server

      One set of rules determines the access to your entire web site, including any virtual servers you have running. To restrict access to a virtual server, specify the path of its document root.

      /usr/Sun/server4/docs/cgi-bin/*

      Controls access to all files and directories in the cgi-bin directory. You must specify an absolute path. On Windows, the path must include the drive letter.

      uri=“/sales”

      Controls access to the sales directory in the document root. To specify URIs, create a named ACL.

  7. Click Edit Access Control.

    8. The Access Control Rules for: (server instance) appears.

    Figure 5-6  Access Control Rules
    This screen capture shows the ACL rules.

  8. Verify Access control is on, if not already selected.
  9. To create or edit the ACL for this server instance, click Deny in the Action column.
  10. Select Allow, if it isn’t already selected as the default, and click Update.
  11. Click anyone in the Users/Groups column.

    12. The User/Group page appears.

    Figure 5-7  Access Control User/Group Rules
    This screen capture shows the ACL User/Group rules.

  12. Select which users and groups you will allow access to, and click Update.

    13. Clicking List for Group and User will provide lists for you to choose from.

  13. Click anyplace in the From Host column.

    14. Figure 5-8  Access Control From Host Rules
    This screen capture shows the ACL From Host rules.

  14. Enter Host Names and IP Addresses allowed access, and click Update.
  15. Click on all in the Rights column.

    16. Figure 5-9  Access Control Rights Rules
    This screen capture shows the ACL access rights rules.

  16. Select one of the following and then click Update:
    • All Access Rights
    • Only the following rights and check all appropriate rights for this user
  17. (Optional) Click the x under the Extra column to add a customized ACL expression.
  18. Put a check in the Continue column, if it isn’t already selected as the default.

    19. The server will evaluate 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 ones.

  19. (Optional) Click Response when denied.
    • Respond with the default file (redirection off)
    • Respond with the following URL or URI: (redirection on)
  20. Enter the path to the absolute URL or a relative URI and click update.
  21. Click Submit to store the new access control rules in the ACL file.

    22. Note

    Clicking Revert will remove all of the settings you’ve just created.

  22. Repeat all steps above for each server instance you want to establish access control for.
  23. When finished, click Apply.
  24. Click OK.
  25. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  26. Stop and start the server for changes to take effect.

ACL settings can also be enabled on a per virtual server basis. To learn how this is done, see "Editing Access Control Lists for Virtual Servers".

Restricting Access to Areas of Your Server

After you have completed the steps described in "Setting Access Control for a Server Instance", you can take additional measures to restrict areas of your server as described in 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 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), perform the following steps:

  1. Access App Server Instance and HTTP Server.
  2. Select ACLs.

    3. The ACLs page displays the existing ACLs.

  3. Click the ACL File to edit.
  4. Click the Edit ACL File button.

    5. The Access Control List Management page is displayed.

  5. Pick the entire server resource, and click Edit Access Control.
  6. Add a new rule to deny access to all.
  7. Add another new rule to allow access to a specific group.
  8. Enter a wildcard pattern for the host names of the computers to be allowed.

    9. For example, *.employee.sun.com

  9. Unselect Continue.
  10. Click OK.
  11. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  12. Stop and start the server for changes to take effect.

Restricting Access to a Directory (Path)

You can allow users in a group to read or run applications in directories, and its 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 a directory on the server (using the steps described for setting access control for a server instance), perform the following steps:

  1. Access App Server Instance and HTTP Server.
  2. Select ACLs.

    3. The ACLs page displays the existing ACLs.

  3. Click the ACL file to edit.
  4. Click the Edit ACL File button.

    5. The Access Control List Management page is displayed.

  5. Browse the Pick a Resource section and select the directory you want to restrict.

    6. The directories in the server’s document root are displayed. Once selected, the Editing drop-down list displays the absolute path to the directory.

    Note

    If you want to view all files in your server root, click Options, then check List files as well as directories.

  6. Click Edit Access Control.
  7. Create a new rule and leave the defaults to deny access to everyone from everywhere.
  8. Create another new rule allowing users in a specific group to have read and execute rights only.
  9. Create a third line to allow a specific user to have all rights.
  10. Unselect Continue for the second and third lines and click Update.
  11. Click OK.
  12. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  13. Stop and start the server for changes to take effect.

An absolute path to the file or directory is created in the docroot directory. An entry similar to the following would appear in the ACL file: acl “path=d:/Sun/suitespot/docroot1/sales/”;

Restricting Access to a URI (Path)

You can use a URI to control access to a single user’s content on the server. URIs are paths and files relative to the server’s document root directory. Using URIs is an easy way to manage your server’s content if you frequently rename or move all or part of it (for example, for disk space). It’s also a good way to handle access control if you have additional document roots.

To limit access to a URI (using the steps described for setting access control for a server instance), perform the following steps:

  1. Access App Server Instance and HTTP Server.
  2. Select ACLs.

    3. The ACLs page displays the existing ACLs.

  3. Click the ACL file to edit.
  4. Click the Edit ACL File button.

    5. The Access Control List Management page is displayed.

  5. Enter the URI you want to restrict in the Type in the ACL name section.

    6. For example: uri=/my_directory.

  6. Click Edit Access Control.
  7. Create a new rule to allows all users read access.
  8. Create another new rule to allow access for the owner of the directory.
  9. Uncheck Continue for both the first and second rules.
  10. Click OK.
  11. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  12. Stop and start the server for changes to take effect.

A path for the URI is created relative to the document root. The entry in the ACL file would appear as follows: acl “uri=/my_directory”;

Restricting Access to a File Type

You can limit access to file types on your server or web site. 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 limit access to a file type (using the steps described for setting access control for a server instance), perform the following steps:

  1. Access App Server Instance and HTTP Server.
  2. Select ACLs.

    3. The ACLs page displays the existing ACLs.

  3. Click the ACL file to edit.
  4. Click the Edit ACL File button.

    5. The Access Control List Management page is displayed.

  5. Click Wildcard in the Pick a resource section and enter a wildcard pattern.

    6. For example, *.cgi.

  6. Click Edit Access Control.
  7. Create a new rule to allow read access to all users.
  8. Create another rule that allows write and delete access only to a specified group.
  9. Click OK.
  10. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  11. Stop and start the server for changes to take effect.

For file type restriction, you would leave both continue boxes checked. If a request for a file comes in, the server will then check the ACL for the file type first.

A Pathcheck function is created in the obj.conf file 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 or during specified hours or on specified days. You might use this to prevent people from publishing documents during working hours when people might be accessing the files.

To limit access based on time of day (using the steps described for setting access control for a server instance), perform the following steps:

  1. Access App Server Instance and HTTP Server.
  2. Select ACLs.

    3. The ACLs page displays the existing ACLs.

  3. Click the ACL file to edit.
  4. Click the Edit ACL File button.

    5. The Access Control List Management page is displayed.

  5. Select the entire server from the drop-down list in Pick a Resource and click Edit Access Control.
  6. Create a new rule allowing read and execute rights to all.

    7. This means that if a user wants to add, update, or delete a file or directory, this rule won’t apply and the server will search for another rule that matches.

  7. Create another new rule denying write and delete rights to all.
  8. Click X link to create a customized expression.
  9. Enter the days of the week and the times of day to be allowed. For example:

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

    The Unrecognized Expressions message will be displayed in the Users/Groups and From Host fields when you create a custom expression.

  10. Click OK.
  11. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  12. Stop and start the server for changes to take effect.

Any errors in the custom expression will generate an error message. Make corrections and submit again.

Restricting Access Based on Security

You can configure SSL and non-SSL HTTP Listeners 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 limit access based on security (using the steps described for setting access control for a server instance), perform the following steps:

  1. Access App Server Instance and HTTP Server.
  2. Select ACLs.

    3. The ACLs page displays the existing ACLs.

  3. Click the ACL file to edit.
  4. Click the Edit ACL File button.

    5. The Access Control List Management page is displayed.

  5. Select the entire server from the drop-down list in Pick a Resource and click Edit Access Control.
  6. Create a new rule allowing read and execute rights to all.

    7. This means that if a user wants to add, update, or delete a file or directory, this rule won’t apply and the server will search for another rule that matches.

  7. Create another new rule denying write and delete rights to all.
  8. Click X link to create a customized expression.
  9. Enter ssl="on". For example:

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

  10. Click OK.
  11. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  12. Stop and start the server for changes to take effect.

Any errors in the custom expression will generate an error message. Make corrections and submit again.

Turning Off Access Control

When you uncheck the option labeled Access Control Is On, you’ll receive a prompt asking if you want to erase records in the ACL. When you click OK, the server deletes the ACL entry for that resource from the ACL file.

If you want to deactivate an ACL, you can comment out the ACL lines in the generated-server-id.acl file by putting a # sign at the beginning of each line.

Note

This access control is in addition to the user being in the administrators group. The Admin Server first verifies that a user (other than superuser) is in the administrators group, then evaluates the access control rules.

Responding When Access is Denied

The Sun ONE Application Server provides the following default message when access is denied:

FORBIDDEN. Your client is not allowed access to the restricted object.

You can choose a different response, or you can create a different message for each access control object.

To change the message sent for a particular ACL, perform the following steps:

  1. In the ACL page, click the Response when denied link
  2. In the lower frame, check Respond with the following file.
  3. Enter the path to the absolute URL or a relative URI and click update.

    4. Make sure users have access to the URL or URI they are redirected to.

  4. Click Update.
  5. Click Submit in the top frame to submit the access control rule.
  6. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  7. Stop and start the server for changes to take effect.

Controlling Access for Virtual Servers

Access control information in Sun ONE Application Server can come from a per-virtual server ACL file and htaccess files in the document directories.

Your server.xml file can contain one or more acl tags which define an ID associated to a particular standard ACL file. For example:

  <acl id="standard" file="standard.acl">

For virtual servers to use access control, you must create a reference to one or more ACL file IDs in their acls attribute. Example:

This configuration allows multiple virtual servers to share the same ACL file. If you want to require user-group authentication for a virtual server, you must add one or more auth-db tags to its definition. These auth-db tags create a connection between the database names in your ACL file and the actual databases found in dbswitch.conf.

The following example maps the ACLs with no ‘database’ attribute to the ‘default’ database in dbswitch.conf file.

  <virtual-server>
    <auth-db id="default" database="default"/>
  </virtual-server>

The following topics address virtual server access:

Accessing Databases from Virtual Servers

You can globally define user authentication databases in the dbswitch.conf file, which is only read at server startup. The baseDN of the LDAP URL in the dbswitch.conf file defines the global root of all accesses to the database. This maintains backward compatibility. For most new installations, the baseDN is empty. You can also use the Administration interface to set up authentication databases for your virtual servers.

Note

When you use the App Server Instance->Security->Configure Directory Service page in Administration interface to configure the directory, the dbswitch.conf file is updated.

The following sections provide instructions:

Using the dbswitch.conf File

The dcsuffix attribute for LDAP databases in dbswitch.conf defines the root of the DC tree according to the Sun ONE Directory Server schema. It is relative to the baseDN in the LDAP URL. When the dcsuffix attribute is present, the LDAP database is Sun ONE Directory Server schema compliant, and the behavior of some operations changes. For more information about the Sun ONE Directory Server schema, and an example, see the Sun ONE Application Server Developer’s Guide to NSAPI.

For every virtual server, you can define one or more auth-db blocks that point to one of the directories, and you can define additional information. The auth-db blocks ID can be referenced in the database parameter of the ACL. If a virtual server has no auth-db blocks, user or group-based ACLs will fail.

auth-db tags define an additional layer of indirection between the database attribute of an ACL and the dbswitch.conf file. This layer of indirection adds the necessary protection for the server administrator to have full control over which databases the virtual server administrators have access to.

For more information on auth-db, see the Sun ONE Application Server Developer’s Guide to NSAPI.

Creating a New Authentication Database

To create a new authentication database in the Administration interface, perform the following steps:

  1. Access App Server Instances and HTTP Server in the left pane.
  2. Access Virtual Servers and open the virtual server you want (expand the node).
  3. Under the virtual server in the left pane, click Authentication Databases.

    4. The Authentication Databases page lists the current databases.

  4. To create a new authentication database, click New.

    5. The Authentication Databases New page is displayed.

  5. Enter the information as described in the online help.
  6. Click OK.
  7. Access App Server Instances and your server instance in the left pane, and click Apply Changes.
  8. Stop and start the server for changes to take effect.

Specifying Databases in the User Interface

After you have created one or more user authentication databases in the dbswitch.conf file, or using the Administration interface, you can use the Administration interface to configure which databases each of your virtual servers will use for authentication. You can also use the Administration interface to add a newly-created database definition from the dbswitch.conf file for the virtual server to authenticate against. This is done by associating the newly-created authentication database with an ACL and using the ACL with the virtual server.

Note

To use ACLs with a virtual server, an authentication database must be associated with the virtual server and the ACL.

An instance is always created with a default virtual server and a default ACL. If acl is enabled, the default virtual server is already set up to use the default authentication database.

For any new virtual servers you want to associate with ACLs, the authentication database association is not done automatically. In this case, you must create a new authentication database entry for the new virtual server. The form of the entry will depend on the ACL being used.

Editing Access Control Lists for Virtual Servers

ACLs for virtual servers are created for the server instance that the virtual server resides in. Virtual server ACL settings default to those created for the server instance. However, you can choose to define a new ACL or edit an existing one.

To edit an existing ACL for a virtual server, perform the following steps:

  1. Access App Server Instances and HTTP Server in the left pane.
  2. Select ACLs and click the ACL you want to edit.
  3. Click Edit ACL File
  4. Under A. Pick a Resource, click Edit Access Control.

    5. The Access Control Rules table is displayed.

  5. Edit the information as described in the online help.
  6. Access App Server Instances and HTTP Server.
  7. Select Virtual Server and click the server instance.
  8. On the edit page, under the section where the ACLs are listed, choose whichever ACL you want to associate with the virtual server.
  9. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  10. Stop and start the server for changes to take effect.

Using htaccess Files

Server content is seldom managed entirely by one person. You may need to allow end users to access a subset of configuration options so that they can configure what they need to, without giving them access to the Sun ONE Application Server. The subset of configuration options is stored in dynamic configuration files.

The Sun ONE Application Server supports htaccess dynamic configuration files. You can enable htaccess files either through the user interface or by manually changing the configuration files. The htaccess plug-in is in the install_dir/lib directory.

You can use htaccess files in combination with the server’s standard access control. The standard access controls are always applied before any htaccess access control, regardless of the ordering of PathCheck directives.

Note

Do not require user authentication with both standard and htaccess access control when User-Group authentication is Basic. You could use SSL client authentication using the standard server access control, and also require HTTP Basic authentication using an htaccess file.

This section addresses the following topics:

Enabling htaccess from the User Interface

To configure your Sun ONE Application Server to use htaccess, perform the following steps:

  1. Under your App Server Instance, Access HTTP Server and Virtual Servers.
  2. Select a virtual server instance.
  3. Select the Doc Directories tab.

    4. The Additional Documentation Directories page is displayed.

    Figure 5-10  Virtual Server Doc Directories Page
    This screen capture shows the Additional Document Directories for the virtual server instance.

  4. Click the htaccess Configuration link.

    5. The htaccess Configuration page is displayed.

    Figure 5-11  Virtual Server htaccess Configuration Page
    This screen capture shows the htaccess configuration settings for the virtual server instance.

  5. Select the server to edit by:
    • Choosing the entire server or a specific server from the drop-down list
    • Choosing the directory and files to edit by clicking Browse
    • Choosing a wildcard pattern to edit by clicking Wildcard
  6. Select Yes to activate.htaccess.
  7. Enter the file name where you want the htaccess configuration to be added.
  8. Click OK.
  9. Access App Server Instances and your server instance in the left pane, then click Apply Changes.
  10. Stop and start the server for changes to take effect.

Enabling htaccess from init.conf

To manually enable your server to use the .htaccess, you need to first modify the server’s init.conf file to load, initialize, and activate the plug-in.

  1. Open init.conf in the instance_dir/config directory.
  2. After the other initialization directives, add the following lines:
    • For UNIX:

      • Init fn="load-modules" funcs="htaccess-init,htaccess-find,htaccess-register"
      shlib="      install_dir/lib/htaccess.so" NativeThread="no"
      Init fn="htaccess-init"

    • For Windows:

      • Init fn="load-modules" funcs="htaccess-init,htaccess-find,htaccess-register"
      NativeThread="no"
      Init fn="htaccess-init"

  3. (Optional) Edit the final line to read:

    4. Init fn="htaccess-init"[groups-with-users=yes]

  4. Click File/Save.
  5. Open obj.conf file.
  6. Add the PathCheck directive as the last directive in the object.
    1. To activate htaccess file processing for all directories managed by a virtual server, add the PathCheck directive to the default object in the obj.conf file:

      2. <Object name="default">

      ...

      PathCheck fn="htaccess-find"

      </Object>

      htaccess processing should be the last PathCheck directive in the object.

    2. To activate htaccess processing for particular server directories, place the PathCheck directive in the corresponding definition in init.conf.
  7. To name your htaccess files something other than htaccess, you must specify the file name in the PathCheck directive using the following format:

    8. PathCheck fn="htaccess-find" filename="filename"

    Note

    The next time you use the Admin Server, you will be warned that manual edits have been applied. Click Apply to accept your changes.

Subsequent access to the server will be subject to htaccess access control in the specified directories. For example, to restrict write access to htaccess files, create a configuration style for them, and apply access control to that configuration style. For more information, see Applying Configuration Styles.

Using htaccess-register

The htaccess-register allows you to create your own authentication methods. Like Apache, you can create external authentication modules and plug them into the htaccess module using htaccess-register.

You can use external modules to create one or more new directives. For example, you might specify the user database for authentication. The directives may not appear within <Limit> or <LimitExcept> tags.

The following example shows an htaccess file:

  <Limit> GET POST
  order deny,allow
  deny from all
  allow from all
  </Limit>
  <Limit> PUT DELETE
  order deny,allow
  deny from all
  </Limit>
  AuthName mxyzptlk.kawaii.com
  AuthUserFile /server_root/mxyz-docs/service.pwd
  AuthGroupFile /server_root/mxyz-docs/service.grp

Supported htaccess Directives

The following topics address the htaccess directives that are supported by the Sun ONE Application Server:

allow

Allows access to the specified hosts. Normally appears inside a <Limit> range.

Syntax

allow from_host

where:

Does not need to be enclosed within a <Limit> or <LimitExcept> range but usually is.

deny

Denies access to the specified host(s). Normally appears inside a <Limit> range.

Syntax

deny from_host

where:

Does not need to be enclosed in a <Limit> <LimitExcept> range but usually is.

AuthGroupFile

Specifies that the named group file to be used for any group definitions referenced in a require group directive. If the file name specified in an AuthGroupFile directive is the same as the file name in an AuthUserFile directive, the file is assumed to contain users and groups in the format:

username:DES-encrypted-password:comma-separated-list-of-groups

Syntax

AuthGroupFile file_name

where:

Must not appear within a <Limit> or <LimitExcept> range.

AuthUserFile

Specifies that the named user file is to be used for any user names referenced in a require user or require valid-user directive.

Note that the use of groups-with-users=yes in the Init fn=htaccess-init directive in obj.conf, or specifying an AuthGroupFile directive with the same file name, causes that file to be assumed to be in the format:

username:DES-encrypted-password:comma-separated-list-of-groups

Syntax

AuthUserFile filename

where:

Must not appear within a <Limit> or <LimitExcept> range.

AuthName

The authentication realm string typically appears in the prompt for user name and password on the client side. It may affect caching of user name and password on the client.

Syntax

AuthName authentication_realm

where

Must not appear within a <Limit> or <LimitExcept> range.

AuthType

Specifies the user authentication method as HTTP Basic Authentication, the only method currently supported.

Syntax

AuthType Basic

Must not appear within a <Limit> or <LimitExcept> range.

<Limit>

Applies the enclosed directives only for requests using the specified HTTP methods.

Syntax

<Limit method method ...>

allow, deny, order, or require directives

</Limit>

where

<LimitExcept>

Applies the enclosed directives only for requests types not matching the specified HTTP methods.

Syntax

<LimitExcept method method ...>

allow, deny, order, or require directives

</LimitExcept>

where

order

Syntax

order ordering

where

Does not need to be enclosed within a <Limit> or <LimitExcept> range, but usually is.

require

Syntax

requires group groupname groupname

requires user username username

requires valid-user

Does not need to be enclosed within a <Limit> or <LimitExcept> range, but usually is.



Previous      Contents      Index      Next     

Copyright 2003 Sun Microsystems, Inc. All rights reserved.