Apache HTTP Server Version 2.3
Apache HTTP Server Version 2.3
Available Languages: en
| Description: | Core Authorization |
|---|---|
| Status: | Base |
| Module Identifier: | authz_core_module |
| Source File: | mod_authz_core.c |
| Compatibility: | Available in Apache 2.3 and later |
This module provides core authorization capabilities so that
authenticated users can be allowed or denied access to portions
of the web site. mod_authz_core provides the
functionality to register various authorization providers. It is
usually used in conjunction with an authentication
provider module such as mod_authn_file and an
authorization module such as mod_authz_user. It
also allows for advanced logic to be applied to the
authorization processing.
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 and
Match directives
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 reference by multiple locations.
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:
<AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx>
AuthLDAPBindDN cn=youruser,o=ctx
AuthLDAPBindPassword yourpassword
AuthLDAPURL ldap://ldap.host/o=ctx
</AuthzProviderAlias>
<AuthzProviderAlias ldap-group ldap-group-alias2
cn=my-other-group,o=dev>
AuthLDAPBindDN cn=yourotheruser,o=dev
AuthLDAPBindPassword yourotherpassword
AuthLDAPURL ldap://other.ldap.host/o=dev?cn
</AuthzProviderAlias>
Alias /secure /webpages/secure
<Directory /webpages/secure>
Order deny,allow
Allow from all
AuthBasicProvider file
AuthType Basic
AuthName LDAP_Protected_Place
#implied OR operation
Require alias1-ldap-group
Require alias2-ldap-group
</Directory>
The authorization container directives
<MatchAll>,
<MatchAny>,
<MatchNotAll>
and
<MatchNotAny>
may be combined with each other and with the
Match
directive to express complex authorization logic.
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.
<Directory /www/mydocs>
<MatchAny>
Match user superadmin
<MatchAll>
Match group admins
Match ldap-group cn=Administrators,o=Airius
<MatchAny>
Match group sales
Match ldap-attribute dept="sales"
</MatchAny>
</MatchAll>
</MatchAny>
<MatchNotAny>
Match group temps
Match ldap-group cn=Temporary Employees,o=Airius
</MatchNotAny>
</Directory>
| Description: | Enclose a group of directives that represent an extension of a base authorization provider and referenced by the specified alias |
|---|---|
| Syntax: | <AuthzProviderAlias baseProvider Alias Require-Parameters>
... </AuthzProviderAlias>
|
| Context: | server config |
| Status: | Base |
| Module: | mod_authz_core |
<AuthzProviderAlias> and
</AuthzProviderAlias> are used to enclose a group of
authorization directives that can be referenced by the alias name using the
directive Require.
| Description: | Tests whether an authenticated user is authorized by an authorization provider. |
|---|---|
| Syntax: | Match [not] entity-name
[entity-name] ... |
| Context: | directory, .htaccess |
| Override: | AuthConfig |
| Status: | Base |
| Module: | mod_authz_core |
This directive is similar to the
Require directive;
it tests whether an authenticated user is authorized according to
a particular authorization provider and the specified restrictions.
Unlike the Require
directive, it may be used with and inside authorization container
directives such as
<MatchAll>.
Furthermore, its result may be negated through the use of the
not option. As with other negated authorization directives,
in this case the Match directive may only
either fail or return a neutral result, and can therefore never
independently authorize a request.
In the following example, all users in the alpha
and beta groups are authorized, except for those who
are also in the reject group.
<Directory /www/docs>
Match group alpha beta
Match not group reject
</Directory>
When multiple Match directives are
used in a single
configuration section
and are not contained in another authorization directive like
<MatchAny>,
they are implicitly contained within a
<MatchAll>
directive. Thus for the user to be authorized, all such
Match directives must not fail, and
at least one must be successful.
Match directives may not be combined
with the Require
directive.| Description: | Enclose a group of authorization directives of which none must fail and at least one must succeed for the enclosing directive to succeed. |
|---|---|
| Syntax: | <MatchAll>
... </MatchAll> |
| Context: | directory, .htaccess |
| Override: | AuthConfig |
| Status: | Base |
| Module: | mod_authz_core |
<MatchAll> and
</MatchAll> are used to enclose a group of
authorization directives of which none must fail and at least one
must succeed in order for
the <MatchAll> directive to
succeed.
If none of the directives contained within the
<MatchAll> directive fails,
and at least one succeeds, then the
<MatchAll> directive
succeeds. If none succeed and none fail, then it returns a
neutral result. In all other cases, it fails.
| Description: | Enclose a group of authorization directives of which one must succeed for the enclosing directive to succeed. |
|---|---|
| Syntax: | <MatchAny>
... </MatchAny> |
| Context: | directory, .htaccess |
| Override: | AuthConfig |
| Status: | Base |
| Module: | mod_authz_core |
<MatchAny> and
</MatchAny> are used to enclose a group of
authorization directives of which one must succeed in order for
the <MatchAny> directive to
succeed.
If one or more of the directives contained within the
<MatchAny> directive succeed,
then the <MatchAny> directive
succeeds. If none succeed and none fail, then it returns a
neutral result. In all other cases, it fails.
<MatchAny>
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 <MatchAny>
directive.| Description: | Enclose a group of authorization directives of which some must fail or none must succeed for the enclosing directive to not fail. |
|---|---|
| Syntax: | <MatchNotAll>
... </MatchNotAll> |
| Context: | directory, .htaccess |
| Override: | AuthConfig |
| Status: | Base |
| Module: | mod_authz_core |
<MatchNotAll> and
</MatchNotAll> are used to enclose a group of
authorization directives of which some must fail or none must succeed
in order for the
<MatchNotAll> directive to
not fail.
If none of the directives contained within the
<MatchNotAll> directive
fail, and one or more succeed, then the
<MatchNotAll> directive fails.
In all other cases, it returns a neutral result. Thus as with
the other negated authorization directives, 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.
| Description: | Enclose a group of authorization directives of which none none must succeed for the enclosing directive to not fail. |
|---|---|
| Syntax: | <MatchNotAny>
... </MatchNotAny> |
| Context: | directory, .htaccess |
| Override: | AuthConfig |
| Status: | Base |
| Module: | mod_authz_core |
<MatchNotAny> and
</MatchNotAny> are used to enclose a group of
authorization directives of which none must succeed
in order for the
<MatchNotAny> directive to
not fail.
If one or more of the directives contained within the
<MatchNotAny> directive succeed,
then the <MatchNotAny> directive
fails. In all other cases, it returns a neutral result. Thus as with
the other negated authorization directives, 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.
<MatchNotAny>
directive. Therefore negated authorization directives
are not permitted within a
<MatchNotAny> directive.| Description: | Controls the manner in which each configuration section's authorization logic is combined with that of preceding configuration sections. |
|---|---|
| Syntax: | MergeAuthz Off | MatchAll | MatchAny |
| Default: | MergeAuthz Off |
| Context: | directory, .htaccess |
| Override: | AuthConfig |
| Status: | Base |
| Module: | mod_authz_core |
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 MergeAuthz 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, MatchAll
and MatchAny.
When a configuration section contains AuthzMerge MatchAll
or AuthzMerge MatchAny,
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
<MatchAll> or
<MatchAny>
directive, respectively.
AuthzMerge 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. Users belonging to either
groups alpha or beta may access
/www/docs/ab. However, the default Off
setting of AuthzMerge applies to the
<Directory>
configuration section for /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.
<Directory /www/docs>
AuthType Basic
AuthName Documents
AuthBasicProvider file
AuthUserFile /usr/local/apache/passwd/passwords
Match group alpha
</Directory>
<Directory /www/docs/ab>
AuthzMerge MatchAny
Match group beta
</Directory>
<Directory /www/docs/ab/gamma>
Match group gamma
</Directory>
| Description: | Tests whether an authenticated user is authorized by an authorization provider. |
|---|---|
| Syntax: | Require entity-name [entity-name] ... |
| Context: | directory, .htaccess |
| Override: | AuthConfig |
| Status: | Base |
| Module: | mod_authz_core |
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
mod_authz_user and
mod_authz_groupfile are:
Require user userid [userid]
...Require group group-name [group-name]
...Require valid-userOther authorization modules that implement require options
include mod_authnz_ldap,
mod_authz_dbm, mod_authz_dbd,
mod_authz_host, and
mod_authz_owner.
For a complete authentication and authorization configuration,
Require must be accompanied by
AuthName, AuthType and
AuthBasicProvider or
AuthDigestProvider
directives, and directives such as
AuthUserFile
and AuthGroupFile (to
define users and groups) in order to work correctly. Example:
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 statement into a
<Limit>
section.
When multiple Require directives are
used in a single
configuration section,
the first one to authorize a user authorizes the entire request,
and subsequent Require directives are
ignored. In other words, all Require directives
are enclosed in an implied <MatchAny> directive.
Require directives may not be combined
with the Match directive
or any authorization container directives, such as
<MatchAll>.Available Languages: en