This chapter discusses the methods you can use to control access to the Administration Server and to the files and directories on your web site. For example, for the Administration Server, 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. Before you can use access control on the Administration Server, you must enable distributed administration from and set up an administration group in your LDAP database. This chapter assumes you have already configured distributed administration and have defined users and groups in your LDAP database.
You should also ensure the security of the web server as discussed in Chapter 5, J2SE-based Security for Web Container and Web Applications, and in Chapter 7, Using Certificates and Keys.
This chapter contains the following sections:
Access control allows you to determine:
Who can access Sun Java System Web Administration Server
Which programs they can access
Who can access the files or directories on your web site
You can control access to the entire server or to parts of the server, or to files and directories on your web site. You create a hierarchy of rules called access control entries (ACEs) to allow or deny access. 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 server has one ACL file that contains multiple ACLs. After determining which virtual server to use for an incoming request, the Sun Java System Web Server checks if any ACLs are configured for that virtual server. If ACLs are found that apply for the current request, the Sun Java System Web Server evaluates their ACEs to determine whether access should be granted or denied.
If there are more than one ACLs that match, the server uses the last statement that matches. The defaultACL is bypassed since the uri ACL is the last statement that matches.
You allow or deny access based on:
When the request is happening (for example, time of day)
What type of connection is being used (SSL)
You can limit the access to your web server to certain users or groups. User-Group access control requires users to enter a username 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 the basic authentication. If you wish to require client authentication on your 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 details, see the section Configuring a Directory Service. The information that 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, it supports the following types of User-Group authentication methods for server instances:
Default
Basic
SSL
Digest
Other
When the server uses an internal file-based directory service, the User-Group authentication methods for server instances it supports include:
Default
Basic
Digest
User-Group authentication requires users to verify their identity before they are able access to the Administration Server, or files and directories on the web site. During authentication, users enter username and password, using a client certificate, or digest authentication plug-in. To use a client certificate you require encryption. For information on encryption and using client certificates, see Chapter 5, J2SE-based Security for Web Container and Web Applications.
Default authentication is the preferred authentication method. The Default setting uses the default method in the obj.conf file, or “Basic” if there is no setting in the obj.conf file. If you select Default, the ACL rule does not 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.
Basic authentication is selected by default and requires users to enter a username and password to access the web server or web site. 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 either a directory server installed on a different server root than your web server, or a directory server installed on a remote machine.
When users attempt to access a resource that has User-Group authentication in the Administration Server or on your web site, the web browser displays a dialog box asking the user to enter a username and password. The server receives the information either encrypted or unencrypted, depending on whether encryption is turned on for the server.
If you use the Basic Authentication setting without SSL encryption, the username and password are sent as unencrypted text across the network. The network packets could be intercepted, and the username and password could be misused. Basic authentication is most effective when combined with SSL encryption, Host-IP authentication, or both. Use Digest Authentication to avoids this problem.
The following dialog appears when users authenticate their identity:
After you click OK, the following process is followed:
The Server Administration page, if authenticated to access the Sun Java System Web Administration Server
The file or directory listing requested, if logging in to a web site
A message denying access if the username or password are invalid
You can customize the access denied message received by unauthorized users using the Access Denied Response page.
The server can confirm users’ identities using security certificates in the following ways:
By using the information in the client certificate as proof of identity
By verifying a client certificate published in an LDAP directory (additional)
When you configure the server to use certificate information for authenticating the client, the server:
Checks first if the certificate is from a trusted CA. If not, the authentication fails and the transaction ends. To learn how to turn on client authentication, see Requiring Client Authentication.
Maps the certificate to a user’s entry using the certmap.conf file, if the certificate is from a trusted certificate authority (CA). To learn how to set up the certificate mapping file see Using the certmap.conf File.
Checks the ACL rules specified for a specific user if the certificate maps correctly. Even if the certificate maps correctly, ACL rules can deny the user access.
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. If you set the server’s access control to use the SSL method for authentication of users and groups, the client needs to:
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, you need to have SSL ciphers enabled for your web server. See Chapter 7, Using Certificates and Keys to learn how to enable SSL.
In order to successfully gain access to an SSL authenticated resource, the client certificate must be from a CA trusted by the web server. The client certificate needs to be published in a directory server if the web 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 only compare selected information from the certificate to the directory server entry. For example, you could configure the certmap.conf file to only compare 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 Chapter 7, Using Certificates and Keys.
Only the SSL authentication method requires you to modify the certmap.conf file, because the certificate is checked against the LDAP directory. 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 magnus.conf.
The Sun Java System Web Server 6.1 can be configured to perform digest authentication using either an LDAP-based or a file-based directory service.
Digest authentication allows the user to verify identity based on username and password without sending the username and password as cleartext. The browser uses the MD5 algorithm to create a digest value using the user’s password and some information provided by the Web Server.
When the server uses an LDAP-based directory service to perform digest authentication, this value is also computed on the server using the Digest Authentication plug-in, and is there compared against the digest value provided by the client. If the digest values match, the user is authenticated. In order for this process to work, the directory server needs access to the user’s password in cleartext. The 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 need to enable the reversible password plug-in and the digestauth-specific plug-in included with Sun Java System Web Server 6.1. To configure the web server to process digest authentication, set the digestauth property of the database definition in dbswitch.conf.
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 will use either digest or basic when authentication is required, or basic if authentication is not required. This is the preferred method.
Table 9–1 Digest Authentication Challenge Generation
ACL Method |
Digest Authentication Supported by Authentication Database |
Digest Authentication 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:
Checking for Authorization request header. If not found, a 401 response is generated with a Digest challenge, and the process ends.
Checking for Authorization type. If Authentication type is Digest then:
Checks nonce. If not valid, fresh nonce generated by this server, generates a 401 response, and the process stops. If stale, generates 401 response with stale=true, and the process stops.
You can configure the time the nonce remains fresh by changing the value of the parameter DigestStaleTimeout in the magnus.conf file, located in server_root/https-server_name/config/. To set the value, add the following line to magnus.conf:
where seconds represents the number of seconds the nonce will remain fresh. After the specified seconds elapse, the nonce expires and new authentication is required from the user.
Checks realm. If it does not match, generates 401 response, and process stops.
verifies the existence of user in the LDAP directory if the authentication directory is LDAP-based, or verifies the existence of user in file database if the authentication directory is file-based. If not found, generates 401 response, and the process stops.
Gets request-digest value from directory server or file database and checks for a match to client’s request-digest. If not, generates 401 response, and process stops.
Constructs Authorization-Info header and inserts it into server headers.
For digest authentication using an LDAP-based directory service, you need to install the digest authentication plug-in. This plug-in computes a digest value on the server side, and compares this against the digest value provided by the client. If the digest values match, the user is authenticated.
If you’re using a file-based authentication database, you don’t need to install the digest authentication plug-in.
The Digest Authentication plug-in consists of a shared library found in the following files:
Make sure this shared library resides on the same server machine that the Sun Java System Directory Server is installed on.
Make sure you know the Directory Manager password.
Modify the libdigest-plugin.ldif file changing all references to the /path/to to the location where you installed the digest plug-in shared library.
libdigest-plugin.ldif is available at server-root/plugins/digest/libdigest-plugin.ldif.
To install the plug-in, enter the following command:
% ldapmodify -D "cn=Directory Manager" -w password -a < libdigest-plugin.ldif
You need to copy several .dll files from the Sun Java System Web Server installation to your Sun Java System Directory Server server machine in order for Sun Java System Directory Server to start properly with the Digest plug-in.
Access the shared libraries on the Sun Java System Web Server installation in:
[server_root]\bin\https\bin
Copy the following files:
Paste them into either:
The DES algorithm is needed to encrypt the attribute that stores the digest password.
Launch the Sun Java System Directory Server Console.
Open your iDS 5.0 instance.
Select the Configuration tab.
Click on the + sign next to plug-ins.
Select the DES plug-in.
Choose Add to add a new attribute.
Enter iplanetReversiblePassword.
Click Save.
Restart your Sun Java System Directory Server instance.
The iplanetReversiblePasswordobject attribute stores the password for digest authentication. To set a digest authentication password in the iplanetReversiblePassword attribute for a user, your entry must include the iplanetReversiblePasswordobject object.
You can create a custom authentication method using the access control API.
You can limit access to the Administration Server files, and directories on your web site by making them available only to clients using specific computers. You specify hostnames or IP addresses for the computers that you want to allow or deny. You can use wildcard patterns to specify multiple computers or entire networks. Access to a file or directory using Host-IP authentication appears easier to the user. Users can access the files and directories immediately without entering a username or password.
Since more than one person might use a specific computer, Host-IP authentication is more effective when combined with User-Group authentication. If both methods of authentication are used, a username and password are required for access.
Host-IP authentication does not require DNS to be configured on your server. If you choose to use Host-IP authentication, you must have DNS running on your network and your server must be configured to use it. You can enable DNS on your server through the Performance Tuning page in the Preferences tab on your Server Manager.
Enabling DNS degrades the performance of Sun Java System Web Server since the server is forced to perform DNS look-ups. To reduce the effect of DNS look-ups on your server’s performance, resolve IP addresses only for access control and CGI instead of resolving the IP address for every request. To do this, iponly=1 to AddLog fn="flex-log" name="access" in the obj.conf file:
AddLog fn="flex-log" name="access" iponly=1
When you use access control on the Administration Server or the files or directories on your web site, the settings are stored in a file with a .acl extension. Access control files are stored in the directory install_dir/httpacl directory with install_dir being the location where the server is installed. For example, if you installed the server in /usr/Sun/Servers, the ACL files for both the Administration Server and each server instance configured on your server would be located in /usr/Sun/Servers/httpacl/.
The main ACL file name is generated-https-server-id.acl; the temporary working file is called genwork-https-server-id.acl. These two files are present on your system if you use Sun Java System Administration Server to configure access. To create more complex restrictions, create multiple files, and reference these files from the server.xml file. Some features becomes available when you edit the files such as restricting access to the server based on the time of day or day of the week.
You can also manually create and edit .acl files to customize access control using APIs. For more information on using access control APIs, see the Sun Java System Web Server 6.1 SP12 Programmer’s Guide.
For more information on access control files and their syntax, see Appendix C, ACL File Syntax.
By default, the Sun Java System Web Server caches user and group authentication results in the ACL user cache. You can control the amount of time that ACL user cache is valid by using the ACLCacheLifetime directive in the magnus.conf file. Each time an entry in the cache is referenced, its age is calculated and checked against ACLCacheLifetime. The entry is not used if its age is greater than or equal to the ACLCacheLifetime. The default value is 120 seconds. Setting the value to 0 (zero) turns the cache off. If you use a large number for this value, you may need to restart the Sun Java System Web Server every time you make changes to the LDAP entries. For example, if this value is set to 120 seconds, the Sun Java System Web Server might be out of sync with the LDAP directory for as long as two minutes. Only set a large value if your LDAP directory is not likely to change often.
Using the magnus.conf parameter for the ACLUserCacheSize, you can configure the maximum number of entries that can be held in the cache. The default value for this parameter is 200. New entries are added to the head of the list, and entries at the end of this list are recycled to accommodate new entries when the cache reaches its maximum size.
You can also set the maximum number of group memberships that can be cached for each user entry using the magnus.conf parameter, ACLGroupCacheSize. The default value for this parameter is four. Unfortunately non-membership of a user in a group is not cached, and will result in several LDAP directory accesses on every request.
For more information on ACL file directives, see the Sun Java System Web Server 6.1 SP12 NSAPI Programmer’s Guide.
When the server receives a request for a page, it uses the rules in the ACL file to determine whether to grant access or not. The rules can refer to the hostname or IP address of the computer sending the request. The rules can also refer to a list of users and groups stored in the LDAP directory.
For example, the following ACL file contains the two default entries for the Administration Server (admin-serv), in addition to an entry that allows users in the “admin-reduced” group to access the Preferences tab in the Administration Server.
version 3.0; # The following "es-internal" rules protect files such # as icons and images related to Sun Java System Web 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 Java System Web 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"); |
For example, if a user requests the URL: http://server_name/my_stuff/web/presentation.html
The Sun Java System Web Server first checks access control for the entire server. If the ACL for the entire server set to continue, the server checks for an ACL associated with the my_stuff directory. If an ACL exists, the server checks the ACEs within the ACL, and 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 presentation.html file) is scanned.
To set up access control for the example above using the Server Manager, you could create an ACL for the file only, or for each resource leading to the file. That is, one for the entire server, one for the my_stuff directory, one for the my_stuff/web directory, and one for the file.
If more than one ACL matchs, the server uses the last ACL statement that is matched. The default ACL is bypassed since the uri ACL is the last statement that matches.
This section describes the process of restricting access to the files or directories on your web site. You can set global access control rules for all servers, and also individually for specific servers. For instance, a human resources department might create ACLs allowing all authenticated users to view their own payroll data, but restrict access to updating data to only human resource personnel responsible for payroll.
You can set access control globally for all servers through the Administration Server. Each option is described in detail in the following section, Selecting Access Control Options.
Distributed administration must be configured and activated before global access control can be configured.
To configure or edit access control globally for all servers, perform the following steps:
Access the Administration Server and choose the Global Settings tab.
Click the Restrict Access link.
Select the administration server (https-admserv) from the drop-down list.
Click Create ACL, Select Go button.
The Access Control Rules for uri=/https-admserv/ page appears:
The Administration Server has two lines of default access control rules which cannot be edited.
Select the Access control is On option , if it is not already selected.
To add a default ACL rule to the bottom row of the table, click the New Line button.
To swap an access control restriction with the access control restriction preceding it, click the up arrow icon.
To swap an access control restriction with the access control restriction following it, click the down arrow icon.
Click on the Anyone field in the Users/Groups column.
The User/Group page appears.
Select the users and groups to configure access to and click Update.
Click List for Group and User to provide lists for you to choose from.
Click on the Anyplace field in the From Host column.
Enter Host Names and IP Addresses that are allowed access and click Update.
Click All Programs in the Programs window.
Select the Program Groups or enter the specific file name in the Program Items field you will allow access to, and click Update.
(Optional) Click the x under the Extra column to add a customized ACL expression.
Click the Continue column, if it isn’t already selected as the default.
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.
(Optional) Click Response when denied to direct the user to a different URL or URI.
Enter the path to the absolute URL or a relative URI and click update.
Click Submit to store the new access control rules in the ACL file.
Clicking Revert will remove all of the settings you’ve just created.
You can create, edit, or delete access control for a specific server instance using the Server Manager.
While 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:
Access the Server Manager and select the server instance you wish to create or edit ACLs for.
Choose the Preferences tab from the Server Manager.
Click the Restrict Access link.
From the Option column choose one of the following:
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 with three options appears:
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 filename 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.
Enter the ACL name allows to create named ACLs. 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.
Table 8-2 describes the resource wildcards you can use.
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. |
Click Edit Access Control.
The Access Control Rules for: (server instance) appears.
Select Access control is on, if it is not already selected.
To configure or edit the ACL for this server instance, click Deny in the Action column.
Select Allow, if it isn’t already selected as the default, and click Update.
Click on the Anyone field in the Users/Groups column.
The User/Group page appears in the lower frame:
Select which users and groups you will allow access to and click Update.
Clicking List for Group and User provide lists for you to choose from.
Click on anyplace in the From Host column.
Enter Host Names and IP Addresses allowed access and click Update.
Click on All field in the Rights column.
Select one of the following and then click Update:
All Access Rights
Only the following rights and check all appropriate rights for this user
(Optional) Click the x under the Extra column to add a customized ACL expression.
Put a check in the Continue column, if it isn’t already selected as the default.
The server evaluates the next line before determining if the user is allowed access. When creating multiple lines, starts with the most general restrictions to the more specific ones.
(Optional) Click Response when denied to direct the user to a different URL or URI.
Enter the path to the absolute URL or a relative URI and click update.
Click Submit to store the new access control rules in the ACL file.
Clicking Revert will remove all of the settings you’ve just created.
Repeat all steps above for each server instance you wish to establish access control for.
When finished, click Apply.
Select Hard Start/Restart or Dynamically Apply.
ACL settings can also be enabled for each virtual server. For more information, see Accessing Databases from Virtual Servers.
The following section describes the various options you can select when setting access control. For the Administration Server, the first two lines are set as defaults, and cannot be edited.
You can specify the action to be taken by the server when a request matches the access control rule.
Allow means users or systems can access the requested resource
Deny means users or systems cannot access the resource
The server scans the list of access control expressions (ACEs) to determine the access permissions. For example, the first ACE is usually to deny everyone. If the first ACE is set to “continue,” the server checks the second ACE in the list, and if it matches, that ACE is used. If continue is not selected, everyone would be denied access to the resource. The server continues down the list until it reaches either an ACE that doesn’t match, or that matches but is set to not continue. The last matching ACE determines if access is allowed or denied.
With user and group authentication, users are prompted to enter a username and password before they can access the resource specified in the access control rule.
Sun Java System Web Server checks lists of users and groups stored either in an LDAP server, such as Sun Java System Directory Server, or in an internal file-based authentication database.
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.
Anyone (No Authentication) is the default and means anyone can access the resource without having to enter a username or password. However, the user might be denied access based on other settings, such as host name or IP address. For the Administration Server, this means that anyone in the administrators group that you specified with distributed administration can access the pages.
Authenticated people only
All in the authentication database matches any user who has an entry in the database.
Only the following people lets you specify which users and groups to match. You can list users or groups of users in a comma separated list, or with a wildcard pattern, or you can select from the lists of users and groups stored in the database. Group refers to all users in the groups you specify. User refers to the individual users you specify. For the Administration Server, the users must also be in the administrators group you specified for distributed administration.
Prompt for authentication allows you to enter message text that appears in the authentication dialog box. You can use this text to describe what the user needs to enter. Depending on the operating system, the user sees approximately about the first 40 characters of the prompt. Netscape Navigator and Netscape Communicator cache the username and password, and associate them with the prompt text. When the user accesses files and directories of the server having the same prompt, the usernames and passwords do not need to be entered again. If you want users to authenticated again for specific files and directories, you simply need to change the prompt for the ACL for that resource.
Authentication Methods specifies the method the server uses for getting authentication information from the client. The Administration Server offers only the Basic method of authentication.
Default uses the default method you specify in the obj.conf file, or “Basic” if there is no setting in obj.conf. If you check Default, 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.
Basic uses the HTTP method to get authentication information from the client. The username and password are only encrypted if encryption is turned on for the server.
SSL uses the client certificate to authenticate the user. To use this method, SSL must be turned on for the server. When encryption is on, you can combine Basic and SSL methods.
Digest uses the an authentication mechanism that provides a way for a browser to authenticate based on username and password without sending the username and password as cleartext. The browser uses the MD5 algorithm to create a digest value using the user’s password and some information provided by the Web Server. 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.
Other uses a custom method you create using the access control API.
Authentication Database lets you select a database the server uses to authenticate users. This option is only available through the Server Manager. If you choose Default, the server looks for users and groups in a directory service configured as default. If you wish to configure individual ACLs to use different databases, select Other, and choose the database from the drop-down list. Non-default databases and LDAP directories need to have been specified in the file server_root/userdb/dbswitch.conf. If you use the access control API for a custom database, such as Oracle or Informix, select Other, and enter the database name.
You can restrict access to the Administration Server or to your web site based on which computer the request comes from.
The Anyplace field allows access to all users and systems
The Only From field allows you to restrict access to specific Host Names or IP Addresses
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 using hostname is more flexible than by IP address: if a user’s IP address changes, you will not 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 Administration Server.
For hostnames, the * must replace an entire component of the name. That is, *.sun.com is acceptable, but *users.sun.com is not. When the * appears in a hostname, it must be the left-most 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 acceptable. When the * appears in an IP address, it must be the right-most character. For example, 198.* is acceptable, but 198.*.251.30 is not acceptable.
Access to programs can only be restricted by the Administration Server. Restricting access to programs allows only specified users to view the Server Manager pages and determines if they can configure the server. For example, you might allow some administrators to configure the Users & Groups section of the administration server but might deny them access to modify Global Settings.
You can configure different users to access different functional domains. Once a user setup with access to a few selected functional domains logs in the Administration Server pages from only those functional domains are visible to the user.
All Programs allows or denies access to all programs. By default administrators have access to all programs for a server.
Only the following Program Groups allows you to specify which programs the user has access to. Select the program from the drop-down list. You can choose multiple program groups by pressing the Control key while clicking on the groups. You can restrict access to the following programs groups:
None (default)
Servers
Preferences
Global Settings
Users & Groups
Security
Cluster Mgmt
The Program Groups listed reflect the tabs of the Administration Server, for example, Preferences and Global Settings, and represent access to those pages. When an administrator accesses the Administration Server, the server uses their username, host, and IP to determine what pages they can view.
Program Items allows you to enter a page name in the Program Items field to control access to a specific page within a program.
Access rights can only be set by the Server Manager for a server instance. 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 grant users read-only access rights to your files, so they can view the information, but not change the files.
All Access Rights is the default and allows or denys all rights
Only the following rights allow you to select a combination of rights to be allowed or denied:
Read allows users to view files, including includes the HTTP methods GET, HEAD, TRACE, OPTIONS, and COPY.
Write allows users to change or delete files, including the HTTP methods PUT, MKDIR, MOVE, POST, LOCK, UNLOCK, PROPPATCH, andMKCOL.
Execute allows users to execute server-side applications, such as CGI programs, Java applets, and agents including includes the HTTP methods POST.
Delete allows users who also have write privileges to delete files or directories including includes the HTTP methods DELETE, RMDIR, and MOVE.
List allows users to access lists of the files in directories that don’t contain an index.html file including includes the HTTP method INDEX, and PROPFIND.
Info allows users to receive information about the URI, including includes the HTTP method INDEX, TRACE, and OPTIONS.
Although the following methods are present in the code, they are not included in the document above, revlog, getattribute, getattributename, getproperties, startrev, stoprev, edit, unedit, save, setattribute, revadd, revlabel and destroy.
You can enter custom expressions for an ACL. Select this option only if you are familiar with the syntax and structure of ACL files. There are a few features available only by editing the ACL file or creating custom expressions. For example, you can restrict access to your server depending on the time of day, day of the week, or both.
The following customized expression shows how you can restrict access by time of day and day of the week. This example assumes that you have two groups in your LDAP directory: the “regular” group gets access Monday through Friday, 8:00am to 5:00pm. while the “critical” group gets 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) }
For more information on valid syntax and ACL files, see Appendix C, ACL File Syntax and Referencing ACL Files in obj.conf.
When you uncheck the option labeled “Access control is on,” you see 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-https-server-id.acl file by putting # signs at the beginning of each line.
From the Administration Server, you could create and turn on access control for a specific server instance and leave it off (which is the default) for other servers. For example, you could deny access to the Server Manager pages from the Administration Server. With distributed administration setting turned on and access control turned off by default for any other servers, administrators could still access and configure other servers, but they cannot configure the Administration Server.
The access control is performed in addition to the user being part of the administrators group for distributed administration. The Administration Server first checks that a user (other than superuser) is in the administrators group, and then evaluates the access control rules.
The Sun Java System Web Server provides the following default message when access is denied: “FORBIDDEN. Your client is not allowed access to the restricted object.” You can choose to show a different response when access is denied. You can also create a different message for each access control object.
Click the Response When Denied link from the ACL page.
Select Respond With the Following File in the lower frame.
Enter the path to the absolute URL or a relative URI and click update.
Make sure users have access to the URL or URI they are redirected to.
Click Update.
Click Submit in the top frame to submit the access control rule.
This section describes commonly used access restrictions to a web server. The steps for each procedure detail the specific actions you need to take. You still need to complete all the steps described under Setting Access Control.
The following procedures are described in this section:
You may wish to allow access to users in a group called who access the server from computers in a subdomain. For instance, you may have a server for a company department that you only want users to access from computers in a specific subdomain of your network.
Use the Server Manager to select the server instance.
Choose the Preferences tab.
Click the Restrict Access link.
Choose the ACL file to edit.
Pick the entire server resource, and click Edit Access Control.
Add a new rule to deny access to all.
Add another new rule to allow access to a specific group.
Enter a wildcard pattern for the host names of the computers to be allowed.
For example, *.employee.sun.com
Deselect Continue.
Submit and Apply your changes.
You can allow users in a group to read or run applications in directories, and its subdirectories and files, that are controlled by the owner of a group. For example, a project manager might update status information for a project team to review.
To limit access to a directory on the server, using the steps described for setting access control for a server instance, perform the following task:
Use the Server Manager to select the server instance.
Choose the Preferences tab.
Click the Restrict Access link.
Choose the ACL File to edit.
Browse the Pick a Resource section and select the directory you want to restrict.
The directories in the server’s document root are displayed. Once selected, the Editing drop-down list displays the absolute path to the directory.
If you want to view all files in your server root, click Options and then List files as well as directories.
Click Edit Access Control.
Create a new rule and leave the defaults to deny access to everyone from everywhere.
Create another new rule allowing users in a specific group to have read and execute rights only.
Create a third rule to allow a specific user to have all rights.
Deselect Continue for the second and third lines and click Update.
Submit and Apply your changes.
An absolute path to the file or directory is created in the docrootdirectory. The entry in the ACL file would appear as: acl “path=d:\sun\suitespot\docroot1\sales/”;
You can use a URI to control access to a single user’s content on the web 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). This is also a good method 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, you would:
Use the Server Manager to select the server instance.
Choose the Preferences tab.
Click the Restrict Access link.
Enter the URI you want to restrict in the Type in the ACL name section.
For example: uri=/my_directory.
Click Edit Access Control.
Create a new rule to allows all users read access.
Create another new rule to allow access for the owner of the directory.
Deselect Continue for both the first and second rules.
Click Submit and Apply your changes.
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”;
You can limit access to file types on your server or web site. For example, you might wish 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, you would:
Use the Server Manager to select the server instance.
Choose the Preferences tab.
Click the Restrict Access link.
Click Wildcard in the Pick a resource section and enter a wildcard pattern.
For example, *.cgi.
Click Edit Access Control.
Create a new rule to allow read access to all users.
Create another rule that allows write and delete access only to a specific group.
Submit and Apply your changes.
For file type restriction, 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 might include wildcard patterns for files or directories. The entry in the ACL file would appear as follows: acl “*.cgi”;
You can restrict write and delete access to the server during specified hours or on specified days. You might use this option to prevent people from publishing documents during working hours when people might be accessing the files.
To limit access based on time of day, complete the following task:
Use the Server Manager to select the server instance.
Choose the Preferences tab.
Click the Restrict Access link.
Select the entire server from the drop-down list in Pick a Resource and click Edit Access Control.
Create a new rule allowing read and execute rights to all.
If a user wants to add, update, or delete a file or directory, this rule will not apply and the server searches for another rule that matches.
Create another new rule denying write and delete rights to all.
Click X link to create a customized expression.
Enter the days of the week and the times of day to be allowed.
For example:
user = "anyone" anddayofweek = "sat,sun" or(timeofday >= 1800 andtimeofday <= 600) |
The message “Unrecognized expressions” is displayed in the Users/Groups and From Host fields when you create a custom expression.
Submit and Apply your changes.
Any errors in the custom expression will generate an error message. Make corrections and submit again.
As of Sun Java System Web Server 6.1 you can configure SSL and non-SSL listen sockets 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, you would:
Use the Server Manager to select the server instance.
Choose the Preferences tab.
Click the Restrict Access link.
Select the entire server from the drop-down list in Pick a Resource and click Edit Access Control.
Create a new rule allowing read and execute rights to all.
If a user wants to add, update, or delete a file or directory, this rule will not apply and the server will searches for another rule that matches.
Create a new rule denying write and delete rights to all.
Click X link to create a customized expression.
Enter ssl=”on”.
Example:
user = "anyone" and ssl=”on” |
Submit and Apply your changes.
Any errors in the custom expression generates an error message. Make the necessary corrections and submit your changes again.
This section lists the additional tasks you must perform in order to secure access control with the Sun Java System Web Server 6.1, after enabling distributed administration.
The order in which the PathCheck directive occurs in the https-server-id object tag in the generated.https-server-id.acl file might grant undesired access to resources. To prevent unauthorized access, edit the <server-root>/generated.https-server-id.acl file, specifying a comma-separated list of program groups for which access control is required, as shown below:
Below the line:
allow (all)
user=<username> and program=<program group, program group...>;
add the following line:
deny absolute (all)
user=<username> and program!=<program group, program group...>;
To configure the Sun Java System Web Server 6.1 to control access to server instances, edit the <server-root>/httpacl/*.https-admserv.acl files to specify the user to whom you want to grant access control privileges. Example:
acl "https-<instance>";
authenticate (user,group) {
database = "default";
method = "basic";
};
deny absolute (all) user != "UserA";
If the access control entry that refers to the ip attribute is located in the Administration Server related ACL files (gen*.https-admserv.acl), then complete steps (1) and (2) below.
If the access control entry that refers to the ip attribute is located in the ACL files related to a server instance, then complete only step (1) below for that particular ACL.
Edit the <server-root>/httpacl/gen*.https-admserv.acl files to add ip to the authentication list, in addition to user and group, as shown below:
acl "https-admserv";
authenticate (user,group,ip) {
database = "default";
method = "basic";
};
Add the following access control entry:
deny absolute (all) ip !="ip_for_which_access_is_allowed";
Example:
acl "https-admserv";
authenticate (user,group,ip) {
database = "default";
method = "basic";
};
deny absolute (all) ip !="205.217.243.119";
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:
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:
To configure your Sun Java System Web Server to use the .htaccess file, perform the following steps:
Access the Server Manager and select the server instance for which you want to enable .htaccess access control.
Click the Class Manager link at the top of the screen.
Select the Content Mgmt tab.
Click the .htaccess Configuration link.
Select the server to be edited:
Select Yes to activate .htaccess.
Enter the file name for which you want to add .htaccess configuration to be added.
Click OK.
When finished, click Apply.
Select Hard Start/Restart or Dynamically Apply.
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.
Access the magnus.conffile in the server_root/https-server_name/config directory.
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”
(Optional) Make the final line should read:
Init fn=”htaccess-init”[groups-with-users=yes]
Click Save from the File menu.
Open obj.conf.
Add the PathCheck directive as the last directive in the object.
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.
To activate .htaccess file processing for particular server directories, place the PathCheck directive in the corresponding definition in magnus.conf.
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"
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.
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.
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:
Revise the format of the user file format to list all the groups a user belongs to:
username:password:group1,group2,group3,...groupn
Revise the AuthGroupFile directive to point to the same file as the AuthUserFile.
Alternatively, you can:
Remove the AuthGroupFile directive entirely.
Add the following to the Init fn=htaccess-init line in the magnus.conf file:
groups-with-users="yes"
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.
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.
htaccess is not the preferred access control mechanism in Web Server. Wherever possible, use ACLs instead.
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
The following .htaccess directives are supported in this release:
Allows from host where:
host is all, to allow access from all client hosts
host is all or the last part of a DNS host name
host is a full or partial IP address
Does not need to be enclosed within a <Limit> or <LimitExcept> range but usually is.
Allows access to the specified hosts. Normally appears inside a <Limit> range.
Deny from host where:
host is all, to deny access from all client hosts
host is all or the last part of a DNS host name
host is a full or partial IP address
Does not need to be enclosed in a <Limit> <LimitExcept> range but usually is.
Denies access to the specified hosts. Normally appears inside a <Limit> range.
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.
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 filename where:
filename is the name of file containing user definitions in the form: username:password
username is a user login name, and password is the DES-encrypted password.
Must not appear within a <Limit> or <LimitExcept> range.
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 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.
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 Basic. Must not appear within a <Limit> or <LimitExcept> range.
Specifies the user authentication method as HTTP Basic Authentication, the only method currently supported.
<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.
Applies the enclosed directives only for requests using the specified HTTP methods.
<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.
Applies the enclosed directives only for requests types not matching the specified HTTP methods.
Order ordering where ordering is one of:
allow, deny
deny, allow
mutual-failure
Does not need to be enclosed within a <Limit> or <LimitExcept> range, but usually is.
allows, denies, evaluates allow directives and then deny directives
denies, allows, evaluates deny directives and then allow directives
mutual-failure denies access for a host listed in both allow and deny directives, regardless of their ordering
require group groupname groupname
require user username username
require valid-user
Does not need to be enclosed within a <Limit> or <LimitExcept> range, but usually is.
require group requires the authenticated user to be a member of one of the specified groups.
require user requires the authenticated user to be one of the specified users.
require valid-user requires an authenticated user.
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).
Access control information in the Sun Java System Web Server 6.1 is provided by a per-virtual server ACL file and .htaccess files in the document directories. The .htaccess system has not changed from iPlanet Web Server 4.x.
Your server.xml file can contain one or more ACLFILE tags which define an ID associated with a particular standard Sun Java System Web Server 6.x ACL file. For example:
<ACLFILE 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 ”aclids’ property. For example:
<VS aclids=”standard”>
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 USERDB tags to its definition. These USERDB 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:
<VS> <USERDB id=”default” database=”default”> </VS>
You can globally define user authentication databases in the dbswitch.conf file. It is only read at server startup.
The baseDN of the LDAP URL in dbswitch.conf defines the global root of all accesses to the database. This maintains backward compatibility. For most new installations, the baseDN would be empty.
The new dcsuffix attribute for LDAP databases in the dbswitch.conf file that defines the root of the DC tree according to the Sun Java System LDAP schema. It is relative to the baseDN in the LDAP URL. When the dcsuffix attribute is present, the LDAP database is Sun Java System LDAP schema compliant, and the behaviour of some operations changes. For more information about the Sun Java System LDAP schema, and an example, see The Sun Java System LDAP Schema.
For every virtual server, you can define one or more USERDB blocks that point to one of the directories, and you can define additional information. The USERDB blocks ID can be referenced in the database parameter of the ACL. If a virtual server has no USERDB blocks, user or group-based ACL fails.
USERDB tags define an additional layer of indirection between the database attribute of an ACL and dbswitch.conf. This layer of indirection adds the necessary protection for the server administrator to have full control over which databases virtual server administrators have access to.
For more information on USERDB, see “User Database Selection” in Chapter 2 of the Sun Java System Web Server 6.1 Administrator’s Configuration Reference.
Once you have defined one or more user authentication databases in the dbswitch.conf file, you can use the Class Manager to configure the databases for each of your virtual servers to use for authentication. You can also use the Class Manager to add a new database definition from the dbswitch.conf for the virtual server to authenticate against.
To specify which LDAP database or databases a virtual server should use, perform the following steps:
Access the Server Manager and select the Virtual Server Class tab.
Click the virtual server class link where you wish to specify the LDAP database listed under Tree View of the Server.
Select the Virtual Server tab, if not already selected.
Click the ACL Settings link.
The ACL Settings for Virtual Servers page is displayed.
Choose Edit from the drop-down list in the Option column, if not already displayed.
Select a database configuration from the drop-down list in the Database column for the virtual server you are editing.
Click OK.
Close the Edit ACL Files window.
Click Apply.
Choose Dynamically Apply.
ACLs for virtual servers are created for the server instances in which the virtual server resides. Virtual server ACL settings default to those created for the server instance. However, access control for each virtual server can be edited through the Class Manager. You would also use this method to add a newly created ACL file to a virtual server.
To edit ACL settings for a virtual server, perform the following steps:
Access the Server Manager and select the Virtual Server Class tab.
Click the Virtual Server Class link where you wish to specify the LDAP database listed under Tree View of the Server.
Select the Virtual Servers tab, if not already displayed.
Click the ACL Settings link.
Choose Edit or Delete from the drop-down list in the Option field for each virtual server that needs to be changed.
Click the Edit link in the ACL File field to display the available ACL files.
Select one or more ACL files to add or delete for the virtual server.
A virtual server can have multiple ACL files because they may have multiple document roots.
Choose the database to associate the ACL list with from the drop-down list.
(Optional) Enter the BaseDN.
Click OK when you have finished making changes.
Click Apply.
Select Dynamically Apply.
The Sun Java System Web Server 6.1 supports the use of file-based authentication databases, which store user and group information in text format in flat files. The ACL framework is designed to work with the file authentication database.
The Sun Java System Web Server 6.1 does not support dynamic flat files. The flat file database is loaded when the server starts up. Changes to the files come into effect only when the server restarts.
An ACL entry can refer to a user database using the database keyword. For example:
acl "default"; authenticate (user) { ... database="myfile"; ... };
The database myfile can be referenced in the USERDB element of a VS in server.xml where it is linked with a corresponding definition in the server-root/userdb/dbswitch.conf file. For example:
<VS> ... <USERDB id="myfile" database="myfiledb"> ... </VS>
In the server-root/userdb/dbswitch.conf file there is an entry which defines the auth-db file and its configuration. For example:
directory myfiledb file myfiledb:syntax keyfile myfiledb:keyfile /path/to/config/keyfile
The table bow
Table 9–2 Parameters supported by the File Authentication Database
syntax |
[Optional] Value is either keyfile, digest or htaccess. If not specified, defaults to keyfile. |
keyfile |
[Required if syntax=keyfile] Path to the file containing user data. |
digestfile |
[Required if syntax=digest] Path to the file containing user data for digest authentication. |
groupfile |
[Required if syntax=htaccess] Path to the AuthGroupFile. |
userfile |
[Required if syntax=htaccess] Path to the AuthUserFile. |
The maximum length of a line in a file authentication database file (htaccess, digestfile or keyfile) is 255.
If any line exceeds this limit, the server fails to start and an error is logged in the log file.
Ensure that the following pre-conditions are met before you attempt to set ACLs using a file-based authentication database:
A file-based authentication directory service is already configured. For information on how to do this, see Configuring a Directory Service.
The virtual server on which the ACLs are set, is configured to use the type of file-based authentication database (keyfile, htaccess or digestauth) you require. If this is not done, ACL restrictions will be configured against the directory service configured as default.
To create an ACL entry for a directory service based on file authentication, perform the following steps:
Access the Server Manager and select the server instance for which you want to create or edit ACLs for.
Choose the Preferences tab from the Server Manager.
Click the Restrict Access link.
From the Option column, choose the ACL file from the drop-down list and click Edit ACL.
In the Access Control Rules page in the top frame, click the Users/Groups link for the ACL you want to edit.
In the User/Group page in the bottom frame, from the Authentication database drop-down list, select keyfile.
Click Update.
When you set an ACL against a keyfile-based file authentication database, the dbswitch.conf file is updated with an ACL entry, like the sample entry given below:
version 3.0; acl "default"; authenticate (user) { prompt = "Sun One Web Server 6.1"; database = "mykeyfile"; method = "basic"; }; deny (all) user = "anyone"; allow (all) user = "all"; |
The Sun Java System Web Server provides support for .htaccess-based flat file authentication. If you have been using .htaccess authentication, you can migrate your existing data files with no change to the file authentication database. As noted in Using .htaccess Files, .htaccess user and group data can be stored in a single file or split into two files (one with user data and other with group data). Both existing formats are supported by the file authentication database.
To create an ACL for a directory service based on htaccess authentication, perform the following steps:
Access the Server Manager and select the server instance you wish to create or edit ACLs for.
Choose the Preferences tab from the Server Manager.
Click the Restrict Access link.
Under the Option column, choose the ACL file from the drop-down list and click Edit ACL.
In the Access Control Rules page in the top frame, click the Users/Groups link for the ACL you want to edit.
In the User/Group page in the bottom frame, from the Authentication database drop-down list, select htaccess.
Click Update.
When you set an ACL against an htaccess-based file authentication database, the dbswitch.conf file is updated with an ACL entry such as the sample entry given below:
version 3.0; acl "default"; authenticate (user) { prompt = "Sun One Web Server 6.1"; database = "myhtaccessfile"; method = "basic"; }; deny (all) user = "anyone"; allow (all) user = "all"; |
To migrate your existing .htaccess information to the file authentication database in the Sun Java System Web Server 6.1:
Copy your .htaccess userfile database to server-root/server-instance/config/userfile.
Copy your htaccess groupfile database to server-root/server-instance/config/groupfile
The user file format is as follows:
#user:password
The group file format is as follows:
#group1:user1 user2 #group2:user3 user4
Member names are separated by spaces.
When userfile and groupfile have the same file name, they are combined. each line of the combination follows the syntax shown below:
#user:password:group1,group2
Columns are separated by colons.
Sample 1
#sample userfile (user/password "j2ee/j2eepwd" user/password "user1/user1pwd" ) j2ee:9hmjfRwNxvJLU user1:wvQirF86BsjSk
Sample 2
#sample group file staff:j2ee user1 eng:j2ee
Sample 3
#sample user/group file (username "j2ee", user password "j2eepwd") j2ee:9hmjfRwNxvJLU:staff,eng
The file authentication database also supports a file format suitable for use with digest authentication per RFC 2617. A hash based on the password and realm is stored. Clear text passwords are not maintained.
To create an ACL for a directory service based on digestauth-based authentication, perform the following steps:
Access the Server Manager and select the server instance you wish to create or edit ACLs for.
Choose the Preferences tab from the Server Manager.
Click the Restrict Access link.
Under the Option column, choose the ACL file from the drop-down list and click Edit ACL.
In the Access Control Rules page in the top frame, click the Users/Groups link for the ACL you want to edit.
In the User/Group page in the bottom frame, from the Authentication database drop-down list, select digest.
Click Update.
When you set an ACL against a digestauth-based file authentication database, the dbswitch.conf file is updated with an ACL entry such as the sample entry given below:
version 3.0; acl "default"; authenticate (user) { prompt = "filerealm"; database = "mydigestfile"; method = "digest"; }; deny (all) user = "anyone"; allow (all) user = "all"; |