Модуль Apache mod_authz_core

Директива AuthMerging

AuthMerging Off | And | Or

AuthMerging Off

Если авторизация включена, обычно она наследуется каждым последующим разделом конфигурации, если только в нём не указан другой набор директив авторизации. Это действие используется по умолчанию и соответствует явной настройке AuthMerging Off.

Однако в некоторых случаях желательно при объединении разделов конфигурации объединить авторизацию одного раздела с авторизацией предшествующего ему раздела. Для этого доступны два варианта: And и Or.

Если раздел конфигурации содержит AuthMerging And или AuthMerging Or, его логика авторизации объединяется с логикой ближайшего предшествующего раздела (в соответствии с общим порядком разделов конфигурации), который также содержит логику авторизации, как если бы оба раздела совместно находились соответственно внутри директивы <RequireAll> или <RequireAny>.

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

<AuthzProviderAlias baseProvider Alias Require-Parameters> ... </AuthzProviderAlias>

<AuthzProviderAlias> и </AuthzProviderAlias> используются для заключения группы директив авторизации, на которую можно ссылаться по имени псевдонима с помощью директивы Require.

Если в Require-Parameters требуется несколько параметров, их необходимо заключить в кавычки. В противном случае будет учтён только первый параметр.

# In this example, for both addresses to be taken into account, they MUST be enclosed
# between quotation marks
<AuthzProviderAlias ip reject-ips "XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY">
</AuthzProviderAlias>

<Directory "/path/to/dir">
    <RequireAll>
        Require not reject-ips
        Require all granted
    </RequireAll>
</Directory>

Директива AuthzSendForbiddenOnFailure

AuthzSendForbiddenOnFailure On|Off

AuthzSendForbiddenOnFailure Off

Если аутентификация проходит успешно, но авторизация завершается неудачей, Apache HTTPD по умолчанию отвечает кодом HTTP '401 UNAUTHORIZED'. Обычно это заставляет браузеры снова отображать пользователю диалоговое окно ввода пароля, что не всегда желательно. AuthzSendForbiddenOnFailure позволяет изменить код ответа на '403 FORBIDDEN'.

Директива Require

Require [not] entity-name [entity-name] ...

Эта директива проверяет, имеет ли аутентифицированный пользователь разрешение согласно определённому поставщику авторизации и указанным ограничениям. mod_authz_core предоставляет следующие универсальные поставщики авторизации:

Require all granted

Доступ разрешён безусловно.

Require all denied

Доступ безусловно запрещён.

Require env env-var [env-var] ...

Доступ разрешён, только если задана одна из указанных переменных окружения.

Require method http-method [http-method] ...

Доступ разрешён только для указанных методов HTTP.

Require expr expression

Доступ разрешён, если expression принимает значение true.

Ниже приведены некоторые допустимые варианты синтаксиса, предоставляемые mod_authz_user, mod_authz_host и mod_authz_groupfile:

Require user userid [userid] ...

Доступ к ресурсу могут получить только указанные пользователи.

Require group group-name [group-name] ...

Доступ к ресурсу могут получить только пользователи из указанных групп.

Require valid-user

Доступ к ресурсу могут получить все действительные пользователи.

Require ip 10 172.20 192.168.2

Доступ к ресурсу могут получить клиенты из указанных диапазонов IP-адресов.

Require forward-dns dynamic.example.org

Доступ будет разрешён клиенту, IP-адрес которого определяется по имени dynamic.example.org.

К другим модулям авторизации, реализующим параметры require, относятся mod_authnz_ldap, mod_authz_dbm, mod_authz_dbd, mod_authz_owner и mod_ssl.

В большинстве случаев для корректной работы полной конфигурации аутентификации и авторизации директива Require должна сопровождаться директивами AuthName, AuthType и AuthBasicProvider или AuthDigestProvider, а также такими директивами, как AuthUserFile и AuthGroupFile (для определения пользователей и групп). Пример:

AuthType Basic
AuthName "Restricted Resource"
AuthBasicProvider file
AuthUserFile "/web/users"
AuthGroupFile "/web/groups"
Require group admin

Применённые таким образом средства контроля доступа действуют для всех методов. Обычно требуется именно такое поведение. Если необходимо применять средства контроля доступа только к определённым методам, оставляя остальные методы незащищёнными, поместите директиву Require в раздел <Limit>.

Результат директивы Require можно инвертировать с помощью параметра not. Как и другая инвертированная директива авторизации <RequireNone>, при инвертировании директива Require может только завершиться неудачей или вернуть нейтральный результат и поэтому никогда не может самостоятельно разрешить запрос.

В следующем примере разрешение получают все пользователи из групп alpha и beta, кроме тех, кто также входит в группу reject.

<Directory "/www/docs">
    <RequireAll>
        Require group alpha beta
        Require not group reject
    </RequireAll>
</Directory>

Если в одном разделе конфигурации используется несколько директив Require, не заключённых в другую директиву авторизации, например <RequireAll>, они неявно заключаются в директиву <RequireAny>. Таким образом, первая директива, разрешившая доступ пользователю, разрешает весь запрос, а последующие директивы Require игнорируются.

См. также

• Руководство по управлению доступом
• Контейнеры авторизации
• mod_authn_core
• mod_authz_host

Директива <RequireAll>

<RequireAll> ... </RequireAll>

<RequireAll> и </RequireAll> используются для заключения группы директив авторизации, ни одна из которых не должна завершиться неудачей и хотя бы одна должна завершиться успешно, чтобы директива <RequireAll> завершилась успешно.

Если ни одна из директив внутри директивы <RequireAll> не завершилась неудачей и хотя бы одна завершилась успешно, директива <RequireAll> завершается успешно. Если ни одна директива не завершилась ни успешно, ни неудачно, возвращается нейтральный результат. Во всех остальных случаях директива завершается неудачей.

См. также

• Контейнеры авторизации
• Аутентификация, авторизация и контроль доступа

Директива <RequireAny>

<RequireAny> ... </RequireAny>

<RequireAny> и </RequireAny> используются для заключения группы директив авторизации, хотя бы одна из которых должна завершиться успешно, чтобы директива <RequireAny> завершилась успешно.

Если одна или несколько директив внутри директивы <RequireAny> завершаются успешно, директива <RequireAny> завершается успешно. Если ни одна директива не завершилась ни успешно, ни неудачно, возвращается нейтральный результат. Во всех остальных случаях директива завершается неудачей.

См. также

• Контейнеры авторизации
• Аутентификация, авторизация и контроль доступа

Директива <RequireNone>

<RequireNone> ... </RequireNone>

<RequireNone> и </RequireNone> используются для заключения группы директив авторизации, ни одна из которых не должна завершиться успешно, чтобы директива <RequireNone> не завершилась неудачей.

Если одна или несколько директив внутри директивы <RequireNone> завершаются успешно, директива <RequireNone> завершается неудачей. Во всех остальных случаях возвращается нейтральный результат. Поэтому, как и другая инвертированная директива авторизации Require not, она никогда не может самостоятельно разрешить запрос, поскольку не может вернуть успешный результат. Однако её можно использовать для ограничения множества пользователей, которым разрешён доступ к ресурсу.

См. также

• Контейнеры авторизации
• Аутентификация, авторизация и контроль доступа