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.