Authorization Directives

Authorization directives manage user authentication and server access control.

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.example.com
</Directory>
Notes The Allow directive is currently not implemented.

AuthAutoLogin

Description Automatically login as the designated user
Synopsis AuthAutoLogin username
Context Default Server, Virtual Host, Route
Example AuthAutoLogin peter
Notes

The AuthAutoLogin directive automatically logs in as the specified user. This is useful for development to avoid having to enter the user credentials for each debug session.

AuthDigestQop

Description Defines the quality of protection for Digest authentication
Synopsis AuthDigestQop [none | auth | auth-int]
Context Default Server, Virtual Host, Route
Example AuthDigesteQop auth
Notes

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".

AuthStore

Description Defines the password store for user and password credentials.
Synopsis AuthStore [file | system]
Context Default Server, Virtual Host, Route
Example AuthStore system
Notes

The AuthStore directive defines where Appweb can access user credentials for authenticating users and their passwords.

The "file" authentication method uses users credentials defined via the User directive and then stored internally in Appweb. These User directives are typically stored in a separate authentication configuration file that is included by appweb.conf. The authpass program can be used to create encrypted User passwords in the authentication file.

The "system" option selects the default system password database. On Unix, the Plugable Authentication Modules (PAM) method is used. Windows ActiveDirectory is not yet supported.

AuthType

Description Defines the type of authentication to use.
Synopsis AuthType [basic | digest | none] [realm]
AuthType form realm login-page [login-service logout-service logged-in-page]
Context Default Server, Virtual Host, Route
Example AuthType basic example.com
AuthType form example.com https:///admin/login.esp -
    https:///login /logout /home.html
Require ability modify
Notes

The AuthType directive specifies the style of authorization to perform when validating users. If a route block does not define, the AuthType is inherited from outer routes in the config file.

All forms of the AuthType directive specify an authentication realm. The realm is included as an ingredient when encrypting passwords via the authpass program. For basic and digest authentication, this realm is also displayed by the browser when the user logs in.

The "AuthType form" authentication directive has extra arguments after the realm. These are four URIs to control the login and logout sequence. These are:

  1. login-page — Unauthenticated users are redirected to this URI to log in
  2. login-service-page — URI to receive the login POST request from the client
  3. logout-service-page — URI to receive the logout request from the client
  4. logged-in-page — Authenticated users are redirected to this URI after logging in
Security

Basic authentication is not very secure. It will transmit user credentials in a format that is very easy for malicious individuals to exploit. If using basic authentication, you should use SSL to encrypt the transmission of the password.

Deny

Description Defines servers to deny access to content
Synopsis Deny [all | host]
Context Default Server, Virtual Host, Route
Example Deny www.example.com
Notes 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, Route
Example Order Deny,Allow
Deny from all
Allow from www.example.com
Notes

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 omitted.

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 omitted.

Examples

To only allow access for a specified domain, www.example.com:

Order Deny,Allow
Deny from All
Allow from www.example.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 the required users and abilities to permitted access
Synopsis Require user username...
Require secure [age=secs] [domains]
Require ability name...
Context Default Server, Virtual Host, Route
Examples Require user julie Require ability manage Require secure
Notes

The Require directive defines which users can access a set of resources. The directive may specify a set of users by name, or a set of abilities that users must possess before being granted access. In the absence of a require directive, any valid user will be permitted access. The Require ability directive specifies a list of ability words. These are typically verbs such as "view", "manage", "edit", and the like.

The Require secure directive specifies that access must be performed over a secure protocol using SSL/TLS. If an age is provided, a Strict-Transport-Security response header will be emitted. This instructs browsers that all connections thereafter must only request over HTTPS. This applies to the current and all future browser sessions to this domain up to the specified lifespan. If the domains attribute is specified, then the Strict-Transport-Security header will apply to all sub-domains.

The Require directive is inherited from outer hosts and blocks in the config file.

Role

Description Defines an authentication role with associated abilities.
Synopsis Role name abilities...
Context Default Server, Virtual Host, Route
Example Role administrator view edit
Notes

The Role directive defines a role with associated abilities. Roles may be specified by the User directive to specify a set of abilities for the user.

Role names are typically nouns such as: user, administrator, manager and the like.

Security

Role directives are typically kept in a separate authentication configuration file with User directives that is included from the main appweb.conf file. It is essential that any configuration file containing Role or User directives be stored outside the DocumentRoot or any directory serving content.

User

Description Defines a user with password and abilities.
Synopsis User name password abilities...
Context Default Server, Virtual Host, Route
Example User julie 9d8873a123eb506e7f8e84d1f2a26916 view
Notes

The User directive defines a user for use with the internal AuthType. The user definition includes an encrypted password and a set of abilities. Multiple users can be defined.

The user abilities are words that may be specified by Require directives to restrict access to those users possessing the required abilities.

Security

User directives are typically kept in a separate authentication configuration file that is included from the main appweb.conf file. It is essential that any configuration file containing User directives be stored outside the DocumentRoot or any directory serving content.

© Embedthis Software, 2003-2015. All rights reserved.