Система аутентификации веб-пользователей WebAuth::Журнал СА 6.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5400
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6594
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7877
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 8169
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 7165
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Система аутентификации веб-пользователей WebAuth

Архив номеров / 2007 / Выпуск №6 (55) / Система аутентификации веб-пользователей WebAuth

Рубрика: Безопасность /  Безопасность

Сергей Яремчук СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Система аутентификации веб-пользователей WebAuth

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

На страницах журнала уже шла речь о достоинствах и недостатках стандартных типов аутентификации basic и digest [1, 2] и был дан пример одной из более защищенных реализаций DACS (Distributed Access Control System). Но это не единственное решение. В Стэнфордском университете уже несколько лет успешно используется система одноразовой регистрации (SSO – single sign-on) WebAuth. Пользователь, который хочет получить доступ к одному из ресурсов, регистрируется только один раз на центральном сервере (http://weblogin.stanford.edu, см. рис. 1) при переходе на другой веб-сайт этой группы серверов вводить пароль уже не потребуется. Если пользователь имеет право посетить ресурс, он к нему будет допущен автоматически.

Рисунок 1. WebLogin Стэнфордского университета

Рисунок 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 команда поиска выдаст длинный список пакетов:

$ sudo apt-cache search webauth

libapache2-webauth - Apache 2 modules for WebAuth authentication

libapache2-webkdc - Apache 2 modules for a WebAuth authentication KDC

libwebauth-perl - Perl library for WebAuth authentication

libwebauth1 - Shared libraries for WebAuth authentication

libwebauth1-dev - Development files for WebAuth authentication

libwebkdc-perl - Perl library for WebAuth authentication

webauth-tests - Tests for the WebAuth authentication modules

webauth-utils - Command-line utilities for WebAuth authentication

webauth-weblogin - Central login server for WebAuth authentication

Все эти пакеты понадобятся при настройке и тестировании работы сервера. Именно в дистрибутивах 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)

Рисунок 2. Регистрация пользователей в WebAuth (нужно включить cookies)

При установке из исходных текстов, кроме Apache, с поддержкой SSL понадобятся MIT Kerberos v5, cURL и OpenSSL. Вот список необходимых пакетов в Ubuntu, выданных командой:

$ sudo apt-cache search webauth

apache2-threaded-dev libapr1-dev libaprutil1-dev

libcurl3-openssl-dev libdb4.4-dev libldap2-dev libpq-dev 

libsqlite3-dev uuid-dev

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

$ ./autogen

$ ./configure --enable-mod_webkdc

Остальные параметры включены по умолчанию, поэтому можно их не указывать. Если скрипт не найдет некоторые библиотеки, их потребуется указать с помощью --with-krb5, --with-openssl, --with-curl и --with-ldap.

Затем:

$ make

$ make check

...

Running all tests listed in ./TESTS.  If any tests fail, run the failing

test program by hand to see more details.  The test program will have

the same name as the test set but with "_test" appended.

 

libwebauth/attrs........ok

libwebauth/base64.......ok

libwebauth/hex..........ok

libwebauth/key..........ok

libwebauth/random.......ok

libwebauth/token........ok

 

All tests successful.

Files=6,  Tests=7374,  0.99 seconds (0.74 usr + 0.14 sys = 0.88 CPU)

Если все тесты прошли успешно, устанавливаем:

$ 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 grep User /etc/apache2/apache2.conf

User www-data

Этот пользовательский бюджет должен быть владельцем созданных каталогов:

$ sudo chown -R www-data:www-data /etc/apache2/webkdc /etc/apache2/webauth

При установке с помощью пакетов, в Ubuntu эти два каталога можно найти в /etc. Поскольку мы имеем дело с Kerberos, поэтому в обязательном порядке синхронизируем время.

Рисунок 3. Пакеты Ubuntu

Рисунок 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 и пользователей:

$ sudo kadmin.local -p admin/admin

Authenticating as principal admin/admin with password.

kadmin.local:  addprinc -randkey host/grinder.com

Principal "host/grinder.com@GRINDER.COM" created.

kadmin.local:  addprinc grinder

Enter password for principal "grinder@GRINDER.COM":

Re-enter password for principal "grinder@GRINDER.COM":

Principal "grinder@GRINDER.COM" created.

kadmin.local:  addprinc -randkey service/webkdc

Principal " service/webkdc@GRINDER.COM" created.

kadmin.local:  ktadd service/webkdc

Entry for principal service/webkdc with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:

/etc/krb5.keytab.

Entry for principal service/webkdc with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.

kadmin.local: quit

Все созданные ключи принципала записываются в файл /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

Посмотрим, что внутри:

$ sudo cat keyring

v=1;n=1;ct0=1179336753;va0=1179509553;kt0=1;

kd0=d31f548b8bab815b62afa96936105c2c;

grinder@grinder.com:/etc/apache2/webkdc

Все доступные ключи можно просмотреть с помощью параметра list:

$ sudo wa_keyring -f keyring list

Path: keyring

 

id  Created              Valid after          Fingerprint

 0  05/16/2007 20:32:33  05/18/2007 20:32:33  f08f5b1a75df2c1d2d38ccdfe570a75f

Шаблоны страниц, которые будут выведены пользователю при регистрации, ошибке и прочие, находятся в каталоге /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

В журнале веб-сервера должна появиться запись об успешной инициализации модулей:

[Wed May 16 21:47:35 2007] [notice] mod_webauth: initialized (3.5.4)

[Wed May 16 21:47:35 2007] [notice] Apache/2.2.3 (Ubuntu) PHP/5.2.1 WebAuth/3.5.4 WebKDC/3.5.4 SSL/0.9.7 configured -- resuming normal operations

При попытке получить доступ к закрытому с помощью WebAuth ресурсу пользователь будет переключен на защищенное SSL-соединение и появится страница, запрашивающая пароль.

Пора подводить итог всего сказанного.

Итоги

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

Но все затраты на установку и настройку затем с лихвой окупятся удобством в использовании.

  1. Мичурин А. Базовая HTTP-авторизация – защита от честных людей. //Журнал «Системный администратор», № 5, 2005 г. – C. 88-92.
  2. Мичурин А. В чем сильные и слабые стороны HTTP digest-авторизации. //Журнал «Системный администратор», № 10, 2005 г. – C. 44-51.
  3. Яремчук С. Cистема контроля доступа к веб-сервису DACS. //Журнал «Системный администратор», № 8, 2006 г. – C. 74-79.
  4. Сайт проекта WebAuth – http://webauth.stanford.edu.
  5. Сайт проекта WebAuth-IIS – http://www.adunar.com/webauth.
  6. Сайт проекта SPIE – http://spie.oucs.ox.ac.uk.
  7. Кондрин М. Развертываем Heimdal Kerberos. //Журнал «Системный администратор», № 7, 2005 г. – С. 20-25.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru