 |
|
|
|
Устанавливаем DACS
Устанавливаем DACS Настройка DACS, системы контроля доступа к веб-ресурсам, – дело не простое. Поэтому разберем, как установить ее в минимальной конфигурации, а заодно посмотрим на нее в работе. Со времени публикования первой части статьи [1] ничего не изменилось. Текущей версией по-прежнему является 1.4.13а. Проект придерживается строгих правил, распространяя только исходные тексты DACS, и рекомендует полностью пересобрать всю систему с их помощью. Прекомпилированные пакеты удалось найти только на сайте проекта OMSE [2]. Хотя здесь доступна версия DACS 1.4.11, собранная для Debian 3.1 и Fedora Core 4, которые шли в качестве приложения к статье «DACS: Nur fur Mitglieder» в немецком журнале для IT-профессионалов IX (http://www.heise.de/ix). Версии 1.4.11 и 1.4.13а имеют отличия, но если цель – знакомство с системой DACS, то первоначально можно воспользоваться и этими пакетами. Это позволит сосредоточиться больше на изучении функциональности, чем на настройке. Мы же не ищем легких путей и будем устанавливать DACS с исходных текстов. Компоненты, необходимые для работы DACS Для установки, кроме самого DACS, понадобятся исходные тексты либо заголовочные devel-пакеты:
Кроме того, в зависимости от требуемой функциональности вам могут понадобиться и другие пакеты, установка которых опциональна. Так, если планируется сохранение конфигурации в базе данных, то потребуется Berkeley DB, gdbm или ndbm. Для включения NTLM понадобится пакет Samba, а возможность работы с LDAP или Active Directory реализуется посредством пакета OpenLDAP. Но при первой настройке лучше всего ограничиться только базовым набором, постепенно разобравшись с настройками, уже можно установить полнофункциональную систему. Устанавливаем основные компоненты В большинстве систем уже имеются библиотеки OpenSSL, если их в системе нет, установить их очень просто. Для удобства все необходимые компоненты я установил в свой каталог. $ cd openssl-0.9.8a/ $./config --prefix=/opt/openssl $ make; make test # make install Теперь очередь веб-сервера. Конфигурировать его необходимо с опцией --enable-ssl, остальные опции по необходимости. Чтобы не повлиять на работу основного Apache, тестовую версию советую установить в отдельный каталог. $ cd apache-2.0.58 $./configure --enable-ssl --with-ssl=/opt/openssl --prefix=/opt/apache2 После чего стандартные make и make install. По умолчанию поддержка SSL компилируется статически, проверить встроенные модули можно командой: # /opt/apache2/bin/apachectl –l
Если поддержка SSL компилировалась как динамически загружаемый модуль (Dynamic Shared Object), то при дальнейшей настройке необходимо проследить, чтобы при помощи директивы LoadModule в файле веб-сервера httpd.conf, mod_ssl загружался перед mod_auth_dacs. Иначе вы получите ошибку при запуске. Хотя настройкой Apache займемся чуть позже. Теперь для веб-сервера необходимо сгенерировать сертификаты и ключи: # /opt/openssl/bin/openssl req -config /opt/openssl/openssl.cnf -new -x509 -keyout gw-ca.pem -out gw-ca.pem -days 365
Далее выбираем пароль и отвечаем на стандартные вопросы скрипта (страна, организация, почтовый адрес и пр.). Разделяем ключ и сертификат, убираем пароль с ключа: # /opt/bin/openssl rsa -in gw-ca.pem -out gw-ca.key
# /opt/ openssl/bin/openssl x509 -in gw-ca.pem -out gw-ca.crt И копируем сертификат и ключ на свое место: # cp gw-ca.crt /opt/apache2/conf/server.crt # cp gw-ca.key /opt/apache2/conf/server.key Все настройки SSL по умолчанию описываются в секции: <IfModule mod_ssl.c> Include /opt/conf/ssl.conf </IfModule> Если заглянуть в файл ssl.conf, в нем файлы сертификата и ключа указываются следующими переменными: SSLCertificateFile /opt/apache2/conf/ssl.crt/server.crt SSLCertificateKeyFile /opt/apache2/conf/ssl.key/server.key После этих действия Apache должен нормально работать через SSL, для чего соединяемся при помощи браузера или telnet к 443 порту. Теперь Expat. Здесь все стандартно. $ cd expat-2.0.0 $ ./configure --prefix=/opt/expat; make # make install После чего следует добавить путь к библиотеке /opt/expat/lib в файл /etc/ld.so.conf и дать команду: # /sbin/ldconfig Установка модуля и утилит DACS Распаковываем архив с исходными текстами. Конфигурационный скрипт находится в подкаталоге src. Для просмотра всех опций конфигурирования вводим. $ cd dacs-1.4.13a $ src/configure --help Опций много, необходимости в выборе всех нет. Я использовал следующие параметры при конфигурировании: $ src/configure --with-ssl=/opt/openssl --with-expat=/opt/expat \ --with-apache=/opt/apache2 --enable-unix-auth --enable-debug \ --enable-apache-auth --enable-native-auth --prefix=/opt/dacs \ --enable-ndbm=no --enable-bdb=no Опции with-ssl, with-expat и with-apache указывают на каталоги, в которых установлены соответствующие приложения, а prefix – куда требуется установить DACS. Все виды аутентификации можно включить при помощи параметра enable-all-auth, сейчас все возможности нам не нужны, поэтому включаем аутентификацию UNIX и Apache опциями enable-unix-auth, enable-native-auth и enable-apache-auth. По умолчанию поддержка ndbm и Berkeley DB включена, и если они не установлены в системе, при конфигурировании будет выдана ошибка, поэтому отключаем их поддержку. Если все прошло нормально, строим зависимости: $ gmake depend Кстати, теперь можно получить помощь по компиляции mod_auth_dacs, вызвав make help. Модуль mod_auth_dacs можно построить с тремя возможными параметрами, добавляющими информацию о DACS в строку ответа сервера. Для включения вывода всей информации используйте make tag, для частичной – make smalltag, и для того чтобы в ответе не было упоминания о работе DACS – make notag. Я пробовал при помощи Google проверить, на скольких серверах установлен DACS, и нашел только один сервер. Получается два варианта, либо DACS малоизвестен, либо собирается с опцией notag, как более безопасной. $ gmake smalltag # gmake install Скрипт сначала запрашивает пользователя и группу владельцев файлов DACS.
Последний вывод получен при помощи утилиты version, которая доступна так же, как веб-сервис dacs_version, позволяющая проверить версию DACS и опции конфигурирования. Ее можно вызвать отдельно: # /opt/dacs/bin/version -v После установки убедитесь, что в httpd.conf добавилась строка, загружающая модуль mod_auth_dacs.so. # cat httpd.conf | grep LoadModule
Теперь можно запустить веб-сервер и проверить правильность работы модуля. # /opt/apache2/bin/apachectl start Сделать это можно несколькими способами. Журнал работы веб-сервера является самым простым способом, в нем должна появиться такая запись:
Еще для проверки работы с SSL в комплекте DACS имеется утилита sslclient, позволяющая подсоединиться к веб-ресурсу по SSL и получить необходимую информацию. # /opt/dacs/bin/sslclient testserver.net:443 Все, сервер работает, осталось только указать на каталоги, которые будут защищены DACS. В «DACS Quick Start Tutorial» для DACS настроен виртуальный сервер, мы тоже поступим аналогичным образом, так легче разобраться, что, где и как. Создадим виртуальный сервер testdacs.net, который будет слушать на 8080 порту. Для этого добавим в httpd.conf следующие строки: <Directory /opt/dacs/www/*> Options Indexes FollowSymLinks Order allow,deny Allow from all </Directory> # Настраиваем виртуальный сервер и делаем доступными каталоги DACS NameVirtualHost 127.0.0.1:8080 Listen 127.0.0.1:8080 <VirtualHost 127.0.0.1:8080> ServerName testdacs.net DocumentRoot "/opt/dacs/www/" ErrorLog "/opt/dacs/logs/error_log" TransferLog "/opt/dacs/logs/access_log" ScriptAlias /cgi-bin/ "/opt/apache2/cgi-bin/dacs/" Alias /css "/opt/dacs/www/css/" Alias /icons/ "/opt/apache2/icons/" Alias /dacs "/opt/dacs/www/" Alias /dtd-xsd "/opt/dacs/www/dtd-xsd/" Alias /examples "/opt/dacs/www/examples/" Alias /handlers "/opt/dacs/www/handlers/" Alias /man "/opt/dacs/www/man/" Alias /misc "/opt/dacs/www/misc/" Alias /mod "/opt/dacs/www/mod/" </VirtualHost> Конфигурирование DACS В качестве примера создадим одну федерацию, назовем ее DACSTEST и сопоставим ее с доменом testdacs.net. Для упрощения федерация будет состоять из одной юрисдикции – FIRST. Во время работы DACS использует два файла: site.conf и dacs.conf. Первый является опциональным, в нем хранится информация обо всех федерациях, расположенных на узле. Второй dacs.conf может описывать федерацию, юрисдикцию, узел. Каждый указанный элемент может иметь свой файл dacs.conf со своими настройками, или на узле может использоваться всего один dacs.conf, в котором все свалено в кучу. Разработчики рекомендуют использовать утилиту install, которая имеется в большинстве дистрибутивов. С ее помощью очень удобно контролировать права доступа к объектам, а DACS очень чувствительный к этим параметрам. Если такой утилиты нет, в комплекте имеется скрипт src/conftools/install-sh. Как вариант можно использовать стандартные утилиты cp, chown, chgrp и chmod, хотя это не так наглядно и можно допустить ошибку. Обратите внимание, что мы используем пользователя/группу apache2/apache2, от имени которых работает веб-сервер. Скопируем шаблонный файл site.conf-std на свое место. # install -g apache2 -m 0640 /opt/dacs/federations/site.conf-std /opt/dacs/federations/site.conf Файл хорошо комментирован, многие параметры понятны, поэтому трогать его не будем. На время тестирования можно отключить SSL, установив директиву SECURE_MODE в off, но в рабочей системе, естественно, она должна быть включена. Обратите внимание на каталоги, в которых должны храниться настройки, они описаны как: ${Conf::FEDERATIONS_ROOT}/${Conf::FEDERATION_DOMAIN}/${Conf::JURISDICTION_NAME} То есть в нашем случае полный путь должен быть такой – /opt/dacs/federations/testdacs.net/FIRST/. Создадим файл dacs.conf для федерации. # install -g apache2 -m 0660 /dev/null /opt/dacs/federations/dacs.conf Теперь каталоги, в которых будут храниться все ассоциативные настройки федерации и юрисдикции FIRST. # install -d -g apache2 -m 0770 /opt/dacs/federations/testdacs.net/ # install -d -g apache2 -m 0770 /opt/dacs/federations/testdacs.net/FIRST Все списки контроля доступа и revocation list юрисдикции по умолчанию хранятся в подкаталоге acl, и они должны существовать. # install -d -g apache2 -m 0770 /opt/dacs/federations/testdacs.net/FIRST/acls # install -g apache2 -m 0660 /dev/null /opt/dacs/federations/testdacs.net/FIRST/acls/revocations В подкаталогах groups записывается вся информация о том, кто состоит в юрисдикции (FIRST) и федерации (DACS). # install -d -g apache2 -m 0770 /opt/dacs/federations/testdacs.net/FIRST/groups \ /opt/dacs/federations/testdacs.net/FIRST/groups/FIRST \ /opt/dacs/federations/testdacs.net/FIRST/groups/DACS Файл jurisdictions.grp описывает все юрисдикции, входящие в федерацию, в случае внесения изменений в этот файл он должен быть скопирован во все юрисдикции. # install -g apache2 -m 0660 /dev/null /opt/dacs/federations/testdacs.net/FIRST/groups/DACS/jurisdictions.grp Добавим в созданный jurisdictions.grp информацию о нашей юрисдикции. <groups xmlns="http://dss.ca/dacs/v1.4"> <group_definition jurisdiction="FIRST" name="jurisdictions" mod_date="Tue, 26-Jun-2006 12:00:00 GMT" type="public"> <group_member jurisdiction="FIRST" name="DACS" type="meta" alt_name="My First Test Jurisdiction" dacs_url="http://testdacs.net:8080/cgi-bin/dacs" authenticates="yes" prompts="no"/> </group_definition> </groups> А в /opt/dacs/federations/dacs.conf данные о федерации и юрисдикции. <Configuration xmlns="http://dss.ca/dacs/v1.4.13а"> <Default> FEDERATION_DOMAIN "testdacs.net" FEDERATION_NAME "DACSTEST" LOG_LEVEL "info" </Default> <Jurisdiction uri="testdacs.net"> JURISDICTION_NAME "FIRST" </Jurisdiction> </Configuration> В примере адрес федерации и юрисдикции совпадает, разделение идет на уровне ресурсов. Как вариант можно разделять на юрисдикции при помощи разных доменов, например first.testdacs.net. Чтобы не создавать множество конфигурационных файлов, создадим для FIRST/dacs.conf символическую ссылку: # ln -s /opt/dacs/federations/dacs.conf /opt/dacs/federations/ testdacs.net/FIRST/dacs.conf Проверяем настройки Для этого в комплекте DACS идет специальная утилита conf, которая выведет результат слияния всех этих файлов. # /opt/dacs/bin/conf -u testdacs.net –q
Параметры понятны. Обратите внимание на установленное по умолчанию время жизни credentials, которое составляет 43200 секунд – 12 часов, и на отключенную проверку IP-адреса в credentials. Создаем ключи Для создания ключей используется утилита mkkey. Ключи необходимо сгенерировать для федерации и каждой юрисдикции. Во избежание компрометации в дальнейшем лучше поручить эту процедуру cron, который будет менять ключи в наименее загруженное время (с учетом жизни credentials, чтобы никто не возмущался). # install -g apache2 -m 0660 /dev/null /opt/dacs/federations/testdacs.net/federation_keyfile # /opt/dacs/bin/mkkey -u testdacs.net -q /opt/dacs/federations/testdacs.net/federation_keyfile
Проверяем созданный ключ. # cat /opt/dacs/federations/testdacs.net/federation_keyfile
Все нормально. Повторяем процедуру для юрисдикции, но с другими опциями mkkey. # install -g apache2 -m 0660 /dev/null /opt/dacs/federations/testdacs.net/FIRST/jurisdiction_keyfile # /opt/dacs/bin/mkkey -uj FIRST /opt/dacs/federations/testdacs.net/FIRST/jurisdiction_keyfile
Списки доступа для новой юрисдикции В папке /opt/dacs/acls сейчас лежат списки контроля доступа, используемые DACS по умолчанию. Эти правила в основном описывают параметры для стандартных веб-ресурсов. Трогать их не рекомендуется, для того чтобы переопределить правило, следует поместить файл с таким же именем в подкаталог acl юрисдикции. Например, правило acl-prenv.0 разрешает доступ к cgi-скрипту prenv, выдающему информацию о рабочем окружении только администратору. Поэтому попытка запуска этого скрипта выдаст ошибку 403. Выглядит правило так: <acl_rule> <services> <service url_expr='"${Conf::dacs_cgi_bin_prefix}/prenv"'/> </services> <rule order="allow,deny"> <allow> dacs_admin() </allow> </rule> </acl_rule> Давайте разрешим всем просматривать эту информацию. Для этого создадим файл acl-prenv.0, переопределяющий это правило. # install -g apache2 -m 0660 /dev/null /opt/dacs/federations/FIRST/acls/acl-prenv.0 И поместим в него следующие строки. <acl_rule> <services> <service url_expr='"${Conf::dacs_cgi_bin_prefix}/prenv"'/> </services> <rule order="allow,deny"> <allow> user("any") # то есть всем </allow> </rule> </acl_rule> И чтобы модуль веб-сервера знал о том, что ему контролировать в конец секции VirtualHost, которую мы создали ранее в файле httpd.conf, запишем следующие строки (параметры -t -v позволяют вывести отладочную информацию, которая вам понадобится). AddDACSAuth dacs-acs /opt/dacs/bin/dacs_acs "-t -v" SetDACSAuthMethod dacs-acs external SetDACSAuthConf dacs-acs "/opt/dacs/federations/dacs.conf" <Location /cgi-bin/dacs> AllowOverride AuthConfig Require valid-user Options ExecCGI AuthType DACS AuthDACS dacs-acs </Location> И перезапускаем Apache: # /opt/apache2/bin/apachectl restart Если набрать в веб-браузере «http://testdacs.net:8080/cgi-bin/dacs/prenv», вы должны увидеть результат работы скрипта. Причем к некоторым другим скриптам, лежащим в этом же каталоге, получить доступ вам не удастся, так как они защищены правилом acl-dacs.0, позволяющим работать с ними только пользователю с правами администратора. Регистрация пользователя Теперь заставим пользователя регистрироваться. Как уже говорилось в первой части, DACS поддерживает несколько методов аутентификации, в том числе и свой. Изменим описание юрисдикции в файле dacs.conf, добавив в него данные, позволяющие осуществлять аутентификацию при помощи паролей UNIX. <Jurisdiction uri="testdacs.net"> JURISDICTION_NAME "FIRST" <Auth id="passwd"> URL "http://testdacs.net:8080/cgi-bin/dacs/local_unix_authenticate" STYLE "pass" CONTROL "sufficient" </Auth> </Jurisdiction> Для регистрации используем подготовленную HTML-форму (см. рис. 1), доступную по адресу http://testdacs.net:8080/examples/login.html, где вводим системный логин и пароль. Как вариант можно использовать аутентификацию DACS, заменив в файле строку local_unix_authenticate на local_passwd_authenticate.
Рисунок 1. HTML-форма для регистрации пользователей DACS Для создания пароля DACS применяется утилита dacspasswd, роль ее аналогична команде htpasswd, предназначенной для работы с паролями пользователей веб-сервера Apache. Создадим файл, в котором будут храниться пароли пользователей юрисдикции. # install -g apache2 -m 0660 /dev/null /opt/dacs/federations/testdacs.net/FIRST/passwd И теперь пароль для пользователя sergej. # /opt/dacs/bin/dacspasswd -u testdacs.net -q -a sergej
Посмотрим, что получилось. # cat /opt/dacs/federations/testdacs.net/FIRST/passwd
Теперь пробуем зайти с новыми данными. Если все нормально, то вам будет выведена страница handlers/auth_ok.html (см. рис. 2), где вы можете просмотреть полученный credentials.
Рисунок 2. Вид страницы при успешной регистрации Вот он:
Если заглянуть внутрь cookie, то можно увидеть только имя пользователя в формате DACS, остальная информация зашифрована. При помощи утилиты cookie расшифруем полученный credentials. # /opt/dacs/bin/cookie -u testdacs.net -decrypt < cookie federation='DACSTEST' DACS username='FIRST:sergej' ip_address='' roles='' expires_secs='1154148374' auth_style='generated' valid_for='acs' version='1.4' В файле acl-prenv.0 изменим user("any") на user("auth"). Если параметр изменяется в конфигурационном файле Apache, то для того чтобы он вступил в силу, требуется перезапуск веб-сервера. При правке файлов DACS изменения будут актуальны уже при следующем запросе, поэтому перезапускать ничего не надо. Попробуем теперь получить доступ к prenv без регистрации, авторизовавшись в системе. В последнем случае credential делает свое дело, и мы получаем доступ к требуемому ресурсу. Загляни в журнал При настройках, описанных в статье, DACS будет вести четыре файла журнала, которые расположены в каталоге /opt/dacs/logs. Три файла описывают все события, а файл, имя которого начинается с FIRST и далее текущая дата, поможет разобраться с происшедшим в конкретной юрисдикции. В режиме отладки выдается большое количество информации, которая при внимательном анализе поможет разобраться с проблемой. Например, такая запись при наличии самого файла:
может свидетельствовать о том, что после правки изменились права доступа, и модуль DACS не может его прочитать. Если пользователь не допущен, система проинформирует администратора.
Или, например, когда DACS не нашел описание ресурса (требуется testdacs.net).
Вместо заключения Несмотря на то что DACS уже установлен и работает, чтобы окончательно в нем разобраться, потребуется провести не один эксперимент, меняя параметры и отслеживая реакцию системы. Здесь открываются большие просторы для творчества. Следует добавить еще юрисдикций, хотя бы одну федерацию, передать между ними пользователя, поэкспериментировать с revocations list, несколькими пользователями, ролями. Только так можно будет ощутить мощь и гибкость этой системы. Успехов.
|
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
