Apache Module mod_authz_core
This module provides core authorization capabilities so that authenticated users can be allowed or denied access to portions of the web site.
provides the functionality to register various authorization providers. It is usually used in conjunction with an authentication provider module such as modauthzcore
. It also allows for advanced logic to be applied to the authorization processing.modauthzuser
directive in the same way as a base authorization provider. Besides the ability to create and alias an extended provider, it also allows the same extended authorization provider to be referenced by multiple locations. Require
The example below creates two different ldap authorization provider aliases based on the ldap-group authorization provider. This example allows a single authorization location to check group membership within multiple ldap hosts:
The example below expresses the following authorization logic. In order to access the resource, the user must either be the superadmin
user, or belong to both the admins
. Furthermore, in order to access the resource, the user must not belong to either the temps
group or the LDAP group Temporary Employees
provider allows access to the server to be controlled based on the existence of an environment variable. When Require env
is specified, then the request is allowed access if the environment variable env-variableenv-variable exists. The server provides the ability to set environment variables in a flexible way based on characteristics of the client request using the directives provided by
. Therefore, this directive can be used to allow access based on such factors as the clients mod_setenvifUser-Agent
, or other HTTP request header fields.
SetEnvIf User-Agent ^KnockKnock/2\.0 letmein
In this case, browsers with a user-agent string beginning with KnockKnock/2.0
When the server looks up a path via an internal subrequest such as looking for a
or generating a directory listing with DirectoryIndex
, per-request environment variables are mod_autoindexnot inherited in the subrequest. Additionally,
directives are not separately evaluated in the subrequest due to the API phases SetEnvIf
takes action in.mod_setenvif
provider mimics the functionality that was previously provided by the 'Allow from all' and 'Deny from all' directives. This provider can take one of two arguments which are 'granted' or 'denied'. The following examples will grant or deny access to all requests.
provider allows using the HTTP method in authorization decisions. The GET and HEAD methods are treated as equivalent. The TRACE method is not available to this provider, use
The following example will only allow GET, HEAD, POST, and OPTIONS requests:
The following example will allow GET, HEAD, POST, and OPTIONS requests without authentication, and require a valid user for all other methods:
provider allows basing authorization decisions on arbitrary expressions.
Require expr "%{TIMEHOUR} -ge 9 && %{TIMEHOUR} -le 17"
The syntax is described in the ap_expr documentation.
Normally, the expression is evaluated before authentication. However, if the expression returns false and references the variable %{REMOTE_USER}
However, there may be circumstances in which it is desirable for a configuration section's authorization to be combined with that of its predecessor while configuration sections are being merged. Two options are available for this case, And
, its authorization logic is combined with that of the nearest predecessor (according to the overall order of configuration sections) which also contains authorization logic as if the two sections were jointly contained within a
is not inherited outside of the configuration section in which it appears. In the following example, only users belonging to group alpha
may access /www/docs/ab
, so that section's authorization directives override those of the preceding sections. Thus only users belong to the group gamma
.
allows to change the response code to '403 FORBIDDEN'.
Modifying the response in case of missing authorization weakens the security of the password, because it reveals to a possible attacker, that his guessed password was right.
Require [not] entity-name [entity-name] ...
Require user userid [userid] ...
Require ip 10 172.20 192.168.2
Other authorization modules that implement require options include
In most cases, for a complete authentication and authorization configuration, Require
(to define users and groups) in order to work correctly. Example:AuthGroupFile
AuthType Basic AuthName "Restricted Resource" AuthBasicProvider file AuthUserFile /web/users AuthGroupFile /web/groups Require group admin
Access controls which are applied in this way are effective for all methods. This is what is normally desired. If you wish to apply access controls only to specific methods, while leaving other methods unprotected, then place the Require
option. As with the other negated authorization
directive
directive is negated it can only fail or return a neutral result, and therefore may never independently authorize a request.
groups are authorized, except for those who are also in the reject
directives are used in a single configuration section and are not contained in another authorization directive like
directive. Thus the first one to authorize a user authorizes the
entire request, and subsequent
Exercise caution when setting authorization directives in
sections that overlap with content served out of the filesystem. By default, these Locationconfiguration sections overwrite authorization configuration in
directive. (At most they could cause the directive to fail in
the case where they failed and all other directives returned a
neutral value.) Therefore negated authorization directives
are not permitted within a
, it can never independently authorize a request because it can never return a successful result. It can be used, however, to restrict the set of users who are authorized to access a resource.
Modules | Directives | FAQ | Glossary | Sitemap
Apache HTTP Server Version 2.4
Apache Module mod_authz_core
Available Languages: en | fr
Creating Authorization Provider Aliases
Extended authorization providers can be created within the configuration file and assigned an alias name. The alias providers can then be referenced through the Require directive in the same way as a base authorization provider. Besides the ability to create and alias an extended provider, it also a
Authorization Containers
The authorization container directives
The Require Directives
mod_authz_core provides some generic authorization providers which can be used with the Require directive.
AuthMerging Directive
When authorization is enabled, it is normally inherited by each subsequent configuration section, unless a different set of authorization directives is specified. This is the default action, which corresponds to an explicit setting of AuthMerging Off.
Directive
AuthzSendForbiddenOnFailure Directive
If authentication succeeds but authorization fails, Apache HTTPD will respond with an HTTP response code of '401 UNAUTHORIZED' by default. This usually causes browsers to display the password dialogue to the user again, which is not wanted in all situations. AuthzSendForbiddenOnFailure allows to cha
Require Directive
This directive tests whether an authenticated user is authorized according to a particular authorization provider and the specified restrictions. mod_authz_core provides the following generic authorization providers: