 |
|
|
|
Система аутентификации веб-пользователей WebAuth
Система аутентификации веб-пользователей WebAuth Интернет-технологии сегодня популярны как никогда. В той или иной форме их использование можно встретить в любой компании, как в виде общедоступных сервисов, так и для организации доступа к внутренним ресурсам компании. И тем острее встает вопрос об обеспечении безопасности таких каналов доступа, в первую очередь о надежности аутентификации пользователей. На страницах журнала уже шла речь о достоинствах и недостатках стандартных типов аутентификации basic и digest [1, 2] и был дан пример одной из более защищенных реализаций DACS (Distributed Access Control System). Но это не единственное решение. В Стэнфордском университете уже несколько лет успешно используется система одноразовой регистрации (SSO – single sign-on) WebAuth. Пользователь, который хочет получить доступ к одному из ресурсов, регистрируется только один раз на центральном сервере (http://weblogin.stanford.edu, см. рис. 1) при переходе на другой веб-сайт этой группы серверов вводить пароль уже не потребуется. Если пользователь имеет право посетить ресурс, он к нему будет допущен автоматически.
Рисунок 1. WebLogin Стэнфордского университета Принцип работы системы WebAuth WebAuth реализован в качестве модуля веб-сервера Apache 2.x. Хотя есть порт и для IIS (см. далее по тексту). Система работает с любым веб-браузером, поддерживающим SSL/TLS и cookies, без необходимости установки дополнительных приложений и не требующих включения Java или JavaScript. Вся схема аутентификации построена поверх Kerberos, при этом билеты (ticket) упаковываются в сеансовый cookies (token), который и используется каждый раз в случае необходимости, для подтверждения полномочий. Хотя для подтверждения полномочий предусмотрены варианты передачи билетов через URL или POST. Для работы WebAuth требуется наличие трех компонентов. Кроме веб-браузера (User-Agent – UA) необходимо настроить сервер, который должен поддерживать схему аутентификации WebAuth-enabled Application Server (WAS). Чтобы не допустить попадания cookies третьему лицу, соединение между UA и WAS обязательно защищается с помощью SSL/TLS, сам tiket шифруется с использованием сеансового ключа. Для подтверждения полномочий пользователя задействуется еще один сервер – WebKDC. Его задачами являются: проверка подлинности пользователя и выдача cookies, уточнение информации о пользователе у WAS, обновление cookies, срок жизни которых истек, установка ключей для WAS. Для всей сети серверов используется один такой сервер, который может находиться в одной сети или вообще по другую сторону океана. Пользователь, который хочет получить доступ к ресурсу, защищенному с помощью WebAuth сервером WAS, сначала перенаправляется на страницу Weblogin, которая находится на WebKDC, после получения cookies он уже попадает на нужную страницу. Регистрация пользователя требует 10 шагов, из них первые два – это обмен ключами между WAS и WebKDC при первоначальном подключении и получение результата krb5_mk_req. Да и единственным полностью эффективным способом удалить используемый cookies, чтобы никто не мог им воспользоваться в дальнейшем, является закрытие веб-браузера. Хотя сервис поддерживает специальную страницу logout, предназначенную для этих целей. Отметьте, что tiket, передаваемый посредством URL, имеет очень короткий период жизни по сравнению с вариантом использования cookies – не более 5 минут. Если по истечении этого времени попытаться повторно использовать такой URL, будет запрошен cookies, содержащий билет, если cookies удовлетворяет всем условиям, доступ будет разрешен. Для подтверждения наличия учетной записи пользователя, может быть использован любой механизм, поддерживаемый Apache, встроена интеграция с LDAP. Распространяется WebAuth по X11-подобной (http://www.gnu.org/licenses/info/X11.html) лицензии, разрешающей бесплатно и без ограничений использовать, копировать, модифицировать, продавать и прочее, сохраняя уведомление об авторском праве. Установка WebAuth Актуальной на момент написания статьи была версия 3.5.4. Версия WebAuth v3 базируется на Apache 2.х и MIT Kerberos v5 (можно использовать Heimdal Kerberos версией выше 0.7) официально представлена общественности в начале 2003 года. Поэтому период детских болезней, можно сказать, давно уже миновал, чего, правда, не скажешь о прозрачности настроек, с которыми придется повозиться, представленная документация также не всегда может помочь. Сегодня WebAuth включен в репозитарии многих дистрибутивов, поэтому самый простой способ установки – использование менеджера пакетов. Правда, называться пакеты могут по-разному. В Debian необходимо установить пакет libapache2-webauth. В Ubuntu команда поиска выдаст длинный список пакетов:
Все эти пакеты понадобятся при настройке и тестировании работы сервера. Именно в дистрибутивах Debian и Ubuntu по заявлению разработчиков WebAuth максимально поддерживается. На сайте проекта, кроме исходных текстов, доступны пакеты для Red Hat Enterprise Linux 4, Solaris и Windows. Правда, их версии не самые свежие, например zip‑архив для Windows содержит версию 3.2.0, и этот порт подписан как unsuported. Судя по инструкции, использовать этот порт можно совместно с Apache 2.0.47. Порт для IIS 6.0 можно найти по адресу [5], его первоначальная реализация разрабатывалась также в Стэнфорде и содержала много ошибок, сейчас отдан на откуп сторонним разработчикам. Другой проект SPIE [6] предлагает реализацию WebAuth на Java, все файлы, предлагаемые SPIE, можно также загрузить со страницы закачки проекта WebAuth.
Рисунок 2. Регистрация пользователей в WebAuth (нужно включить cookies) При установке из исходных текстов, кроме Apache, с поддержкой SSL понадобятся MIT Kerberos v5, cURL и OpenSSL. Вот список необходимых пакетов в Ubuntu, выданных командой:
В других дистрибутивах названия будут несколько другими. Теперь распаковываем полученный архив с исходными текстами, заходим внутрь и последовательно даем команды: $ ./autogen $ ./configure --enable-mod_webkdc Остальные параметры включены по умолчанию, поэтому можно их не указывать. Если скрипт не найдет некоторые библиотеки, их потребуется указать с помощью --with-krb5, --with-openssl, --with-curl и --with-ldap. Затем:
Если все тесты прошли успешно, устанавливаем: $ sudo make install В комплект WebAuth входит набор для тестирования работы сервиса, если планируется его использование, вводим: $ sudo make install-tests И если планируется на этом же компьютере использовать WebKDC: $ sudo make install-webkdc Теперь создаем каталог, в котором будут храниться настройки, принципалы, токены и некоторые другие файлы: $ sudo mkdir -p /etc/apache2/webauth $ sudo mkdir -p /etc/apache2/webkdc Смотрим, с правами какого учетного имени работает веб-сервер:
Этот пользовательский бюджет должен быть владельцем созданных каталогов: $ sudo chown -R www-data:www-data /etc/apache2/webkdc /etc/apache2/webauth При установке с помощью пакетов, в Ubuntu эти два каталога можно найти в /etc. Поскольку мы имеем дело с Kerberos, поэтому в обязательном порядке синхронизируем время.
Рисунок 3. Пакеты Ubuntu Настройка WAS Все настройки сервера, который для аутентификации будет использовать WebAuth, производятся в конфигурационном файле веб-сервера Apache – httpd.conf (в Ubuntu apache2.conf). Настройки можно условно разделить на две части: описание параметров модуля WebAuth и настройка доступа к ресурсам. Сначала первая часть: # Загружаем модуль LoadModule webauth_module /usr/lib/apache2/modules/mod_webauth.so # Расположение AES-ключей и токенов для связи с WebKDC относительно корня веб-вервера WebAuthKeyring webauth/keyring WebAuthServiceTokenCache webauth/service_token_cache # Расположение keytab-файла Kerberos WebAuthKeytab webauth/keytab # Адрес, куда будет перенаправлен пользователь для регистрации WebAuthLoginURL https://grinder.com/login/ # Адрес для связи с сервером WebKDC WebAuthWebKdcURL https://grinder.com/webkdc-service/ # Название сервиса, используемого для связи с WebKDC WebAuthWebKdcPrincipal service/webkdc@GRINDER.COM # Автоматическое перенаправление пользователя на SSL, при попытке соединиться # по не защищенному каналу в доступе будет отказано и журнале появится запись: # mod_webauth: connection is not https, denying request WebAuthSSLRedirect on WebAuthDebug on # Если используется сам подписанный сертификат для работы с WebKDC, добавляем WebAuthWebKdcSSLCertFile webauth/webkdc.cert # В отладочном режиме можно включить доступ к URL /webauth-status, # который покажет статус работы # mod_webauth #<Location /webauth-status> # SetHandler webauth # Order allow,deny # Allow from all #</Location> Настройки просты и понятны. Остается только создать keytab. Kerberos – штука тонкая, и малейшая неточность приведет к тому, что WAS откажется работать, полностью блокируя доступ к серверу. В документации проекта по этому поводу только одна строка, рассказывающая, как получить такой файл со Стэнфорда. О настройках Kerberos в журнале уже говорилось [7], коротко напомню, как это сделать. Устанавливаем пакеты: $ sudo apt-get install krb5-admin-server krb5-kdc krb5-config krb5-user krb5-clients Редактируем файлы /etc/krb5.conf и /etc/krb5kdc/kdc.conf под настройки своей системы. Запускаем два сервера: $ sudo /etc/init.d/krb5-kdc restart $ sudo /etc/init.d/krb5-admin-server restart Теперь создаем принципалы и ключи: $ sudo kdb5_util create –s Создаем принципал для административных целей: $ sudo kadmin.local -q "addprinc admin/admin" И далее в интерактивном режиме создаем все необходимые принципалы для узла, KDC и пользователей:
Все созданные ключи принципала записываются в файл /etc/krb5.keytab. Этот файл и будем использовать при работе WebAuth. Лучше всего создать символическую ссылку: $ sudo ln –s /etc/krb5.keytab /etc/apache2/webauth/keytab $ sudo chown www-data:www-data /etc/apache2/webauth/keytab Настройка доступа к ресурсам стандартна для Apache, здесь можно использовать любой удобный вариант. Чтобы включить проверку WebAuth, достаточно в файл .htaccess вписать: AuthType WebAuth Require valid-user Или в httpd.conf описать ресурс таким образом: <Location "/private/"> AuthType WebAuth require valid-user </Location> Конечно, максимальная защита достигается при включении всех возможных проверок пользователя, в том числе и адреса: <Location "/private/"> AuthType WebAuth require valid-user order deny,allow deny from all allow from 192.168 satisfy any </Location> Для удаления cookies без закрытия окна браузера можно использовать страницу logout: <Location /private/logout> WebAuthDoLogout on </Location> Без WebKDC эта схема не будет иметь смысла, поэтому приступаем к его настройкам. Настройка WebKDC Напомню, WebKDC не обязательно должен находиться на том же узле, что и WAS, учитывая, что безопасность всей системы WebAuth зависит от безопасности WebKDC, последний должен быть максимально защищен. Установки в конфигурационном файле веб-сервера практически аналогичны: # Загружаем модуль LoadModule webkdc_module /usr/lib/apache2/modules/mod_webkdc.so WebKdcServiceTokenLifetime 30d WebKdcKeyring webkdc/keyring WebKdcKeytab webkdc/keytab WebKdcTokenAcl webkdc/token.acl WebKdcDebug on LogLevel debug # Создадим алиасы ScriptAlias /login "webkdc/login.fcgi" ScriptAlias /logout "webkdc/logout.fcgi" Alias /images "webkdc/images/" Alias /help.html "webkdc/help.html" Теперь по порядку. Как создавать файл keytab, показано выше, он должен соответствовать параметру WebAuthWebKdcPrincipal в конфигурациях WAS. Файл keyring, в котором содержится AES-ключ, используемый при соединении с mod_webauth - mod_webkd, cоздается с помощью утилиты wa_keyring: $ cd /etc/apache2/webkdc Создадим ключ, который будет действителен в течение двух дней: $ sudo wa_keyring -f ./keyring add 2d Посмотрим, что внутри:
Все доступные ключи можно просмотреть с помощью параметра list:
Шаблоны страниц, которые будут выведены пользователю при регистрации, ошибке и прочие, находятся в каталоге /usr/share/weblogin/generic/templates. В том случае, если установка производилась из исходных текстов, в файле /usr/share/perl5/WebKDC/Config.pm пути могут не совпадать с принятыми в дистрибутиве. Можно отредактировать их в нем, но лучшим вариантом является использование файла webkdc.conf, который должен находиться в подкаталоге /etc/apache2/webkdc. Открываем его и указываем правильные настройки: our $KEYRING_PATH = "/etc/apache2/webkdc/keyring"; our $TEMPLATE_PATH = "/usr/share/weblogin/generic/templates"; # Адрес, по которому будет находиться сервис WebKDC our $URL = "https://localhost/webkdc-service/"; Для работы нам понадобится еще один файл token.acl, в котором описывается шаблон разрешенных токенов, которые может создавать WebKDC. Копируем пример на место: $ sudo cp webauth-3.5.4/src/modules/webkdc/token.acl /etc/apache2/webkdc/ Снимаем комментарий в первой строке и указываем шаблон: krb5:service/*@grinder.com id На этом настройки можно считать законченными. Перезапускаем веб-сервер: $ sudo /etc/init.d/apache2 restart В журнале веб-сервера должна появиться запись об успешной инициализации модулей:
При попытке получить доступ к закрытому с помощью WebAuth ресурсу пользователь будет переключен на защищенное SSL-соединение и появится страница, запрашивающая пароль. Пора подводить итог всего сказанного. Итоги Без сомнения, WebAuth обладает достаточно впечатляющими возможностями, позволяя организовать безопасный доступ к защищенным ресурсам, используя один сервер для аутентификации. Правда, для того чтобы заставить эту систему полноценно работать, администратору придется потратить не один час на ее первоначальную настройку. Но все затраты на установку и настройку затем с лихвой окупятся удобством в использовании.
|
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
