Editing Access Control Settings

You can protect resources that reside on your web server through several security services and mechanisms, including authentication, authorization, and access control.

Authentication is the process of confirming an identity. Authorization means granting access to a restricted resource to an identity, and access control mechanisms enforce these restrictions. Authentication and authorization can be enforced by a number of security models and services.

The following sections explain the process of configuring the security settings for the selected configuration.

Editing Authentication Databases

An Authentication Database, also referred to as auth-db, represents one database of known users and the mechanism for authenticating client requests against that database. The server can have multiple auth-db entries configured at the same time and these may be of the same type or different types or any combination. The auth-db user databases are used by the ACL engine. Note that the server also supports a different type of user database known as the Java Realm.

LDAP -- The user data is stored in any LDAP directory server, including Sun Java System Directory Server.
File -- The user data is stored in a disk file. This auth-db is particularly convenient for development or small deployments where no centralized user management is available (or desired). The file auth-db supports several different file formats:
- keyfile -- The keyfile format stores a list of users (and optional group memberships for each user). The password is stored as a one-way (unrecoverable) hash. This is the default format.
- digestfile -- The digestfile is very similar to the keyfile with the important distinction that it is also able to support the HTTP Digest authentication method.
- htaccess -- This is a legacy format only and should never be used for new installations or adding new users.
PAM -- PAM is the new auth-db supported by Sun Java System Web Server 7.0. The PAM auth-db delegates the authentication to the Solaris PAM stack, which allows existing Solaris users on the web server system to authenticate to the web server as well. Note that the PAM auth-db is only supported in Solaris 9 and 10 (or higher) and the web server instance must be running as root.

Editing Users and Groups

The Administration Server provides access to editing user accounts, group lists, access privileges, organization units, and other user- and group-specific information for both LDAP and File auth-db types.

User and group information is stored either in flat files in text format or in a directory server such as Sun Java System Directory Server, which supports Lightweight Directory Access Protocol (LDAP). LDAP is an open directory access protocol that runs over TCP/IP and is scalable to a global size and millions of entries.

A key file is a text file that contains the user's password in a hashed format, and the list of groups to which the user belongs. The users and groups stored in a key file are used for authorization and authentication by the file realm alone; these bear no relationship to system users and groups.

Procedure To Add a User

Select the configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Access Control > Users tab.
Click New button.
Add User Information.
Enter the user id and password. Optionally enter the group which the user belongs to. The user ID must be unique. In case of LDAP based authentication DB, the Administration Server ensures that the user ID is unique by searching the entire directory from the search base (base DN) down to see if the user ID is in use. Be aware, however, that if you use the Directory Server ldapmodify command line utility (if available) to create a user, it does not ensure unique user IDs.

Procedure To Add a Group

Select the configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Access Control > Groups tab.
Click New button.
Enter Group Name.
From the Add Users To Group section search and add existing users to the group.
Note - Creating a group in authentication database like keyfile or digestfile requires atleast one user to be specified.

Procedure To Delete a User

Select the configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Access Control > Users tab.
Select the authentication database from which you need to delete the user.
Enter the User ID in the Search Users text box and click Search button.
Select the user from the UserID column and click Delete button.
Caution - Deleting users(s) from keyfile/digestfile authentication databases will delete the associated group(s) as well if the group(s) contain no members after deletion of the user(s). This happens because groups without members are not allowed for keyfile/digestfile authentication databases.

Procedure To Delete a Group

Select the configuration.
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Access Control > Groups tab.
Select the authentication database from which you need to delete the group.
Enter the User ID in the Search Users text box and click Search button.
Select the user from the UserID column and click Delete button.
Note - Deleting a group does not delete the users belonging to the group. You have to delete the users manually or reassign groups.

Editing Access Control

The server supports authentication and authorization through the use of locally stored access control lists (ACLs), which describe what access rights a user has for a resource. For example, an entry in an ACL can grant a user named John read permission to a particular folder, misc.

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.

The core ACLs supported by the server are three types of authentication: basic, SSL, and digest.

For editing access control settings, perform the following tasks:

Click Configurations tab and select the configuration.
Click Access Control tab > Access Control List sub tab.
Click New button to add a new ACL or click existing ACL to edit the settings.

Adding a new ACL

The following section describes the process of adding a new ACL to the configuration.

Click Configurations tab and select the configuration.
Click Access Control tab > Access Control List sub tab.
Click New button to add a new ACL.

The following table described the fields in the Add new ACL page.

Table 18 Field Description > Add ACL

Field	Description
Resource	Named/URI/Path Select the type of resource you need to set access restriction and specify the value. Example for URI resource -- "/sales" Example for Path resource -- *"/usr/sun/server4/docs/cgi-bin/"**
Authentication DB	Authentication Database lets you select a database the server will use to authenticate users. The default is keyfile
Authentication Method	Basic -- uses the HTTP Basic method to get authentication information from the client. The username and password are only encrypted over the network if SSL 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 an authentication mechanism that provides a way for a browser to authenticate based on username and password without sending the username and password as clear text. The browser uses the MD5 algorithm to create a digest value using the user's password and some information provided by the Web Server. Note that in order to use Digest the underlying auth-db must support digest as well. This means either a File auth-db using digestfile or an LDAP auth-db only if the Digest Authentication Plug-In has been installed Other -- uses a custom method created using the access control API.
Prompt for Authentication	Prompt for Authentication option 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 browser, the user will see about first 40 characters of the prompt. Web browsers typically 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 won't need to be entered again. If you want users to authenticate again for specific files and directories, you simply need to change the prompt for the ACL on that resource.
Denied Access Response	Specify the response action when an access to a resource is denied. 1. Respond with default message -- Select this option for displaying the standard access denied message from the server. 2. Respond with URL -- Select this option for forwarding the request to any other external URL or error page.

Adding a New ACE

The section describes the process of adding a new Access Control Entry (ACE) for the selected configuration.

Click Configurations tab and select the configuration.
Click Access Control tab > Access Control List > New button.
Under Access Control Entry, click New button to add a new ACE.

The following table describes the fields in the New ACE wizard page.

Table 19 Field Description > Adding a New ACE

Field	Description
Action	Allow means users or systems can access the requested resource Deny means users or systems cannot access the resource The server goes through the list of Access Control Expressions (ACEs) to determine the access permissions.
Users	1. Anyone -- No authentication. Grants access to everyone. 2. All in the Auth DB -- Grants access to all users specified in the authentication database. 3. Only the following in the Auth DB -- Restrict access to selected users from the authentication DB. You can query the authentication DB based on common attributes like First name, Last name and Email address.
Groups	With group authentication, users are prompted to enter a username and password before they can access the resource specified in the access control rule. Use this option to restrict access to specific groups.
From Host	You can restrict access to the Administration Server or your web site based on which computer the request comes from. Anyplace allows access to all users and systems Only from 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 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 will 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. When the `` appears in an IP address, it must be the right-most character. For example, `198.` is acceptable, but not `198..251.30`.
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 allow 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 will allow or deny 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 the HTTP methods GET, HEAD, POST, and INDEX Write allows users to change or delete files, including the HTTP methods PUT, DELETE, MKDIR, RMDIR, and MOVE. To delete a file, a user must have both write and delete rights Execute allows users to execute server-side applications, such as CGI programs, Java applets, and agents Delete allows users who also have write privileges to delete files or directories. List allows users to access lists of the files in directories that don't contain an `index.html` file. Info allows users to receive information about the URI, for example `http_head`.
Continue	The server goes through 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, the next ACE is used. If continue is not checked, everyone will 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.

Also see Adding a new ACL