Configuring 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.
To edit access control settings, perform the following tasks:
-
Click theConfigurations tab and select the configuration.
-
Click theSecurity sub tab > Access Control sub tab.
-
Click theAdd ACL button to add a new ACL or click existing ACL to edit the settings.
Adding an Access Control List (ACL)
The following section describes the process of adding a new ACL to the
configuration.
-
Click the Configurations tab and select the configuration.
-
Click theAccess Control sub tab > Access Control Lists sub tab.
-
Click theNew button to add a new ACL.
Configure the following parameters:
Table 7–2 ACL Parameters
Parameter
|
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 obtain 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 must
be present 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 enables 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 the
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 server files and directories with 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 to display the standard
access denied message from the server.
2. Respond with URL — Select this option to forward the request
to any other external URL or error page.
|
Note –
Using CLI
To add an ACL through the CLI, execute
the following command.
wadm> set-acl --user=admin --password-file=admin.pwd
--host=serverhost --port=8989 --vs=config1_vs_1 --config=config1
--aclfile=aclfile1
|
See CLI Reference, set-acl(1).
Adding an Access Control Entry (ACE)
The section describes the process of adding a new Access Control Entry
(ACE) for the selected configuration.
-
Click theConfigurations tab and select the configuration.
-
Click theAccess Control sub tab > Access Control List sub tab.
-
Click the New button.
-
Click theNew button under Access Control Entry.
Configure the following ACE parameters:
Table 7–3 ACE parameters
Parameter
|
Description
|
Access
|
-
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.
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 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 enables 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.
|
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.
|