Apache: Модуль Apache mod_authz

RU EN

Пункт 111. Модуль Apache mod_authz_core

Этот модуль предоставляет основные возможности авторизации, так что аутентифицированным пользователям можно разрешить или запретить доступ к частям веб-сайта. mod_authz_core предоставляет функциональные возможности для регистрации различных поставщиков авторизации. Обычно он используется в сочетании с модулем поставщика аутентификации, например, mod_authn_file и модулем авторизации, например mod_authz_user . Это также позволяет применять расширенную логику к обработке авторизации.

Создание псевдонимов поставщиков авторизации

Провайдеры расширенной авторизации могут быть созданы в файле конфигурации и им может быть присвоен псевдоним. После этого на провайдеров псевдонимов можно ссылаться через Require директиву так же, как на базового провайдера авторизации. Помимо возможности создавать расширенный провайдер и псевдоним, он также позволяет ссылаться на один и тот же расширенный провайдер авторизации из нескольких местоположений.

Пример

В приведенном ниже примере создаются два разных псевдонима провайдера авторизации ldap на основе провайдера авторизации ldap-group. Этот пример позволяет одному местоположению авторизации проверять членство в группе на нескольких хостах ldap:

 <AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx>
 AuthLDAPBindDN cn=youruser,o=ctx
 AuthLDAPBindPassword ваш пароль
 АутентификацияLDAPURL ldap://ldap.host/o=ctx
</AuthzProviderAlias>
<AuthzProviderAlias ldap-group ldap-group-alias2 cn=my-other-group,o=dev>
 AuthLDAPBindDN cn=yourotheruser,o=dev
 AuthLDAPBindPassword ваш другой пароль
 АутентификацияLDAPURL ldap://other.ldap.host/o=dev?cn
</AuthzProviderAlias>
Псевдоним "/secure" "/webpages/secure"
<Каталог "/webpages/secure">
 Требовать все предоставленные
 
 Файл AuthBasicProvider
 
 Основной тип авторизации
 Имя_аутентификации LDAP_Protected_Place
 
 #подразумеваемая операция ИЛИ
 Требовать ldap-group-alias1
 Требовать ldap-group-alias2
</Каталог>

Контейнеры авторизации

Директивы контейнера авторизации <RequireAll> и могут быть объединены друг с другом и с директивой для выражения сложной логики <RequireAny> авторизации . <RequireNone> Require

Пример ниже выражает следующую логику авторизации. Чтобы получить доступ к ресурсу, пользователь должен либо быть superadmin пользователем, либо принадлежать как к admins группе, так и к Administrators группе LDAP и либо принадлежать к группе, либо иметь атрибут sales LDAP . Кроме того, для доступа к ресурсу пользователь не должен принадлежать ни к группе, ни к группе LDAP . dept sales temps Temporary Employees

 <Каталог "/www/mydocs">
 <ТребоватьВсе>
 <RequireAny>
 Требовать пользователя суперадминистратора
 <ТребоватьВсе>
 Требуются администраторы группы
 Требовать группу ldap cn=Администраторы,o=Airius
 <RequireAny>
 Требовать групповых продаж
 Требуется ldap-атрибут dept="sales"
 </RequireAny>
 </RequireAll>
 </RequireAny>
 <Не требуется>
 Требовать временные группы
 Требуется группа ldap cn=Временные сотрудники,o=Airius
 </RequireNone>
 </RequireAll>
</Каталог>

Требуемые директивы

mod_authz_core предоставляет несколько общих провайдеров авторизации, которые можно использовать с Require директивой.

Требовать среду

Поставщик env позволяет контролировать доступ к серверу на основе существования переменной среды. Когда указано, запросу разрешается доступ, если существует переменная окружения env-variable . Сервер предоставляет возможность гибко задавать переменные среды на основе характеристик клиентского запроса с помощью директив, предоставляемых . Следовательно, эту директиву можно использовать для разрешения доступа на основе таких факторов, как клиенты (тип браузера), или другие поля заголовка HTTP-запроса. Require env env-variable mod_setenvif User-Agent Referer

 SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
<Каталог "/docroot">
 Требовать env let_me_in
</Каталог>

В этом случае браузерам со строкой пользовательского агента, начинающейся с, KnockKnock/2.0 будет разрешен доступ, а всем остальным будет отказано.

Когда сервер ищет путь через внутренний подзапрос , такой как поиск DirectoryIndex или создание списка каталогов с помощью mod_autoindex , переменные среды для каждого запроса не наследуются в подзапросе. Кроме того, SetEnvIf директивы не оцениваются отдельно в подзапросе из-за того, что этапы API mod_setenvif выполняют действия.

Требовать все

Поставщик all имитирует функциональность, которая ранее предоставлялась директивами «Разрешить от всех» и «Запретить от всех». Этот провайдер может принимать один из двух аргументов: «предоставлено» или «отказано». В следующих примерах будет предоставлен или запрещен доступ ко всем запросам.

 Требовать все предоставленные

 Требовать все отказано

Требовать метод

Провайдер method позволяет использовать метод HTTP в решениях об авторизации. Методы GET и HEAD считаются эквивалентными. Метод TRACE недоступен для этого провайдера, используйте TraceEnable вместо него.

В следующем примере разрешены только запросы GET, HEAD, POST и OPTIONS:

 Требовать метод GET POST OPTIONS

В следующем примере разрешены запросы GET, HEAD, POST и OPTIONS без аутентификации, а для всех остальных методов требуется действительный пользователь:

 <RequireAny>
  Требовать метод GET POST OPTIONS
  Требовать действительного пользователя
</RequireAny>

Требовать выражение

Провайдер expr позволяет основывать решения об авторизации на произвольных выражениях.

 Требуется выражение "%{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17"

 <ТребоватьВсе>
 Требуется выражение "!(%{QUERY_STRING} =~ /secret/)"
 Требовать expr "%{REQUEST_URI} в { '/example.cgi', '/other.cgi' }"
</RequireAll>

 Требуется выражение "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} в { '/example.cgi', '/other.cgi' }"

Синтаксис описан в документации ap_expr.

Обычно выражение оценивается перед аутентификацией. Однако, если выражение возвращает false и ссылается на переменную %{REMOTE_USER} , будет выполнена аутентификация и выражение будет переоценено.

Директива AuthMerging

Описание:	Управляет способом, которым логика авторизации каждого раздела конфигурации комбинируется с логикой предыдущих разделов конфигурации.
Синтаксис:	`AuthMerging Off \| And \| Or`
По умолчанию:	`AuthMerging Off`
Контекст:	каталог, .htaccess
Переопределить:	Аутконфиг
Положение дел:	База
Модуль:	mod_authz_core

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

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

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

Параметр AuthMerging не наследуется за пределами раздела конфигурации, в котором он появляется. В следующем примере только пользователи, принадлежащие к группе, alpha могут получить доступ к /www/docs . Пользователи, принадлежащие либо к группам alpha , либо beta могут получить доступ к /www/docs/ab . Однако Off параметр по умолчанию AuthMerging применяется к <Directory> разделу конфигурации для /www/docs/ab/gamma , поэтому директивы авторизации этого раздела переопределяют директивы предыдущих разделов. Таким образом, только пользователи, принадлежащие к группе, gamma могут получить доступ /www/docs/ab/gamma .

 <Каталог "/www/docs">
 Основной тип авторизации
 Документы AuthName
 Файл AuthBasicProvider
 AuthUserFile "/usr/local/apache/passwd/пароли"
 Требовать группу альфа
</Каталог>
<Каталог "/www/docs/ab">
 AuthMerge или
 Требовать групповую бета-версию
</Каталог>
<Каталог "/www/docs/ab/gamma">
 Требовать групповую гамму
</Каталог>

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

Описание:	Заключите группу директив, которые представляют собой расширение базового поставщика авторизации и на которые ссылается указанный псевдоним.
Синтаксис:	`<AuthzProviderAlias baseProvider Alias Require-Parameters> ... </AuthzProviderAlias>`
Контекст:	конфигурация сервера
Положение дел:	База
Модуль:	mod_authz_core

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

Директива AuthzSendForbiddenOnFailure

Описание:	Отправить «403 FORBIDDEN» вместо «401 UNAUTHORIZED», если аутентификация прошла успешно, но авторизация не удалась.
Синтаксис:	`AuthzSendForbiddenOnFailure On\|Off`
По умолчанию:	`AuthzSendForbiddenOnFailure Off`
Контекст:	каталог, .htaccess
Положение дел:	База
Модуль:	mod_authz_core
Совместимость:	Доступно в Apache HTTPD 2.3.11 и более поздних версиях.

Если аутентификация прошла успешно, но авторизация не удалась, Apache HTTPD по умолчанию ответит кодом ответа HTTP «401 UNAUTHORIZED». Это обычно приводит к тому, что браузеры снова отображают пользователю диалоговое окно с паролем, что нежелательно во всех ситуациях. AuthzSendForbiddenOnFailure позволяет изменить код ответа на «403 ЗАПРЕЩЕНО».

Предупреждение безопасности

Изменение ответа в случае отсутствия авторизации ослабляет безопасность пароля, поскольку показывает возможному злоумышленнику, что его угаданный пароль был правильным.

Требовать директиву

Описание:	Проверяет, авторизован ли аутентифицированный пользователь поставщиком авторизации.
Синтаксис:	`Require [not] entity-name [entity-name] ...`
Контекст:	каталог, .htaccess
Переопределить:	Аутконфиг
Положение дел:	База
Модуль:	mod_authz_core

Эта директива проверяет, авторизован ли аутентифицированный пользователь в соответствии с конкретным поставщиком авторизации и указанными ограничениями. 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: Доступ разрешен, если выражение оценивается как истинное.

Некоторые из разрешенных синтаксисов, предоставляемых 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-адресов могут получить доступ к ресурсу.

Другие модули авторизации , реализующие требуемые параметры, включают mod_authnz_ldap , mod_authz_dbm , и . mod_authz_dbd mod_authz_owner mod_ssl

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

 Основной тип авторизации
AuthName "Ограниченный ресурс"
Файл AuthBasicProvider
AuthUserFile "/web/users"
AuthGroupFile "/web/groups"
Требуется администратор группы

Контроль доступа, применяемый таким образом, эффективен для всех методов. Это то, что обычно желательно. Если вы хотите применить контроль доступа только к определенным методам, оставив другие методы незащищенными, поместите Require оператор в <Limit> раздел.

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

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

 <Каталог "/www/docs">
 <ТребоватьВсе>
 Требовать группу альфа-бета
 Требовать не группового отклонения
 </RequireAll>
</Каталог>

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

Предупреждение безопасности

Соблюдайте осторожность при установке директив авторизации в Location разделах, которые пересекаются с содержимым, обслуживаемым вне файловой системы. По умолчанию эти разделы конфигурации перезаписывают конфигурацию авторизации в разделах Directory и Files .

Директиву AuthMerging можно использовать для управления объединением разделов конфигурации авторизации.

Смотрите также

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

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

Описание:	Включите группу директив авторизации, ни одна из которых не должна дать сбой, и по крайней мере одна из них должна быть успешной, чтобы заключающая директива сработала.
Синтаксис:	`<RequireAll> ... </RequireAll>`
Контекст:	каталог, .htaccess
Переопределить:	Аутконфиг
Положение дел:	База
Модуль:	mod_authz_core

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

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

Смотрите также

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

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

Описание:	Включите группу директив авторизации, одна из которых должна быть успешной, чтобы закрывающая директива была успешной.
Синтаксис:	`<RequireAny> ... </RequireAny>`
Контекст:	каталог, .htaccess
Переопределить:	Аутконфиг
Положение дел:	База
Модуль:	mod_authz_core

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

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

Поскольку отрицательные директивы авторизации не могут вернуть успешный результат, они не могут существенно повлиять на результат директивы <RequireAny> . (В лучшем случае они могут привести к сбою директивы в том случае, если они не сработали, а все другие директивы вернули нейтральное значение.) Поэтому директивы с отрицанием авторизации не разрешены в директиве <RequireAny> .

Смотрите также

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

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

Описание:	Включите группу директив авторизации, ни одна из которых не должна быть успешной, чтобы закрывающая директива не потерпела неудачу.
Синтаксис:	`<RequireNone> ... </RequireNone>`
Контекст:	каталог, .htaccess
Переопределить:	Аутконфиг
Положение дел:	База
Модуль:	mod_authz_core

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

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

Поскольку отрицательные директивы авторизации не могут вернуть успешный результат, они не могут существенно повлиять на результат директивы <RequireNone> . Следовательно, внутри директивы запрещаются отрицательные директивы авторизации <RequireNone> .

Смотрите также

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