mod_authz_core
Core Authorization
Base
mod_authz_core.c
authz_core_module
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.

# 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 allows the same extended authorization provider to be reference by multiple locations.

## Example

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:

### Example

<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 ldap-group-alias1
Require ldap-group-alias2
</Directory>

# Authorization Containers

The authorization container directives RequireAll, RequireAny and RequireNone may be combined with each other and with the Require 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> <RequireAll> <RequireAny> Require user superadmin
<RequireAll> Require group admins
Require ldap-group cn=Administrators,o=Airius
<RequireAny> Require group sales
Require ldap-attribute dept="sales" </RequireAny> </RequireAll> </RequireAny>
<RequireNone> Require group temps
Require ldap-group cn=Temporary Employees,o=Airius </RequireNone> </RequireAll> </Directory>
Require
Tests whether an authenticated user is authorized by an authorization provider.
Require [not] entity-name [entity-name] ...
directory
.htaccess
AuthConfig

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] ...`
  Only the named users can access the resource.
`Require group group-name [group-name] ...`
  Only users in the named groups can access the resource.
`Require valid-user`
  All valid users can access the resource.

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

The result of the Require directive may be negated through the use of the `not` option. As with the other negated authorization directive RequireNone, when the Require directive is negated it can only fail or return a neutral result, and therefore may 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> <RequireAll> Require group alpha beta
Require not group reject </RequireAll> </Directory>

When multiple Require directives are used in a single configuration section and are not contained in another authorization directive like RequireAll, they are implicitly contained within a RequireAny directive. Thus the first one to authorize a user authorizes the entire request, and subsequent Require directives are ignored.

Authentication, Authorization, and Access Control
Authorization Containers
mod_authn_core
mod_authz_host
RequireAll
Enclose a group of authorization directives of which none must fail and at least one must succeed for the enclosing directive to succeed.
<RequireAll> ... </RequireAll>
directory
.htaccess
AuthConfig

RequireAll and `</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 RequireAll directive to succeed.

If none of the directives contained within the RequireAll directive fails, and at least one succeeds, then the RequireAll directive succeeds. If none succeed and none fail, then it returns a neutral result. In all other cases, it fails.

Authorization Containers
Authentication, Authorization, and Access Control
RequireAny
Enclose a group of authorization directives of which one must succeed for the enclosing directive to succeed.
<RequireAny> ... </RequireAny>
directory
.htaccess
AuthConfig

RequireAny and `</RequireAny>` are used to enclose a group of authorization directives of which one must succeed in order for the RequireAny directive to succeed.

If one or more of the directives contained within the RequireAny directive succeed, then the RequireAny directive succeeds. If none succeed and none fail, then it returns a neutral result. In all other cases, it fails.

Because negated authorization directives are unable to return a successful result, they can not significantly influence the result of a RequireAny 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 RequireAny directive.

Authorization Containers
Authentication, Authorization, and Access Control
RequireNone
Enclose a group of authorization directives of which none must succeed for the enclosing directive to not fail.
<RequireNone> ... </RequireNone>
directory
.htaccess
AuthConfig

RequireNone and `</RequireNone>` are used to enclose a group of authorization directives of which none must succeed in order for the RequireNone directive to not fail.

If one or more of the directives contained within the RequireNone directive succeed, then the RequireNone directive fails. In all other cases, it returns a neutral result. Thus as with the other negated authorization directive `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.

Because negated authorization directives are unable to return a successful result, they can not significantly influence the result of a RequireNone directive. Therefore negated authorization directives are not permitted within a RequireNone directive.

Authorization Containers
Authentication, Authorization, and Access Control
AuthMerging
Controls the manner in which each configuration section's authorization logic is combined with that of preceding configuration sections.
AuthMerging Off | And | Or
AuthMerging Off
directory
.htaccess
AuthConfig

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 RequireAll or RequireAny directive, respectively.

The setting of AuthMerging 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 AuthMerging 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
Require group alpha </Directory>
<Directory /www/docs/ab> AuthMerging Or
Require group beta </Directory>
<Directory /www/docs/ab/gamma> Require group gamma </Directory>
AuthzProviderAlias
Enclose a group of directives that represent an extension of a base authorization provider and referenced by the specified alias
<AuthzProviderAlias baseProvider Alias Require-Parameters> ... </AuthzProviderAlias>
server config

AuthzProviderAlias and `</AuthzProviderAlias>` are used to enclose a group of authorization directives that can be referenced by the alias name using the directive Require.