Authorization Directives

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.