test

Sun Java System Web Server 6.1 SP9 Administrator's Guide

Working with Dynamic Access Control Files

Server content is seldom managed entirely by one person. You might 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 Java System Web Server. The subset of configuration options is stored in dynamic configuration files.

The following topics are described in this section:

Using .htaccess Files

The Sun Java System Web Server supports.htaccess dynamic configuration files. You can enable .htaccess files either through the user interface or by manually changing the configuration files. The files that support the .htaccess file are in the server_root/plugins/htaccess directory. These files include a plug-in that enables you to use .htaccess files and a script for converting .nsconfig files to .htaccess files.

You can use .htaccess files in combination with the server’s standard access control. The standard access control is always applied before any .htaccess access control, regardless of the ordering of PathCheck directives. Do not require user authentication with both standard and .htaccess access control when user-group authentication is ”Basic’ You could use SSL client authentication via the standard server access control, and also require HTTP ”Basic’ authentication via an .htaccess file.

This section includes the following topics:

Enabling .htaccess from the User Interface

To configure your Sun Java System Web Server to use the .htaccess file, perform the following steps:

ProcedureTo configure the Sun Java System Web Server to use .htaccess

  1. Access the Server Manager and select the server instance for which you want to enable .htaccess access control.

  2. Click the Class Manager link at the top of the screen.

  3. Select the Content Mgmt tab.

  4. Click the .htaccess Configuration link.

  5. Select the server to be edited:

    • Choose the entire server or a specific server from the drop-down list

      • Choose the directory and files to edit by clicking Browse

      • Choose a wildcard pattern to edit by clicking Wildcard

  6. Select Yes to activate .htaccess.

  7. Enter the file name for which you want to add .htaccess configuration to be added.

  8. Click OK.

  9. When finished, click Apply.

  10. Select Hard Start/Restart or Dynamically Apply.

Enabling .htaccess from magnus.conf

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

ProcedureTo manually enable your server to use the .htaccess

  1. Access the magnus.conffile in the server_root/https-server_name/config directory.

  2. After the other Init directives, add the following lines:

    • For UNIX/Linux:

      Init fn=”load-modules” funcs=”htaccess-init,htaccess-find”shlib=”server_root/plugins/htaccess/htaccess.so” NativeThread=”no”Init fn=”htaccess-init”

    • For Windows:

      Init fn=”load-modules” funcs=”htaccess-init,htaccess-find,htaccess-register”shlib=”server_root/plugins/htaccess/htaccess.dll” NativeThread=”no”Init fn=”htaccess-init”

    • For HP:

      Initfn=”load-modules” funcs=”htaccess-init,htaccess-find,htaccess-register” shlib=”<server_root>/plugins/htaccess/htaccess.sl” NativeThread=”no”

      Init fn=”htaccess-init”

  3. (Optional) Make the final line should read:

    Init fn=”htaccess-init”[groups-with-users=yes]

  4. Click Save from the File menu.

  5. Open obj.conf.

  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 object.conf file:

      <Object name="default">

      ...

      PathCheck fn="htaccess-find"

      </Object>

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

    2. To activate .htaccess file processing for particular server directories, place the PathCheck directive in the corresponding definition in magnus.conf.

  7. To name your .htaccess files something other than .htaccess, you must specify the filename in the PathCheck directive using the following format:

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

    Note –

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

    Subsequent access to the server is 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 Chapter 17, Applying Configuration Styles.

Converting Existing .nsconfig Files to .htaccess Files

The Sun Java System Web Server 6.1 includes the htconvert plug-in for converting your existing .nsconfig files to .htaccess files. The .nsconfig files are no longer supported. If you have been using.nsconfig files, you should convert them to .htaccess files.

When activated, htconvert searches the given server.xml files for pfx2dir and document-root directives. Each .nsconfig file found is translated into an .htaccess file. Multiple obj.conf files can be converted depending on configuration.

Note –

If there is an existing .htaccess file, htconvert will produce an .htaccess.new file, and slow a warning. If .htaccess and .htaccess.new already exist, the new file will be named .htaccess.new.new. The.new is repeatedly appended.

The htconvert plug-in currently only supports the RestrictAccess and RequireAuth directives, and the <Files> wrapper. If <Files> other than <Files*> are presented, the script issues a warning and behave as though all files in the directory are to be access-controlled.

To convert your files, at the command prompt, enter the path to Perl on your system, the path to the plug-in script, and the path to your server.xml file. For example:

server_root\install\perl server_root/plugins/htaccess/htconvert server_root/https-server_name/config/server.xml

All .nsconfig files are converted to .htaccess files, but not deleted.

The groups-with-users option facilitates handling large numbers of users in groups. If you have many users in a group, follow these steps:

  1. Revise the format of the user file format to list all the groups a user belongs to:

    username:password:group1,group2,group3,...groupn

  2. Revise the AuthGroupFile directive to point to the same file as the AuthUserFile.

    Alternatively, you can:

  3. Remove the AuthGroupFile directive entirely.

  4. Add the following to the Init fn=htaccess-init line in the magnus.conf file:

    groups-with-users="yes"

Using htaccess-register

The htaccess-register function allows you to create your own authentication methods. Like Apache you can create external authentication modules and plug them into the .htaccess module via htaccess-register. Two sample modules are provided in server_root/plugins/nsapi/htaccess.

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.

htpasswd Command

The htpasswd command is used to generate or modify a password file suitable for use with the htaccess access control mechanism.

The htpasswd usage is as follows: 

htpasswd [-c] passwordfile username [password]

Where, -c creates a new passwordfile(overwriting an old one if it exists). Without -c, the command will modify the existing file by either updating the user's password (if user already exists) or adding a new user with the given name. If the optional password argument is not given, it will prompt interactively for the password to assign.

Note –

htaccess is not the preferred access control mechanism in Web Server. Wherever possible, use ACLs instead.

Example of an .htaccess File

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 .htaccess directives are supported in this release:

allow

Syntax

Allows from host where:

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

Effect

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

deny

Syntax

Deny from host where:

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

Effect

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

AuthGroupFile

Syntax

AuthGroupFile filename where filename is the name of file containing group definitions in the form: groupname: user user.

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

Effect

Specifies that the named group file is to be used for any group definitions referenced in a require group directive. Note that if the filename specified in an AuthGroupFile directive is the same as the filename 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

AuthUserFile

Syntax

AuthUserFile filename where:

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

Effect

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 filename, causes that file to be assumed to be in the format:

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

AuthName

Syntax

AuthName authentication realm where authentication realm is a string identifying an authorization realm to be associated with any request for user authentication.

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

Effect

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

AuthType

Syntax

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

Effect

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

<Limit>

Syntax

<Limit method method ...>

allow, deny, order, or require directives

</Limit>

where method is an HTTP method such as GET, POST, or PUT. Any method that the web server understands can be used here.

Effect

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

<LimitExcept>

Syntax

<LimitExcept method method ...>
allow, deny, order, or require directives
</LimitExcept>

where method is an HTTP method such as GET, POST, or PUT. Any method that the web server understands can be used here.

Effect

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

order

Syntax

Order ordering where ordering is one of:

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

Effect

require

Syntax

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

Effect

.htaccess Security Considerations

By default, server support for HTTP PUT is disabled. You can activate HTTP PUT using the Remote File Manipulation page of Content Mgmt in the Class Manager. Be careful when allowing PUT access to directories containing .htaccess files, since it will allow them to be replaced. PUT access can be prevented on all files in a directory by restricting access. See Restricting Access to a Directory (Path).