Allow
Description |
Define which servers can access a section of
the published content |
Synopsis
|
Allow from [all | host] |
Context |
Directory |
Example
|
<Directory /var/www/acme>
  Allow from www.acme.com
</Directory> |
The Allow directive is currently not implemented.
AuthDigestQop
Description |
Defines the quality of protection for Digest
authentication |
Synopsis
|
AuthDigestQop [none | auth | auth-int] |
Context |
Default Server, Virtual Host, Directory |
Example
|
AuthDigesteQop auth |
The AuthDigestQop directive specifies the desire quality
of protection to be employed by the AuthHandler when validating
user credentials. The following levels are supported:
- none -- No authentication
- auth -- Standard digest authentication
- auth-int --Use integrity checking via an MD5 hash of the
credentials. Not yet implemented.
The default level is "auth".
AuthGroupFile
Description |
Defines the name of the user group file for
authentication. |
Synopsis
|
AuthGroupFile path |
Context |
Default Server, Virtual Host, Directory |
Example
|
AuthGroupFile /var/lib/appweb/groups.db |
The AuthGroupFile directive defines the file for AppWeb
to use when validating user groups. The
path may be an absolute file name or it may be a path
relative to the ServerRoot.
Unlike Apache, AppWeb uses the same authorization file and format
for Digest and Basic authentication. This simplifies
administration. The file format is:
acmeUsers: coyote roadRunner
SECURITY WARNING: it is essential that the AuthGroupFile and the
AuthUserFile be stored outside the DocumentRoot or any directory
serving content.
AuthName
Description |
Defines the "Realm" of users to be permitted
access to this set of documents. |
Synopsis
|
AuthName realm |
Context |
Default Server, Virtual Host, Directory |
Example
|
AuthName "Acme Inc"
AuthType Basic
Require group employees
|
The AuthName directive defines a name that is used to
create a realm of access to AppWeb. Â Realms define discrete
regions of access to AppWeb. Any number of realms may be created,
but only one per context is allowed.
The
realm is usually presented by the
user's browser when prompting for a user name and password.Â
AuthType
Description |
Defines the type of authentication to
use. |
Synopsis
|
AuthType [Basic | Digest] |
Context |
Default Server, Virtual Host, Directory |
Example
|
AuthType Digest
AuthName "Acme Inc"
Require valid-user
|
The AuthType directive specifies the style of
authorization to perform when validating users.
SECURITY WARNING: Basic authentication is not very secure. It
will transmit your user credentials in a format that is very easy
for malicious individuals to expose. Unless you are also using
SSL, basic authentication is not recommended. If at all possible,
use Digest authentication rather than Basic.Â
AuthUserFile
Description |
Defines teh quality of protection for Digest
authentication |
Synopsis
|
AuthDigestQop [none | auth | auth-int] |
Context |
Default Server, Virtual Host, Directory |
Example
|
AuthDigesteQop auth |
The AuthUserFile directive defines the file for AppWeb to
use when validating user names. The
path
may be an absolute file name or it may be a path relative to the
ServerRoot.
Unlike Apache, AppWeb uses the same authorization file and format
for Digest and Basic authentication. This simplifies
administration. The file format is:
coyote:Realm:EncryptedPassword
The
Realm is the name specified via the
AuthName directive. The
EncryptedPassword
is an MD5 secure hash of the user name, realm and password. Use
the AppWeb utility
httpPassword to create
entries in the password file. Use an editor to delete entries by
deleting the relevant line.
SECURITY WARNING: it is essential that the AuthUserFile and
the AuthGroupFile be stored outside the DocumentRoot or any
directory serving content.
Deny
Description |
Defines which servers cannot access a
section of the published content. |
Synopsis
|
Deny [all | host] |
Context |
Default Server, Virtual Host, Directory |
Example
|
Deny www.acme.com |
The Deny directive is currently not implemented.
Order
Description |
Specifies the order in which the allow and
deny directives apply. |
Synopsis
|
Order allowSpec |
Context |
Default Server, Virtual Host, Directory |
Example
|
Order Deny,Allow
Deny from all
Allow from www.acme.com
|
The Order directive defines who the server access control
is applied. The
allowSpec may be either
"Deny,Allow" or "Allow,Deny". Note that no spaces may
appear between the words or after the comma.
Deny,Allow
The deny directive is applied first then the
allow directive. Requests that do not match the deny directive
and do match the allow directive will be permitted access. Access
is allowed by default if either the deny or allow directive is
ommitted.
Allow,Deny
The allow directive is applied first then the
deny directive. Requests that do not match the allow directive or
requests that match the deny directive will be denied. Access is
denied by default if either the deny or allow directive is
ommitted.
Examples
To only allow access for a specified domain,
www.acme.com:
Order Deny,Allow
Deny from All
Allow from www.acme.com
To deny access to a specific domain: www.myCompetitor.com
Order Allow,Deny
Allow from All
Deny from www.myCompetitor.com
Require
Description |
Defines which authenticated users will be
permitted access to a set of published content. |
Synopsis
|
Require user userName [userName]...
Require group groupName [groupName]...
Require valid-user
Require acl aclMask
|
Context |
Default Server, Virtual Host, Directory |
Example
|
AuthType Digest
AuthName "Cartoon Actors"
AuthUserFile "/var/appweb/users.db"
AuthGroupFile "/var/appweb/groups.db"
Require user coyote |
The Require directive defines which users can access a
set of resources. The directive may validate specific users, any
valid user, or groups of users. The users and groups are
specified via the
AuthUserFile and
AuthGroupFile directives.
The Require acl directive specifies an Access Control Mask which
defines a set of capabilities that must be satisfied to grant
access. ACLs are used to associated capabilities with users and
groups of users and to specifiy via the Require directive what
capabilities the user must posess to gain access. Typically each
bit in the ACL mask corresponds to a set of tasks or roles which
must be performed. For example: backup tasks could be associated
with the bit 0x10 in the ACLs.
ACLs are defined in the group authorization file where each group
has a specified ACL mask. A user may be in multiple groups and
their total ACL capabilities are the union (or) of all the group
masks for which they are a member. To be granted access, the
logical OR of the users ACL and the Required ACL must be
non-zero. For example, if the groups file contained:
1: 0x111: powerUsers: peter
1: 0x1: users: julie
And the Require directive was:
Require acl 0x10
Then, for Peter, the computed ACL is 0x111 | 0x10 which results
in 0x10 which is non-zero so Peter would be granted access.
Julie's computed ACL is 0x1 | 0x10 which results in 0 so Julie
would be denied access.
The entries in the group authorization file contain ACL
masks.