Apache: Аутентификация и авторизация

RU EN

Пункт 49. Аутентификация и авторизация

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

Для общего управления доступом см. Руководство по управлению доступом.

Связанные модули и директивы

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

Тип аутентификации (см. AuthType директиву)
- mod_auth_basic
- mod_auth_digest
Поставщик аутентификации (см. директивы AuthBasicProvider и AuthDigestProvider )
- mod_authn_anon
- mod_authn_dbd
- mod_authn_dbm
- mod_authn_file
- mod_authnz_ldap
- mod_authn_socache
Авторизация (см. Require директиву)
- mod_authnz_ldap
- mod_authz_dbd
- mod_authz_dbm
- mod_authz_groupfile
- mod_authz_host
- mod_authz_owner
- mod_authz_user

Кроме этих модулей есть еще mod_authn_core и mod_authz_core . Эти модули реализуют основные директивы, которые являются основными для всех модулей аутентификации.

Модуль mod_authnz_ldap является одновременно поставщиком аутентификации и авторизации. Модуль mod_authz_host обеспечивает авторизацию и управление доступом на основе имени хоста, IP-адреса или характеристик запроса, но не является частью системы провайдера аутентификации. Для обратной совместимости с mod_access есть новый модуль mod_access_compat .

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

Введение

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

В этой статье рассматривается «стандартный» способ защиты тех частей вашего веб-сайта, которые большинство из вас собирается использовать.

Примечание:

Если ваши данные действительно нуждаются в безопасности, рассмотрите возможность использования mod_ssl в дополнение к любой аутентификации.

Предпосылки

Директивы, обсуждаемые в этой статье, должны находиться либо в файле конфигурации вашего основного сервера (обычно в разделе <Directory> ), либо в файлах конфигурации для каждого каталога ( .htaccess файлы).

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

Поскольку мы говорим здесь об аутентификации, вам понадобится AllowOverride директива, подобная следующей:

 Аллововеррайд Аутконфиг

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

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

Вам также необходимо убедиться, что модули mod_authn_core и mod_authz_core были либо встроены в двоичный файл httpd, либо загружены файлом конфигурации apache2.conf. Оба этих модуля предоставляют основные директивы и функциональные возможности, которые имеют решающее значение для настройки и использования аутентификации и авторизации на веб-сервере.

Как это работает

Вот основы защиты паролем каталога на вашем сервере.

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

Этот файл должен быть размещен в месте, недоступном из Интернета. Это делается для того, чтобы люди не могли загрузить файл паролей. Например, если ваши документы обслуживаются /usr/local/apache/htdocs из /usr/local/apache/passwd .

Чтобы создать файл, используйте htpasswd утилиту, поставляемую с Apache. Он будет расположен в bin каталоге, где вы установили Apache. Если вы установили Apache из стороннего пакета, он может быть в вашем пути выполнения.

Чтобы создать файл, введите:

htpasswd -c /usr/local/apache/passwd/passwords rbowen

htpasswd запросит у вас пароль, а затем попросит ввести его еще раз для подтверждения:

# htpasswd -c /usr/local/apache/passwd/passwords rbowen New password: mypassword Re-type new password: mypassword Adding password for user rbowen

Если htpasswd его нет на вашем пути, конечно, вам придется ввести полный путь к файлу, чтобы он запустился. При установке по умолчанию он находится по адресу /usr/local/apache2/bin/htpasswd

Далее вам нужно настроить сервер для запроса пароля и сообщить серверу, каким пользователям разрешен доступ. Вы можете сделать это либо отредактировав apache2.conf файл, либо используя .htaccess файл. Например, если вы хотите защитить каталог /usr/local/apache/htdocs/secret , вы можете использовать следующие директивы, помещенные либо в файл /usr/local/apache/htdocs/secret/.htaccess , либо в apache2.conf раздел <Directory "/usr/local/apache/htdocs/secret">.

 Основной тип авторизации
AuthName "Файлы с ограниченным доступом"
# (следующая строка не обязательна)
Файл AuthBasicProvider
AuthUserFile "/usr/local/apache/passwd/пароли"
Требовать пользователя rbowen

Давайте рассмотрим каждую из этих директив в отдельности. Директива AuthType выбирает тот метод, который используется для аутентификации пользователя. Самый распространенный метод — Basic , и этот метод реализуется с помощью mod_auth_basic . Однако важно помнить, что обычная проверка подлинности отправляет пароль от клиента на сервер в незашифрованном виде. Поэтому этот метод не следует использовать для особо конфиденциальных данных, если он не сопровождается mod_ssl . Apache поддерживает еще один метод аутентификации: AuthType Digest . Этот метод реализован mod_auth_digest и был задуман как более безопасный. Это больше не так, и mod_ssl вместо этого соединение должно быть зашифровано.

Директива AuthName устанавливает область , которая будет использоваться при аутентификации. Царство выполняет две основные функции. Во-первых, клиент часто представляет эту информацию пользователю как часть диалогового окна пароля. Во-вторых, он используется клиентом, чтобы определить, какой пароль отправить для данной аутентифицированной области.

Так, например, после того, как клиент прошел аутентификацию в "Restricted Files" области, он автоматически повторит попытку ввести тот же пароль для любой области на том же сервере, который отмечен Realm "Restricted Files" . Таким образом, вы можете запретить пользователю запрашивать пароль более одного раза, разрешив нескольким областям с ограниченным доступом использовать одну и ту же область. Конечно, из соображений безопасности клиенту всегда нужно будет снова запрашивать пароль всякий раз, когда изменяется имя хоста сервера.

В данном случае является AuthBasicProvider необязательным, так как file является значением по умолчанию для этой директивы. Вам нужно будет использовать эту директиву, если вы выбираете другой источник для аутентификации, например mod_authn_dbm или mod_authn_dbd .

Директива AuthUserFile задает путь к файлу паролей, который мы только что создали с помощью htpasswd . Если у вас большое количество пользователей, поиск в обычном текстовом файле для аутентификации пользователя при каждом запросе может быть довольно медленным. Apache также имеет возможность хранить информацию о пользователях в быстрых файлах базы данных. Модуль mod_authn_dbm предоставляет AuthDBMUserFile директиву. Эти файлы можно создавать и управлять ими с помощью программ dbmmanage и htdbm . Многие другие типы параметров аутентификации доступны из сторонних модулей в базе данных модулей Apache.

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

Впускать более одного человека

rbowen Приведенные выше директивы позволяют войти в каталог только одному человеку (в частности, пользователю с именем ). В большинстве случаев вы захотите впустить более одного человека AuthGroupFile .

Если вы хотите допустить более одного человека, вам нужно создать групповой файл, который связывает имена групп со списком пользователей в этой группе. Формат этого файла довольно прост, и вы можете создать его в своем любимом редакторе. Содержимое файла будет выглядеть так:

GroupName: rbowen dpitts sungo rshersey

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

Чтобы добавить пользователя в уже существующий файл паролей, введите:

htpasswd /usr/local/apache/passwd/passwords dpitts

Вы получите тот же ответ, что и раньше, но он будет добавлен к существующему файлу, а не к созданию нового файла. (Это -c заставляет его создать новый файл паролей).

Теперь вам нужно изменить .htaccess файл или <Directory> блок, чтобы он выглядел следующим образом:

 Основной тип авторизации
AuthName "Только по приглашению"
# Необязательная строка:
Файл AuthBasicProvider
AuthUserFile "/usr/local/apache/passwd/пароли"
AuthGroupFile "/usr/local/apache/passwd/groups"
Требовать группу имя_группы

Теперь любой, кто указан в группе GroupName и имеет запись в password файле, будет пропущен, если введет правильный пароль.

Есть еще один способ разрешить нескольким пользователям, менее конкретный. Вместо создания группового файла вы можете просто использовать следующую директиву:

 Требовать действительного пользователя

Использование этого, а не Require user rbowen строки, позволит любому, кто указан в файле паролей, и кто правильно вводит свой пароль.

Возможные проблемы

Из-за того, что указана обычная проверка подлинности, ваше имя пользователя и пароль необходимо проверять каждый раз, когда вы запрашиваете документ с сервера. Это даже если вы перезагружаете одну и ту же страницу и для каждого изображения на странице (если они взяты из защищенного каталога). Как вы понимаете, это немного замедляет работу. Величина, на которую это замедляет работу, пропорциональна размеру файла паролей, потому что он должен открыть этот файл и пройтись по списку пользователей, пока не дойдет до вашего имени. И он должен делать это каждый раз, когда загружается страница.

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

Альтернативное хранилище паролей

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

mod_authn_dbm и mod_authn_dbd два модуля, которые делают это возможным. Вместо выбора , вместо этого вы можете выбрать или в качестве формата хранения. AuthBasicProvider file dbm dbd

Чтобы выбрать файл dbm, а не текстовый файл, например:

 <Каталог "/www/docs/private">
 Имя_аутентификации "Частное"
 Основной тип авторизации
 База данных AuthBasicProvider
 AuthDBMUserFile "/www/passwords/passwd.dbm"
 Требовать действительного пользователя
</Каталог>

Доступны другие варианты. Обратитесь к mod_authn_dbm документации для более подробной информации.

Использование нескольких провайдеров

С введением новой архитектуры аутентификации и авторизации на основе провайдера вы больше не привязаны к одному методу аутентификации или авторизации. На самом деле любое количество поставщиков может быть смешано и подобрано, чтобы предоставить вам именно ту схему, которая соответствует вашим потребностям. В следующем примере используются поставщики аутентификации на основе файлов и LDAP.

 <Каталог "/www/docs/private">
 Имя_аутентификации "Частное"
 Основной тип авторизации
 Файл AuthBasicProvider ldap
 AuthUserFile "/usr/local/apache/passwd/пароли"
 AuthLDAPURL ldap://ldaphost/o=yourorg
 Требовать действительного пользователя
</Каталог>

В этом примере поставщик файлов сначала попытается аутентифицировать пользователя. Если он не может аутентифицировать пользователя, будет вызван поставщик LDAP. Это позволяет расширить область проверки подлинности, если ваша организация реализует более одного типа хранилища проверки подлинности. Другие сценарии аутентификации и авторизации могут включать смешивание одного типа аутентификации с другим типом авторизации. Например, аутентификация по файлу паролей и авторизация по каталогу LDAP.

Так же, как могут быть реализованы несколько поставщиков аутентификации, также могут использоваться несколько методов авторизации. В этом примере используется как авторизация группы файлов, так и авторизация группы LDAP.

 <Каталог "/www/docs/private">
 Имя_аутентификации "Частное"
 Основной тип авторизации
 Файл AuthBasicProvider
 AuthUserFile "/usr/local/apache/passwd/пароли"
 AuthLDAPURL ldap://ldaphost/o=yourorg
 AuthGroupFile "/usr/local/apache/passwd/groups"
 Требовать группу имя_группы
 Требовать группу ldap cn=mygroup,o=yourorg
</Каталог>

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

Помимо авторизации

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

Применение логики и порядка

В прошлом контроль над тем, как и в каком порядке будет применяться авторизация, был загадкой. В Apache 2.2 был представлен механизм аутентификации на основе провайдера, чтобы отделить фактический процесс аутентификации от авторизации и вспомогательных функций. Одним из дополнительных преимуществ было то, что провайдеры аутентификации можно было настраивать и вызывать в определенном порядке, который не зависел от порядка загрузки самого модуля аутентификации. Этот же механизм на основе провайдера был перенесен и в авторизацию. Это означает, что Require директива не только указывает, какие методы авторизации следует использовать, но и определяет порядок их вызова. Несколько методов авторизации вызываются в том же порядке, в котором Require директивы появляются в конфигурации.

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

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

Использование провайдеров авторизации для управления доступом

Аутентификация по имени пользователя и паролю — это только часть истории. Часто вы хотите впустить людей, основываясь на чем-то другом, а не на том, кто они есть. Что-то вроде того, откуда они берутся.

Поставщики авторизации all , и позволяют разрешать или запрещать доступ на основе других критериев хоста, таких как имя хоста или IP-адрес машины, запрашивающей документ env . host ip

Использование этих поставщиков определяется директивой Require . Эта директива регистрирует провайдеров авторизации, которые будут вызываться на этапе авторизации обработки запроса. Например:

 Требовать IP -адрес

где address — это IP-адрес (или частичный IP-адрес) или:

 Требовать хост имя_домена

где domain_name — полное доменное имя (или частичное доменное имя); при желании вы можете указать несколько адресов или доменных имен.

Например, если у вас есть кто-то, кто рассылает спам на вашу доску объявлений, и вы хотите, чтобы он не вмешивался, вы можете сделать следующее:

 <ТребоватьВсе>
 Требовать все предоставленные
 Требовать не ip 10.252.46.165
</RequireAll>

Посетители, приходящие с этого адреса, не смогут увидеть контент, подпадающий под действие этой директивы. Если вместо этого у вас есть имя машины, а не IP-адрес, вы можете использовать его.

 <ТребоватьВсе>
 Требовать все предоставленные
 Не требовать хоста host.example.com
</RequireAll>

А если вы хотите заблокировать доступ со всего домена, вы можете указать только часть адреса или доменного имени:

 <ТребоватьВсе>
 Требовать все предоставленные
 Требовать не ip 192.168.205
 Не требовать размещения phishers.example.com moreidiots.example
 Не требовать размещения ке
</RequireAll>

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

Обратная совместимость контроля доступа

Одним из побочных эффектов внедрения механизма аутентификации на основе провайдера является то, что прежние директивы управления доступом Order больше не нужны. Однако для обеспечения обратной совместимости со старыми конфигурациями эти директивы были перемещены в модуль. Allow Deny Satisfy mod_access_compat

Примечание

Директивы, предоставленные , mod_access_compat устарели mod_authz_host . Смешивание старых директив, таких как Order , Allow или Deny с новыми, например, Require технически возможно, но не рекомендуется. Модуль mod_access_compat был создан для поддержки конфигураций, содержащих только старые директивы, для облегчения обновления 2.4. Пожалуйста, ознакомьтесь с руководством по обновлению для получения дополнительной информации.

Кэширование аутентификации

Могут быть случаи, когда аутентификация создает неприемлемую нагрузку на провайдера или вашу сеть. Это, скорее всего, повлияет на пользователей mod_authn_dbd (или сторонних / пользовательских поставщиков). Чтобы решить эту проблему, в HTTPD 2.3/2.4 представлен новый провайдер кэширования mod_authn_socache для кэширования учетных данных и снижения нагрузки на провайдеров-источников.

Некоторым пользователям это может предложить существенное повышение производительности.

Больше информации

Вы также должны прочитать документацию для mod_auth_basic и mod_authz_host которая содержит дополнительную информацию о том, как все это работает. Директива <AuthnProviderAlias> также может помочь упростить определенные конфигурации аутентификации.

Различные шифры, поддерживаемые Apache для аутентификационных данных, описаны в разделе «Шифрование паролей».

И вы можете посмотреть руководство по управлению доступом, в котором обсуждается ряд связанных тем.