По соображениям безопасности аутентификацию веб-приложения следует перенести на клиентские сертификаты SSL. Должна быть возможность входа в систему с использованием имени пользователя / пароля или SSL. Кроме того, пользователям из интрасети должно быть разрешено использовать Приложение без дополнительной аутентификации.
Мы пытались реализовать этот сценарий согласно официальной документации, но безуспешно.
Вот наша текущая конфигурация
<Directory /opt/app/system/html>
RedirectMatch permanent ^/$ /exec/login.pl
Options -Indexes +FollowSymLinks
SSLVerifyClient optional
SSLVerifyDepth 2
SSLRequire %{SSL_CLIENT_I_DN_O} eq "Company_O"
SSLOptions +FakeBasicAuth
Satisfy any
AuthType Basic
AuthName "Zugriffsschutz"
AuthBasicProvider file
AuthUserFile /etc/apache2/htaccess/iapp.passwd
require valid-user
Order allow,deny
Allow from 10.20.0.0/255.255.0.0
Allow from 10.144.100
</Directory>
При такой конфигурации сертификат клиента даже не запрашивается. Если мы удалим базовую конфигурацию аутентификации, аутентификация клиента SSL будет работать хорошо.
Вопросу три месяца назад, поэтому мой ответ может не понадобиться OP, но он может помочь любому, кто хочет эту конфигурацию.
Вопрос помечен как apache-2.4, но конфигурация выглядит как подходящая для 2.2. Это не совсем удивительно, поскольку многие примеры в документации Apache 2.4 сами по себе не подходят для 2.4.
У меня такая конфигурация работала в 2.2 (за исключением «Разрешить от», которая не работала), и мне пришлось переписать ее для 2.4. Я обнаружил, что для этого нужны некоторые элементы, которые не сразу были видны в документации.
Я не даю на это никаких гарантий; он основан на моем файле конфигурации без тестирования. +StrictRequire
может не понадобиться в SSLOptions
- Без этого не пробовал, но так работает.
В этом отношении SSLOptions
строка может и не потребоваться - +FakeBasicAuth
вариант, вероятно, не используется. В конфигурации, которая есть у меня здесь, как только Company_O
находится в сертификате, доступ будет предоставлен. Как я понимаю, +FakeBasicAuth
используется с Require valid-user
(только), и доступ предоставляется, если DN из сертификата находится в списке пользователей, определенном в AuthUserFile
вместе с соответствующим паролем. Моя система так не работает, и я подозреваю, что ОП тоже не хотел этого делать.
<Directory /opt/app/system/html>
RedirectMatch permanent ^/$ /exec/login.pl
Options -Indexes +FollowSymLinks
# Anything which matches a Require rule will let us in
# Make server ask for client certificate, but not insist on it
SSLVerifyClient optional
SSLVerifyDepth 2
SSLOptions +FakeBasicAuth +StrictRequire
# Client with appropriate client certificate is OK
<RequireAll>
Require ssl-verify-client
# Correction: eq is integer comparison, string comparison requires ==
# Require expr %{SSL_CLIENT_I_DN_O} eq "Company_O"
Require expr %{SSL_CLIENT_I_DN_O} == "Company_O"
</RequireAll>
# Set up basic (username/password) authentication
AuthType Basic
AuthName "Zugriffsschutz"
AuthBasicProvider file
AuthUserFile /etc/apache2/htaccess/iapp.passwd
# User which is acceptable to basic authentication is OK
Require valid-user
# Access from these addresses is OK
Require ip 10.20.0.0/255.255.0.0
Require ip 10.144.100
</Directory>
я должен
<Directory />
...
Require all denied
...
</Directory>
в другом файле конфигурации - возможно, это важная часть рецепта.
Мне потребовалось некоторое время, чтобы заставить эту работу работать, так это то, что казалось, что Require expr %{SSL_CLIENT
bit будет работать сам по себе, но со временем я понял, что Require ssl-verify-client
также требовалось (см. http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#authzproviders)