This module provides core authorization capabilities so that
authenticated users can be allowed or denied access to portions
of the web site.
Extended authorization providers can be created within the configuration
file and assigned an alias name. The alias providers can then be referenced
through the
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 authorization container directives
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 group and the Administrators LDAP
group and either belong to the sales group or
have the LDAP dept attribute sales.
Furthermore, in order to access the resource, the user must
not belong to either the temps group or the
LDAP group Temporary Employees.
The env provider allows access to the server
to be controlled based on the existence of an environment variable. When Require
env env-variable is specified, then the request is
allowed access if the environment variable env-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
User-Agent (browser type), Referer, or
other HTTP request header fields.
In this case, browsers with a user-agent string beginning
with KnockKnock/2.0 will be allowed access, and all
others will be denied.
The all provider mimics the functionality the
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.
The method provider allows to use 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:
The expr provider allows to base authorization
decisions on arbitrary expressions.
The syntax is described in the ap_expr documentation.
This directive tests whether an authenticated user is authorized
according to a particular authorization provider and the specified
restrictions.
Require all grantedRequire all deniedRequire env env-var [env-var]
...Require method http-method [http-method]
...Require expr expression Some of the allowed syntaxes provided by
Require user userid [userid]
...Require group group-name [group-name]
...Require valid-userRequire ip 10 172.20 192.168.2Other authorization modules that implement require options
include
In most cases, for a complete authentication and authorization
configuration,
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
The result of the not option. As with the other negated authorization
directive
In the following example, all users in the alpha
and beta groups are authorized, except for those who
are also in the reject group.
When multiple
</RequireAll> are used to enclose a group of
authorization directives of which none must fail and at least one
must succeed in order for
the
If none of the directives contained within the
</RequireAny> are used to enclose a group of
authorization directives of which one must succeed in order for
the
If one or more of the directives contained within the
</RequireNone> are used to enclose a group of
authorization directives of which none must succeed
in order for the
If one or more of the directives contained within the
Require not,
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.
When authorization is enabled, it is normally inherited by each
subsequent configuration section,
unless a different set of authorization directives are specified.
This is the default action, which corresponds to an explicit setting
of AuthMerging Off.
However, there may be circumstances in which is it 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
and Or.
When a configuration section contains AuthMerging And
or AuthMerging Or,
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
alpha
may access /www/docs. Users belonging to either
groups alpha or beta may access
/www/docs/ab. However, the default Off
setting of /www/docs/ab/gamma, so
that section's authorization directives override those of the
preceding sections. Thus only users belong to the group
gamma may access /www/docs/ab/gamma.</AuthzProviderAlias> are used to enclose a group of
authorization directives that can be referenced by the alias name using the
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.
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.