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.
This directive tests whether an authenticated user is authorized
according to a particular authorization provider and the specified
restrictions. Some of the allowed syntaxes provided by
Require user userid [userid]
...Require group group-name [group-name]
...Require valid-userOther authorization modules that implement require options
include
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