Разработка системы межсайтовой авторизации или технологии

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
Институт математики и компьютерных наук
Кафедра информационной безопасности
Допустить к защите в ГАК
Заведующий кафедрой
информационной безопасности,
д.т.н., профессор А.А. Захаров
“____” _________ 2010 г.
Голышева Вячеслава Валерьевича
«Разработка системы межсайтовой авторизации или технологии
единого входа (Single Sign On)»
(выпускная квалификационная работа)
Научный руководитель:
старший преподаватель
__________Нестерова О.А.
Автор работы:
__________ Голышев В.В.
Тюмень 2010
Оглавление
Введение ................................................................................................... 3
1.Технологии............................................................................................ 5
1.1 1С - Битрикс ................................................................................................. 5
1.2 Технология переноса посетителей между сайтами ................................. 7
1.3 Модуль AD/LDAP ..................................................................................... 10
1.4 Схема работы модуля ............................................................................... 13
1.5 Настройка многосайтовой конфигурации в 1С-битрикс. ..................... 14
1.6 OpenID ........................................................................................................ 21
1.7 Кто контролирует OpenID? ...................................................................... 22
1.8 Терминология OpenID .............................................................................. 23
1.9 Simple Registration Extension .................................................................... 24
1.10 Применение технологии OpenID ........................................................... 26
1.11 Протокол Диффи-Хеллмана................................................................... 27
1.12 Описание алгоритма ............................................................................... 27
1.13 Недостатки OpenID в системе университета ....................................... 35
1.14 Windows Live ID ...................................................................................... 37
1.15 SAML ........................................................................................................ 38
2.Настройка межсайтовой авторизации между битриксом и
удалёнными сайтами............................................................................. 40
3.Безопасность при межсайтовом взаимодействии........................... 49
Список литературы ............................................................................... 51
2
Введение
В настоящее время простые Интернет сайты отходят на второй план, и все
большую популярность получают, так называемые, Интернет порталы.
Интенсивному
развитию
порталов
способствует
ряд
программных
продуктов, позволяющих объединить в единое пространство информацию из
различных источников (Например: форум, фотогалерея, библиотека, wiki,
почта, новости и т.д.).
Каждый тип Интернет ресурса имеет собственный движок для работы с
персональной информацией пользователя (phpBB для форума, Gallery для
фотогалереи и т.д.).
В ТюмГУ Институт математики и компьютерных наук функционирует
несколько сайтов от образовательных порталов до сайтов для тестирования и
на каждом сайте существует своя система управления контентом, механизм
управления новостями и т.д..
Регистрация пользователей давно стала рутинной операцией для многих и
многих интернет-сервисов, будь то форумы, блоги или новостные сайты.
Зарегистрированные пользователи получают доступ к дополнительным
функциям сервиса. По мере его учёбы студент получает доступ на все эти
порталы в системе универсистета. И для каждого нужен свой пароль и
пользователь.
Минусы
таких
порталов
в
том,
что
происходят
хранения/запоминания множества связок «логин/пароль». Зачастую в
учебных заведениях данные для авторизации выдаются на кафедре и ладно
если тебе выдали логин ivanov_123 так могут же ещё добавить сюда имя
через нижнее подчеркивание и написать ещё это всё в разных регистрах
такая картина не особо радует.
Образуется своего рода «заповедник» с
множеством логинов и паролей для каждого сайта — и это далеко не всегда
удобно, так как пароли имею свойства забывается и теряться.
3
Исходя из этого, целью работы является разработать техногологию
межсайтовой авторизации в сети интернет для портала ИМКН .
Для реализации технологии единого входа поставим перед собой следующие
задачи:
1. Проанализировать
существующие
технологии
единого
(межсайтовой авторизации)
2. Настройка межсайтовой авторизации портала ИМКН
3. Тестирование настроек сайта или вопрос безопасности.
4
входа
Технологии
1С - Битрикс
Идея технологии межсайтовой авторизации в том, что пользователь
авторизировавшись на одном портале переходит из одного портала в другой
без повторной авторизации.
Под сайтом понимается совокупность следующих понятий:
 Учетная запись в общей базе данных;
 Публичная часть сайта (файлы и папки);
 Настройки сайта.
Другими словами, сайт – это созданная в системе сущность, обладающая
определенным набором данных (контента) и параметров (язык, шаблон
дизайна, форматы даты и времени). Данные могут быть уникальными в
рамках этого сайта (публичная часть, индивидуальные инфоблоки, вебформы, опросы, форумы и т.п.) или разделяемыми между несколькими
сайтами.
Один из сайтов который находится в наличии у ИМКН это сатй imkn.kib.ru
на котором установлена платформа 1С - Битрикс.
Программные продукты «1С-Битрикс» - профессиональные системы для
управления
веб-проектами
и
создания
корпоративных
порталов.
Система ориентирована на корпоративные сайты, информационные и
справочные порталы, социальные сети, интернет-магазины, сайты СМИ,
пригодна для создания других видов веб-ресурсов.
Для
хранения
данных
сайта
используется
реляционная
СУБД.
Поддерживаются следующие СУБД: MySQL, Oracle, MS SQL. Продукт
5
работает на Microsoft Windows и UNIX‐подобных платформах, включая
GNU/Linux.
Идеология системы представляет собой разделение логики на модули и
компоненты.
Модули
в
«1С-Битрикс» —
это
набор
программных
компонентов, отвечающих за работу с различными типами баз данных, а
также предоставляющих унифицированный API системы. Компоненты
служат для связи конечного представления информации на сайте с
программным ядром системы. Они используют API, созданный модулями,
для организации выборки, модификации, управления информацией в базе
данных.
Критерии по которым он был выбран для реализации межсайтовой
авторизации:
-
во-первых : в нём есть система управления контентом через которую
можно добавлять, изменять новости структуру сайта и.т.д.;
-
во-вторых : в нем имется встроенный модуль AD/LDAP который
синхронизирует данные из Active Directory которые находятся на серверной
станции и с базой битрикса.
-
в-третих : это преимущества для разработчиков одной из которых
является механизм информационных блоков (инфоблоков). Он позволяет
легко создавать пользовательские типы содержания. Другой особенностью
современных версий Битрикса является мощный визуальный HTMLредактор, позволяющий размещать на странице как обычную HTML
информацию, так и различные динамические компоненты, работу которых
обеспечивает CMS.
6
Технология переноса посетителей между сайтами
Особенностями многосайтовой системы являются:
- единые права на все сайты
- единый набор функций пользователей на все сайты
- единая система ведения статистики на все сайты
Исходя из этого, вытекает следующая задача распознать одного и того же
посетителя, приходящего на разные сайты c разными доменными именами в
рамках одного портала.
Распознавание посетителей осуществляется с помощью файлов cookie
(куков), представляющих из себя информацию, передаваемую между вебсервером и браузером и хранимую только на локальном диске посетителя.

При первом заходе посетителя на сайт A ему выдаются ряд
идентификаторов,
используемых
разными
модулями
(например,
идентификатор посетителя или идентификатор покупателя в модуле
интернет-магазина и т.д.), которые запоминаются в хранимых cookie
принадлежащих сайту A.

Когда посетитель в следующий раз возвращается на этот же сайт
A,
он
будет "узнан" благодаря информации хранимой в cookie,
принадлежащих сайту A.

Теперь представим, что этот же посетитель пришел на сайт B.
Возникает задача "узнать" его как посетителя в недавнем прошлом
сайта A. Под термином "узнать" здесь
понимается
-
получить
идентификаторы, выданные ему на сайте A. Проблема осложняется
тем, что если доменное имя сайта B отличается от доменного
имени сайта A, то информация хранимая в cookie принадлежащих
сайту A не может быть получена при заходе посетителя на сайт B.
7
Также есть обратная проблема - cookie устанавливаемые с сайта A (и
на этот же сайт A) не могут быть установлены на сайт B. Такова
политика безопасности браузеров. Для
решения
вышеописанных
проблем используется технология переноса cookie посетителя между
разными сайтами с разными доменными именами и принадлежащих
одному порталу.
Алгоритм работы технологии можно описать так:

Когда посетитель заходит на сайт A, идентификаторы, выдаваемые
ему, будут сохраняться в cookie с помощью функции, основная
задача которой не только установить cookie для текущего сайта A, но и
запомнить данные этого cookie для дальнейшего распостранения его на
другие сайты B, C, D.

В
конце
визуальной
части
эпилога
вызывается
функция
CMain::ShowSpreadCookieHTML. Данная функция выводит набор
IMG'ов, в каждом из которых вызывается скрипт /bitrix/spread.php с
того
домена
на
который необходимо установить cookie. Таким
образом для сайтов B, C, D будет создано три IMG'а, в каждом из
которых
будет
вызван
скрипт
http://доменное
имя
сайта/bitrix/spread.php. В параметрах этого скрипта будет передана
необходимая информация для установки cookie. Эта информация
передается в зашифрованном виде и подписана зашифрованным
лицензионным ключом этого портала. В результате получится, что
cookie, установленный на сайте A, будет скопирован (перенесен) на
другие сайты - B, C, D.

Аналогично происходит и для других сайтов. Если посетитель, зайдя
на сайт B, получит какой либо идентификатор который необходимо
сохранить в cookie, то этот идентификатор будет также сохранен и
8
для других сайтов A, C, D. Таким образом мы добиваемся единого
набора cookie для всех сайтов одного портала.
Использование данной технологии позволяет:

В модуле "Статистика" подсчитывать уникальных посетителей для
всего портала.

В модуле "Реклама, баннеры"
позволяет корректно учитывать
количество показов одного баннера одному посетителю. Другие
модули
также
технология
активно
будет
используют
использоваться
эту
для
методику.
Указанная
сайтов многосайтовой
конфигурациии, если активирована опция: Распространять куки на все
домены в настройках главного модуля.
9
Модуль AD/LDAP
Модуль AD/LDAP интеграция реализован с учетом особенностей работы
LDAP (Lightweight Directory Access Protocol) и AD (Active Directory)
протоколов, один из которых должен быть установлен на корпоративном
сервере.
В основе работы перечисленных протоколов лежит принцип хранения
информации в виде записей, обладающих набором атрибутов и хранящихся в
базе данных с древовидной иерархической структурой. Таким образом, при
настройке на сервере локальной вычислительной сети LDAP или AD
протокола информация о группах пользователей будет представляться в
следующем виде (Error! Reference source not found.):
Структура записей
Используя
данную
структуру
хранения
данных,
модуль
AD/LDAP
интеграция позволяет настраивать соответствие групп пользователей
корпоративной сети группам пользователей сайта.
Соответствие групп пользователей задается в специальной Таблице
соответствий в административном разделе сайта. При этом возможно
10
несовпадение
имен
групп
пользователей
сайта
с
именами
групп
пользователей корпоративной сети. Например, группе пользователей
корпоративной сети
Techsupport, к которой относятся сотрудники
технической поддержки корпоративной сети, может быть поставлена в
соответствие группа пользователей Techsupport stuff, созданная на сайте.
Теперь сотрудники службы технической поддержки корпоративной сети
смогут выполнять обязанности сотрудников службы технической поддержки
сайта.
Группы пользователей внутри компании обладают правами на доступ к
определенным ресурсам корпоративной сети, а сопоставленные им группы
пользователей на сайте обладают правами на доступ к ресурсам сайта.
Например, группа пользователей Techsupport наделена правами на доступ к
почтовому серверу сети, а группа пользователей сайта Techsupport stuff
обладает правами на доступ к модулю Техподдержка.
В соответствии с приведенным выше примером, пользователь, относящийся
к группе Techsupport корпоративной сети, при попытке авторизации на
сайте будет добавлен в группу пользователей сайта Techsupport stuff. После
чего в системе автоматически будет заведен бюджет данного пользователя,
на основе его данных, которые хранятся на корпоративном сервере.
Допустима привязка пользователя к одной, двум или боле группам. В
системе могут быть настроены группы пользователей, для которых не
установлено соответствие с группами пользователей в корпоративной сети.
Принадлежность
пользователей
к
такой
группе
задается
вручную
администратором системы. Все изменения бюджета пользователя на
корпоративном сервере будут автоматически учтены в бюджете пользователя
в системе управления сайтом во время его следующей авторизации.
Изменения затронут только те группы, для которых задано соответствие
группам пользователей корпоративной сети.
11
Таким образом, модуль AD/LDAP интеграция позволяет:

интегрировать
систему
"1С-Битрикс:
Управление
сайтом"
в
настроить соответствие групп пользователей корпоративной сети
и
корпоративную сеть;

групп пользователей сайта;

автоматически создавать бюджет пользователя после его регистрации
исходя из Таблицы соответствий (данные для создания бюджета
пользователя запрашиваются из базы данных корпоративного сервера);

централизованно управлять изменениями бюджетов пользователей
системы через корпоративный сервер.
Модуль AD/LDAP интеграция так же позволяет использовать NTML
авторизацию. Чтобы ею воспользоваться, нужен веб-сервер IIS или Apache
с модулем mod_ntlm или mod_auth_sspi.
12
Схема работы модуля
Общая
схема
работы
модуля
может
быть
описана
следующей
последовательностью действий:
1. Пользователь заходит на сайт и авторизуется (вводит логин и пароль,
используемый для авторизации в корпоративной сети);
2. Система обращается к указанному в настройках AD/LDAP серверу и
проверяет наличие пользователя с указанными данными (паролем и
логином) в базе пользователей на корпоративном сервере:

если пользователя с такими данными в корпоративной сети не
существует, то система запрещает вход на сайт;

если
пользователь
существует,
то
определяется
группа
пользователей корпоративной сети, к которой он относится, и
сопоставленная ей группа пользователей сайта (с помощью
Таблицы соответствий).
3. Далее проверяется наличие бюджета данного пользователя в системе:

если бюджет пользователя не найден, то система получает данные о
пользователе из базы данных корпоративного сервера и создает его
бюджет.
4. Если бюджет пользователя в системе уже был создан, т. е. пользователь
уже авторизовался на сайте, то система проверяет, были ли
произведены какие-либо изменения с бюджетом пользователя на
корпоративном сервере. Если да, то соответствующие изменения
производятся и с бюджетом пользователя в системе управления
сайтом.
5. Пользователь получает разрешение на доступ к ресурсам сайта и
авторизуется. Права пользователя определяются в зависимости от
настроек группы пользователей сайта, к которой он был приписан.
13
Настройка многосайтовой конфигурации в 1С-битрикс.
Для этого на веб-сервере (Apache, IIS) нужно сконфигурируем несколько
виртуальных хостов (веб-серверов). Каждый сайт в системе получает
собственную
корневую
директорию
(Document
Root),
в
которой
располагается его публичная часть. Иногда каждый сайт может даже иметь
собственный IP адрес.. Ядро системы при такой реализации физически
расположено в одном месте, скажем, на основном сайте (папки /bitrix/ и
/upload/), а на остальных сайтах делаются символические ссылки на данные
папки.
Будем использовать для примера конфигурацию из двух сайтов:
· www.site1.com
· www.site2.com
Для каждого сайта надо сконфигурировать отдельный виртуальный вебсервер Apache.
Если разместить сайты в соответствующих каталогах на диске:
· /home/www/site1/
· /home/www/site2/
В конфигурационном файле httpd.conf веб-сервера Apache это будет
соответствовать примерно следующей двум записям, каждая из которых
описывает свой "виртуальный сервер" (в терминологии, принятой в Apache):
для site1:
<VirtualHost *:80>
ServerAdmin admin@site1.com
DocumentRoot "/home/www/site1/"
ServerName site1.com
ServerAlias *.site1.com
14
ErrorLog logs/site1.log
CustomLog logs/site1.log common
</VirtualHost>
для site2:
<VirtualHost *:80>
ServerAdmin admin@site2.com
DocumentRoot "/home/www/site2/"
ServerName site2.com
ServerAlias *.site2.com
ErrorLog logs/site2.log
CustomLog logs/site2.log common
</VirtualHost>
Обратите внимание, что параметр DocumentRoot для каждого сайта
указывает в разный каталог на диске, в котором должен быть размещен
соответствующий сайт.
Строки <VirtualHost *:80> указывают на то, что веб-сервер будет отвечать на
любом IP адресе, но переменная ServerAlias говорит о том, что каждый из
сайтов будет отвечать только по определенному доменному имени.
Т.е. доменное имя www.site1.com будет обрабатываться одним вебсервером Apache, который работает с каталогом /home/www/site1/, а
www.site2.com - другим вебсервером, работающим с каталогом
/home/www/site2/.
Возможен так же вариант конфигурирования для разных IP адресов.
Ниже приведен пример конфигурации Apache для двух разных IP адресов:
<VirtualHost 192.168.0.1:80>
ServerAdmin admin@site1.com
DocumentRoot "/home/www/site1/"
ServerName site1.com
ErrorLog logs/site1.log
CustomLog logs/site1.log common
Options +FollowSymLinks
</VirtualHost>
15
<VirtualHost 192.168.0.2:80>
ServerAdmin admin@site2.com
DocumentRoot "/home/www/site2/"
ServerName site2.com
ErrorLog logs/site2.log
CustomLog logs/site2.log common
Options +FollowSymLinks
</VirtualHost>
В этом случае при соответствующей настройке DNS для разных доменных
имен, каждый "виртуальный сервер" (в терминологии Apache) будет работать
на отдельном IP адресе и отвечать только по определенному доменному
имени. Следующий шаг - это установка продукта. Продукт
устанавливается в один из сайтов. Чтобы ядро могло работать для обоих
сайтов, необходимо создать символические ссылки для сайта, в котором
нет установленного ядра. Ссылки потребуются для папок /bitrix и /upload.
1. установите программный продукт "1С-Битрикс: Управление сайтом"
сначала в каталог первого сайта /home/www/site1/
2. создайте каталог /home/www/shared/, в котором будут располагаться
общие для всех сайтов файлы: mkdir /home/www/shared
3. перенесите весь каталог /home/www/site1/bitrix/ в
/home/www/shared/bitrix/:
mv /home/www/site1/bitrix /home/www/shared/bitrix
4. перенесите весь каталог /home/www/site1/upload/ в
/home/www/shared/upload/:
mv /home/www/site1/upload /home/www/shared/upload
5. создайте символическую связь для каталога /bitrix/ в каждом из сайтов:
· ln -s /home/www/shared/bitrix /home/www/site1/
16
· ln -s /home/www/shared/upload /home/www/site1/
· ln -s /home/www/shared/bitrix /home/www/site2/
· ln -s /home/www/shared/upload /home/www/site2/
6. убедитесь, что веб-сервер (Apache, IIS) имеет право на запись в
каталог
/home/www/shared/ (это необходимо будет для работы системы
обновлений и загрузки графических файлов)
7. разместите публичную часть второго сайта в каталог /home/www/site2/
Для создания символических связей в Windows необходимо
воспользоваться дополнительными программами, например, Far Manager или
Junction от Sysinternals.
Примечание: в ряде случаев, например если web сервер работает в chroot,
необходимо делать относительные ссылки.
Пример:
/var/www/s1 - первый сайт
/var/www/s2 - второй сайт
/var/www/shared - папка с ядром системы
Заходим в /var/www/s1 и создаём ссылки:
ln -s ../shared/bitrix bitrix
ln -s ../shared/upload upload
Переходим в /var/www/s2 и выполняем те же команды.
Следующий шаг в настройке данной конфигурации - правильное
конфигурирование сайтов в программном продукте.
17
Настройка сайтов выполняется в административном разделе системы в
административном пункте меню "Настройки системы" - "Сайты".
Выбираем "Изменить" параметры сайта #1 (www.site1.com) и указываем в
них:
· Название: site1
· Доменное имя: www.site1.com
· Папка сайта: /
· Название сайта: Корпоративный сайт компании "Название компании"
· URL сервера: www.site1.com
· Путь к корневой папке веб-сервера для этого сайта: /home/www/site1/
Если DNS настроен таким образом что ваш сайт отвечает на адрес
http://site1.com, то в поле Доменное имя желательно указывать без www.
Можно перечислить в этом поле с новой строки любое число доменных
имен, по которым вы хотите, чтобы отвечал сайт (или уже отвечает).
Важно иметь в виду, что значения, указанные в поле Доменное имя,
используются продуктом для распространения в указанные домены
информации о посетителях по технологии переноса посетителей. Поэтому
крайне желательно указывать полный список доменов, по которым может
ответить сайт.
Очень важно не указывать в списке доменов сайты, которые не
работают на данном экземпляре продукта. Указанный неправильно или
несуществующий домен может нетолько замедлить работу пользователей,
но и фактически не позволит перенести данные в сайты, работающие не на
общем экземпляре продукта.
Аналогично настроим параметры сайта #2 (www.site2.com):
18
· Название: site2
· Доменное имя: site2.com
· Папка сайта: /
· Название сайта: Интернет-магазин компании "Название компании"
· URL сервера: www.site2.com
· Путь к корневой папке веб-сервера для этого сайта: /home/www/site2/
Обратите внимание, что для двух сайтов в параметре "Папка сайта" указано
одинаковое значение - "/". Это связано с тем, что сайты обслуживаются
разными "виртуальными серверами" (в терминологии Apache) у которых
для размещения файлов использован разный каталог.
Также необходимо обратить на параметр "Путь к корневой папке вебсервера для этого сайта". Для разных сайтов у него свое значение,
взятое из параметра DocumentRoot настроек соответствующего
"виртуального сервера" (см. выше пример части файла httpd.cnf настроек
Apache).
Необходимо иметь в виду, что при организации многосайтовости по данному
способу, вы можете использовать как виртуальные сервера одной
инсталляции Apache, так и просто разные инсталляции Apache. Аналогично и
для других веб-серверов: IIS, EServ и т.д.
Конфигурация готова к работе.
Настройка сайта
В момент добавления записи о новом сайте в таблицу сайтов
необходимо указать следующие параметры:
· идентификатор сайта – двухсимвольная комбинация, например: ru, en, de,
s1, s2 и т.п.
19
· название – произвольное название сайта, наряду с идентификатором
сайта используется в различных административных формах для указания
привязки к тому или иному сайту.
· доменное имя – указываются доменные имена, которые соответствуют
данному сайту.
Теперь о минусах этого варианта многосайтовости.
Чтобы настроить этот проект многосайтовости нужно чтобы ядро системы
битрикс для всех сайтов было едино как и база. Следовательно, нужно чтобы
все порталы находились на одном сервере, что можно было ядро для
порталов объединить в символической связью .Ещё один критерий версия
Windows NT не должна быть ниже Windows NT 5 и файловая система должна
быть NTFS.
Такой вариант тоже не подходит так как все порталы у университета
находятся на разных виртуальных машинах. И переносить всё на одну не
особо рационально.
20
OpenID
OpenID — это открытая децентрализованная система единого входа на
сайты, порталы, блоги и форумы.
Технология OpenID устраняет необходимость содержать многочисленные
аккаунты на разных вебсайтах. Эта технология позволяет авторизироваться
на многочисленных сайтах с помощью всего лишь одного аккаунта OpenID.
Используя OpenID Вы получаете на выбор несколько провайдеров OpenID,
таких как http://openid.yandex.ru/, https://www.myopenid.com/ и т.д.. Вам
необходимо выбрать того, который наиболее отвечает вашим потребностям
и, самое главное, того, которому Вы доверяете. В то же время, Ваш OpenID
может остаться с Вами, какой бы Провайдер Вы не выбрали, даже при смене
Интернет-провайдера, Ваша учетная запись OpenID останется с Вами. И
самое замечательное, что OpenID технология не является собственностью
какой либо компании, плюс абсолютно бесплатна.
OpenID - это открытая, децентрализованная, свободная технология для
пользователей, формирующих свою личность в Интернет. OpenID использует
уже существующие Интернет-технологии (URI, HTTP, SSL, Diffie-Hellman) и
понимает, что люди уже создают личность для себя будь они на своем блоге,
в фотогалерее и т.п. OpenID позволяет использовать один аккаунт для
доступа к различным сайтам. Отныне вам не нужно регистрироваться на
каждом новом сайте. Вам достаточно один раз зарегистрировать аккаунт
OpenID и использовать его в дальнейшем на любом ресурсе, который
поддерживает технологию OpenID.
OpenID все еще находится на стадии разработки и становится все более и
более популярным. Крупные организации, такие как AOL, Microsoft, Sun,
Novell и т.д. начают предоставлять OpenID аккаунты. Сегодня по нашим
оценкам более 160 млн. пользователей OpenID используют свои аккаунты
для доступа к более чем десяти тысячам сайтов.
21
Кто контролирует OpenID?
OpenID возник из сообщества открытых исходных кодов для решения
проблем, которые не могут быть легко решены другими существующими
технологиями. OpenID - это легкий метод авторизации на огромном
количестве веб сайтов. Таким образом, OpenID не принадлежит никому.
Сегодня каждый может быть в качестве OpenID пользователя или OpenID
провайдера бесплатно и без регистрации.
В поддержку OpenID создан фонд (http://openid.net/foundation) – для решения
всевозможных юридических вопросов, а так же поддержки разработчиков,
создания инфраструктуры с целью расширения и продвижения OpenID.
Как сказал Брэд Фитцпатрик (автор OpenID): "Ни кто не должен планировать
заработать деньги на этом. Наша цель – предоставить все возможности для
использования этой технологии по наиболее либеральной лицензии. Этот
принцип принесет пользу всем нам и всему обществу в целом.".
Это заявление продолжает звучать и сегодня в рамках OpenID сообщества.
22
Терминология OpenID
* Конечный Пользователь — лицо, которое хочет идентифицировать себя
* Идентификатор — URI или XRI, выбранный пользователем в качестве
OpenID-идентификатора
* Провайдер Идентификации — лицо, предоставляющее сервис регистрации
и аутентификации Идентификаторов
* Пользователь Аутентификации — лицо, желающее проверить подлинность
Идентификатора Конечного Пользователя
* Сервер Аутентификации — сервер, проверяющий подлинность
Идентификатора Конечного Пользователя (сервер Провайдера
Аутентификации в большинстве случаев)
* Агент Пользователя — программа (браузер в большинстве случаев),
используемая клиентом, для доступа к Провайдеру или Пользователю
Аутентификации
23
Simple Registration Extension
Первоначально OpenID создавался исключительно для аутентификации
пользователя, но после непродолжительной эксплуатации появилась острая
потребность в предоставлении дополнительной информации о конечном
пользователе. Для решения этой проблемы было разработано расширение
протокола — Simple Registation Extension. Провайдеры аутентификации,
которые поддерживают это расширение, могут хранить информацию о т. н.
«персонах».
«Персона» — запись, содержащая Ваше имя, адрес электронной почты и
другие данные, которые обычно требуются для регистрации на сайтах.
Любая персона может быть выбрана, как «публичная» — её содержимое
сможет посмотреть каждый даже без согласия персоны на это.
(Рис. № 1) Схема работы OpenID
На рис. №1 изображён порядок работы OpenID-аутентификации. Слева OpenID-провайдеры ,а справа - другие сайты, поддерживающие OpenIDрегистрацию. Мы будем считать, что в центре - это профиль пользователя.
24
Справа - сайты, на которые он хочет залогиниться, указав в качестве OpenIDаккаунта ссылку на свой профиль. А слева - его, пользователя, OpenIDпровайдеры, которых, к слову, он может и не иметь вовсе, иметь всего один
(на схеме изображен черным цветом), или иметь несколько (на схеме
дополнительные связи к другим OpenID-провайдерам указаны серым
цветом).
25
Применение технологии OpenID
В OpenID используется протокол, которые позволяют двум сторонам
сгенерировать общий ключ К, не передавая его по каналу который
называется
— Diffie-Hellman Key Exchange Protocol (протокол Диффи-
Хелмана) .
Обмен ключа Диффи-Хеллмэн
является шифровальным протоколом,
который разрешает две стороны, у которых нет никакого предшествующего
знания друг друга, чтобы совместно установить общий секретный ключ по
опасному каналу коммуникаций. Этот ключ может тогда использоваться,
чтобы
зашифровать
последующие
симметрический ключевой шифр.
26
коммуникации,
используя
Протокол Диффи-Хеллмана
Описание алгоритма
Предположим, что обоим абонентам известны некоторые два числа g и p
(например, они могут быть «зашиты» в программное обеспечение), которые
не
являются
секретными
и
могут
быть
известны
также
другим
заинтересованным лицам. Для того, чтобы создать неизвестный более
никому секретный ключ, оба абонента генерируют большие случайные
числа: первый абонент — число a, второй абонент — число b. Затем первый
абонент вычисляет значение A = gamod p и пересылает его второму, а второй
вычисляет B = gbmod p и передаёт первому. Предполагается, что
злоумышленник может получить оба этих значения, но не модифицировать
их (то есть у него нет возможности вмешаться в процесс передачи). На
втором этапе первый абонент на основе имеющегося у него a и полученного
по сети B вычисляет значение Bamod p = gabmod p, а второй абонент на
основе имеющегося у него b и полученного по сети A вычисляет значение
Abmod p = gabmod p. Как нетрудно видеть, у обоих абонентов получилось
одно и то же число: K = gabmod p. Его они и могут использовать в качестве
секретного
ключа,
поскольку
здесь
злоумышленник
встретится
с
практически неразрешимой (за разумное время) проблемой вычисления
gabmod p по перехваченным gamod p и gbmod p, если числа p,a,b выбраны
достаточно большими.
27
Alisa
Bob
Параметрами протокола являются p – большое простое число, g –
порождающий элемент мультипликативной группы Zp*.
1. A→B: ga mod p (где x – случайное секретное число);
2. B→A: gb mod p (где y – случайное секретное число);
3. A: вычисляет K=Ba mod p;
4. B: вычисляет K=Ab mod p.
В результате A и B получают общий сеансовый ключ K.
Итак, как всё это выглядит на практике.
У нас есть 2 файла : index.php и class.openid.php.
При заходе на сайт клиента OpenID пользователь попадает на index.php ,где
вводит свой OpenID Login
И после этого редиректится на сайт провайдера на котором пользователю
предоставляется возможность авторизироваться. Еcли авторизация прошла
успешно происходит генерация трёх переменных g,a,p и вычисляется A= ga
28
mod p кторорый отправляется клиенту переменные g,p,A через GET запрос. С
помощью функции ValidateWithServer() в class.openid.php переданные
переменные кодируются в безопасное представление и вычисляется B = gb
mod p и отправляет серверу. В результате если общий сеансовый ключ
совпадает то происходит авторизация на стороне клиента OpenID.
Структура файла Index.php
<?
require('class.openid.php');
if ($_POST['openid_action'] == "login"){
$openid = new SimpleOpenID;
$openid->SetIdentity($_POST['openid_url']);
$openid->SetTrustRoot('http://' . $_SERVER["HTTP_HOST"]);
$openid->SetRequiredFields(array('email','fullname'));
$openid->SetOptionalFields(array('dob','gender','postcode','country','language','timezone'));
if ($openid->GetOpenIDServer()){
$openid->SetApprovedURL('http://' . $_SERVER["HTTP_HOST"] .
$_SERVER["PATH_INFO"]);
$openid->Redirect();
}else{
$error = $openid->GetError();
echo "ERROR CODE: " . $error['code'] . "<br>";
echo "ERROR DESCRIPTION: " . $error['description'] . "<br>";
}
exit;
}
else if($_GET['openid_mode'] == 'id_res'){
$openid = new SimpleOpenID;
$openid->SetIdentity($_GET['openid_identity']);
$openid_validation_result = $openid->ValidateWithServer();
if ($openid_validation_result == true){
echo "VALID";
}else if($openid->IsError() == true){
$error = $openid->GetError();
echo "ERROR CODE: " . $error['code'] . "<br>";
echo "ERROR DESCRIPTION: " . $error['description'] . "<br>";
}else{
echo "INVALID AUTHORIZATION";
}
}else if ($_GET['openid_mode'] == 'cancel'){ // User Canceled your Request
echo "USER CANCELED REQUEST";
}
?>
<html>
<head>
</head>
29
<body>
<div>
<fieldset id="openid">
<legend>OpenID Login</legend>
<form action="<?echo 'http://' . $_SERVER["HTTP_HOST"] . $_SERVER["PATH_INFO"]; ?>" method="post"
onSubmit="this.login.disabled=true;">
<input type="hidden" name="openid_action" value="login">
<div><input type="text" name="openid_url" class="openid_login"><input type="submit" name="login"
value="login >>"></div>
</form>
</fieldset>
</div>
</body>
</html>
Структура файла class.openid.php
<?
class SimpleOpenID{
var $openid_url_identity;
var $URLs = array();
var $error = array();
var $fields = array();
function SimpleOpenID(){
if (!function_exists('curl_exec')) {
die('Error: Class SimpleOpenID requires curl extension to work');
}
}
function SetOpenIDServer($a) { $this->URLs['openid_server'] = $a;}
function SetTrustRoot($a) { $this->URLs['trust_root'] = $a;}
function SetCancelURL($a) { $this->URLs['cancel'] = $a;}
function SetApprovedURL($a) { $this->URLs['approved'] = $a;}
function SetRequiredFields($a){
if (is_array($a)){
$this->fields['required'] = $a;
}else{
$this->fields['required'][] = $a;
}
}
function SetOptionalFields($a){
if (is_array($a)){
$this->fields['optional'] = $a;
}else{
$this->fields['optional'][] = $a;
}
}
function SetIdentity($a){
if(strpos($a, 'http://') === false) {
$a = 'http://'.$a;
}
/*
$u = parse_url(trim($a));
30
if (!isset($u['path'])){
$u['path'] = '/';
}else if(substr($u['path'],-1,1) == '/'){
$u['path'] = substr($u['path'], 0, strlen($u['path'])-1);
}
if (isset($u['query'])){ // If there is a query string, then use identity as is
$identity = $a;
}else{
$identity = $u['scheme'] . '://' . $u['host'] . $u['path'];
}*/
$this->openid_url_identity = $a;
}
function GetIdentity(){
return $this->openid_url_identity;
}
function GetError(){
$e = $this->error;
return array('code'=>$e[0],'description'=>$e[1]);
}
function ErrorStore($code, $desc = null){
$errs['OPENID_NOSERVERSFOUND'] = 'Cannot find OpenID Server TAG on Identity page.';
if ($desc == null){
$desc = $errs[$code];
}
$this->error = array($code,$desc);
}
function IsError(){
if (count($this->error) > 0){
return true;
}else{
return false;
}
}
function splitResponse($response) {
$r = array();
$response = explode("\n", $response);
foreach($response as $line) {
$line = trim($line);
if ($line != "") {
list($key, $value) = explode(":", $line, 2);
$r[trim($key)] = trim($value);
}
}
return $r;
}
function OpenID_Standarize($openid_identity){
$u = parse_url(strtolower(trim($openid_identity)));
if ($u['path'] == '/'){
$u['path'] = '';
}
31
if(substr($u['path'],-1,1) == '/'){
$u['path'] = substr($u['path'], 0, strlen($u['path'])-1);
}
if (isset($u['query'])){
return $u['host'] . $u['path'] . '?' . $u['query'];
}else{
return $u['host'] . $u['path'];
}
}
function array2url($arr){
if (!is_array($arr)){
return false;
}
foreach($arr as $key => $value){
$query .= $key . "=" . $value . "&";
}
return $query;
}
function FSOCK_Request($url, $method="GET", $params = ""){
$fp = fsockopen("ssl://www.myopenid.com", 443, $errno, $errstr, 3);
if (!$fp) {
$this->ErrorStore('OPENID_SOCKETERROR', $errstr);
return false;
} else {
$request = $method . " /server HTTP/1.0\r\n";
$request .= "User-Agent: Simple OpenID PHP Class
(http://www.phpclasses.org/simple_openid)\r\n";
$request .= "Connection: close\r\n\r\n";
fwrite($fp, $request);
stream_set_timeout($fp, 4); // Connection response timeout is 4 seconds
$res = fread($fp, 2000);
$info = stream_get_meta_data($fp);
fclose($fp);
if ($info['timed_out']) {
$this->ErrorStore('OPENID_SOCKETTIMEOUT');
} else {
return $res;
}
}
}
function CURL_Request($url, $method="GET", $params = "") {
if
(is_array($params)) $params = $this->array2url($params);
$curl = curl_init($url . ($method == "GET" && $params != "" ? "?" . $params : ""));
curl_setopt($curl, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($curl, CURLOPT_HEADER, false);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($curl, CURLOPT_HTTPGET, ($method == "GET"));
curl_setopt($curl, CURLOPT_POST, ($method == "POST"));
if ($method == "POST") curl_setopt($curl, CURLOPT_POSTFIELDS, $params);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($curl);
if (curl_errno($curl) == 0){
32
$response;
}else{
$this->ErrorStore('OPENID_CURL', curl_error($curl));
}
return $response;
}
function HTML2OpenIDServer($content) {
$get = array();
// Get details of their OpenID server and (optional) delegate
preg_match_all('/<link[^>]*rel="openid.server"[^>]*href="([^"]+)"[^>]*\/?>/i', $content, $matches1);
preg_match_all('/<link[^>]*href="([^"]+)"[^>]*rel="openid.server"[^>]*\/?>/i', $content, $matches2);
$servers = array_merge($matches1[1], $matches2[1]);
preg_match_all('/<link[^>]*rel="openid.delegate"[^>]*href="([^"]+)"[^>]*\/?>/i', $content, $matches1);
preg_match_all('/<link[^>]*href="([^"]+)"[^>]*rel="openid.delegate"[^>]*\/?>/i', $content, $matches2);
$delegates = array_merge($matches1[1], $matches2[1]);
$ret = array($servers, $delegates);
return $ret;
}
function GetOpenIDServer(){
$response = $this->CURL_Request($this->openid_url_identity);
list($servers, $delegates) = $this->HTML2OpenIDServer($response);
if (count($servers) == 0){
$this->ErrorStore('OPENID_NOSERVERSFOUND');
return false;
}
if ($delegates[0] != ""){
$this->openid_url_identity = $delegates[0];
}
$this->SetOpenIDServer($servers[0]);
return $servers[0];
}
function GetRedirectURL(){
$params = array();
$params['openid.return_to'] = urlencode($this->URLs['approved']);
$params['openid.mode'] = 'checkid_setup';
$params['openid.identity'] = urlencode($this->openid_url_identity);
$params['openid.trust_root'] = urlencode($this->URLs['trust_root']);
if (count($this->fields['required']) > 0){
$params['openid.sreg.required'] = implode(',',$this->fields['required']);
}
if (count($this->fields['optional']) > 0){
$params['openid.sreg.optional'] = implode(',',$this->fields['optional']);
}
return $this->URLs['openid_server'] . "?". $this->array2url($params);
}
33
function Redirect(){
$redirect_to = $this->GetRedirectURL();
if (headers_sent()){
echo '<script language="JavaScript" type="text/javascript">window.location=\'';
echo $redirect_to;
echo '\';</script>';
}else{ // Default Header Redirect
header('Location: ' . $redirect_to);
}
}
function ValidateWithServer(){
$params = array(
'openid.assoc_handle' => urlencode($_GET['openid_assoc_handle']),
'openid.signed' => urlencode($_GET['openid_signed']),
'openid.sig' => urlencode($_GET['openid_sig'])
);
// Send only required parameters to confirm validity
$arr_signed = explode(",",str_replace('sreg.','sreg_',$_GET['openid_signed']));
for ($i=0; $i<count($arr_signed); $i++){
$s = str_replace('sreg_','sreg.', $arr_signed[$i]);
$c = $_GET['openid_' . $arr_signed[$i]];
// if ($c != ""){
$params['openid.' . $s] = urlencode($c);
// }
}
$params['openid.mode'] = "check_authentication";
// print "<pre>";
// print_r($_GET);
// print_r($params);
// print "</pre>";
$openid_server = $this->GetOpenIDServer();
if ($openid_server == false){
return false;
}
$response = $this->CURL_Request($openid_server,'GET',$params);
$data = $this->splitResponse($response);
if ($data['is_valid'] == "true") {
return true;
}else{
return false;
}
}
}
?>
34
Недостатки OpenID в системе университета
После тестированая технологии на первый взгляд показалась не совсем
удобной с одной стороны, если говорить о плюсах единый логин и пароль
для любого сайта который поддерживает эту технологию это находка для
пользователя которому надоело вечная авторизация, тем более что в новой
версии протокола на сайт клиента передаётся не только индификационные
данные но и личная информация ФИО, дата рождения и т.д. А с другой если
глядеть с точки безопасности провайдер OpenID может представиться своим
пользователем.
Это
возможно
или
в
случае
недобропорядочности
провайдера, или в случае его взлома.
Пользователь должен доверять провайдеру, так как тот может узнать, какие
сайты посещал владелец OpenID. Хотя, с другой стороны, провайдер обычно
даёт пользователю OpenID возможность проконтролировать, на каких сайтах
был использован его логин, чтобы заметить кражу пароля.
Система OpenID для университета не идеальна, ещё одним минусом является
то, что нет чёткого контроля за пользователями так как в системе где
поддерживается OpenID авторизация может авторизироватся любой выбрав
себе провайдера и пошел гулять по всем сайтом с поддержкой этой
технологии. Зарегистрировавшись на одном из OpenID провайдеров он
получает
доступ
ко
всем
ресурсам
которые
доступны
обычному
пользователю на других сайтах, но студенты у нас не являются простыми
пользователями для них нужно открывать тесты, лабораторные и т.д.
Сейчас система в университете работает так при поступление новых
студентов они вбиваются в базу с присвоение группы которая им
назначается, либо можно вбить их в экселевсикий файлик и импортировать в
базу, и в процессе учёбы для той или иной группы открывается блоки с
заданиями, где предварительно старосте выдаётся список
в котором
напротив каждой фамилии написан логин и пароль для доступа на сайт.
35
В openid ситуация выглядит следующим образом после того как все
авторизировались на портале к примеру imkn.kib.ru предварительно выбрав
себе
провайдера,
преподаватель
должен
переписать
все
логины
(ivanov.opnid.com, petrov.myopenid.com, sidirov.ya.ru (это openid яндекса)) и в
процессе искать этого человека в базе и закреплять за ним определенную
группу в которой он учится, а если кого то из студентов не было в
университете, а тест открыли на неделю а преподаватель уехал в
командировку возникает проблема. Ещё один минус даже больше не
удобство то что если студент выбрал себе провайдера который не
поддерживает передачу доп. данных (ФИО,дата рождения и т.д.)
( это
возможно у тех провайдеров у которых старая версия протокола)
преподавателю придётся самому мало того чтоб подтверждать пользователя
в базе назначать ему группу так ещё и заполнять ФИО, дату рождения так
как в базе клиента от openid провайдера останется только логин
(ivanov.openid.com).
Вывод это технология для университета не особо удобная так как может
возникнуть путаница с логинами и подтверждением пользователей что он
студен, назначение правильной группы и т.д. плюсом в OpenID не встроена
защита от фишинга (для ввода пароля пользователя могут не перенаправить
на страницу провайдера, а показать поддельную страницу, похожую на
страницу провайдера). Однако многие провайдеры и дополнительные
программы (например, расширения для Firefox) предоставляют эту защиту.
36
Windows Live ID
Windows
Live
ID
—
сервис
идентификации
и
аутентификации
предоставляемый системой Windows Live. Используется для единого входа
на всех сетевых сервисах Microsoft, не только Windows Live. Имеет
программную документацию для встраивания в собственные приложения и
веб-сайты. По сути очень похоже на OpenID, только у OpenID провайдеров
мног, а Windows Live ID он один.
В июле 1999 года сайты MSN Network получили систему Microsoft Passport,
единый аккаунт для ряда веб-сервисов.
С развитием система получила название .NET Passport. Появилась
возможность встраивать веб-аутентификацию в собственные веб-сайты. Так
же система получила интеграцию и с программами. Например во встроенном
в Windows XP клиенте мгновенных сообщений Windows Messenger
используется .NET Passport. С введением Windows Live закрепилось название
Windows Live ID. Иногда систему называют Passport Network.
37
SAML
Язык SAML (Security Assertion Markup Language) сможет обеспечить
стандартный способ обмена аутентификационными и авторизационными
данными между приложениями разных производителей. Стандарт SAML
версии 1.1 — это XML-структура, разработанная организацией OASIS
(Organization for the Advancement of Structured Information Standards). В
версии 1.1 спецификации Liberty Alliance этот стандарт используется для
поддержки единой Web-регистрации, а также служб аутентификации в
соответствии со спецификацией Web Services Security. Web-службы
открывают перспективу для стандарта SAML, и в ближайшем будущем такие
продукты, как Nsure компании Novell и eTrust Admin компании Computer
Associates, будут поддерживать SAML. Между тем ведущие производители
ПО, включая компании CrossLogix, Tivoli Systems (в составе IBM), Netegrity,
Novell, Oblix, RSA Security и Sun Microsystems, уже предлагают поддержку
SAML в своих решениях безопасности, как и новая платформа .Net Server
компании Microsoft.
Стандарт SAML поддерживает пароли, мандаты Kerberos, защищенные
удаленные пароли, жетоны, открытые ключи (сертификаты X.509, SPKI,
XKMS, SSL/TLS) и цифровые подписи XML.
Протоколы SAML определяют формат запросов и ответов. Обмен данными
SAML предполагает наличие доверительных отношений между инициатором
запроса и отвечающей стороной. Обе стороны должны ссылаться на один и
тот же объект, например, существует только один объект с именем “Bruce” в
домене безопасности “nwcinc.com”.
В соответствии со стандартом SAML каждый запрос и каждый ответ имеют
общие заголовки, определяемые в SAML-документах пространством имен
samlp. Все утверждения SAML начинаются с префикса, задающего
38
пространство имен saml, и каждый из трех видов утверждений имеет
соответствующий протокол запроса.
Помимо базовых протоколов, стандарт SAML также определяет параметры
(артефакты) перенаправления браузера и единой регистрации. Артефакт
ссылается на утверждение SAML, позволяя приложению или Web-серверу
получить его.
39
Настройка межсайтовой авторизации между битриксом и
удалёнными сайтами.
Разработаем страницу с системе битрикс и назовём её auth_bix.php эта
страница будет проверять с какого сайта пришел пользователь, и если он ещё
не авторизирован на сайте то перенаправляем его на страницу авторизации, а
если авторизирован то проверяем жива ли сессия и есть ли связка ID
пользователя и то перенаправляем его на сайт с которго он пришол и
подымаем там сессию.
В основу защиты я взял потокол Диффи-Хелмана который используется в
технологии OpenID. Этот протокол позволяют двум сторонам сгенерировать
общий ключ К, не передавая его по незащищённому каналу связи.
Как это выглядит на практике. Когда пользователь заходит на сайт
происходит
редирект
на
сайт
битрикса,
где
с
этим
редиректом
перенаправляются 3 сгенерированных переменных в процессе на сайте
битрикса проверяется авторизирован ли пользователь (т.е. живы ли сессии и
cookie) и если да то на странице битрикса вычисляется переменная и
происходит редирект назад на страницу с которой пришел пользователь если
есть связь в базе ID пользователя и сессии и совпадает ключ, то подымаем
сессию и перенаправляем на пользовательскую страницу.
Схема генерации ключа по протоколу Дифи-Хелмана
40
auth_bix.php – странница на которую пересылаются пользователи с других
сайтов , для авторизации в битриксе
index.php – главная странница сайта, с которой пользователи пересылаются
на auth_bix.php для авторизации либо, подтвердив что автризациия уже
выполнена и перенаправить назад уже авторизированным
config.php – содержит конфигурационные данные
function.php – страница с функциями к которым обращается index.php
logout.php – при переходе на эту странницу происходит закрытие сессии и
уничтожение сессионных переменных
members.php – страница на которую пересылается в случае успешной
авторизации на сайте
Структура файла auth_bix.php в битриксе
<?
require($_SERVER['DOCUMENT_ROOT']."/bitrix/header.php");
global $USER;
if(eregi("test1.ru",$_SERVER['HTTP_REFERER'])){
$lock = "true";
$site_k = "http://test1.ru/"; }
elseif(eregi("test2.ru",$_SERVER['HTTP_REFERER'])){
$lock = "true";
$site_k = "http://test.ru/";
}
else $lock = "false";
}
if ($lock == "true") {
if ($_GET['auth'] == "qwerty") {
if ($_GET['close'] == "1") {$USER->Logout();};
if ($USER->IsAuthorized()) {
$login = $USER->GetParam("LOGIN");
$password = $USER->GetParam("PASSWORD_HASH");
header("Location: ".$site_k."index.php?auth=open&login=".$login."&pass=".$password);
41
}
else {
header("Location: ".$site_k."index.php?auth=1");
}
}
else {
if (isset($_GET['login'])) {
if (isset($_GET['pass'])) {
$login = trim($_GET['login']); $password = trim($_GET['pass']);
global $USER;
if (!is_object($USER)) $USER = new CUser;
$arAuthResult = $USER->Login($login, $password, "Y", "Y");
$APPLICATION->arAuthResult = $arAuthResult;
header("Location: ".$site_k."");
}
}
};
};
require($_SERVER['DOCUMENT_ROOT']."/bitrix/footer.php");
?>
Структура файла config.php
<?php
include_once("functions.php");
session_register("login");
session_register("password");
session_register("loggedIn");
$messages=array();
$dbhost="localhost";
$dbuser="root";
$dbpass="";
$dbname="imkn_b";
$site = "http://sait_bitrix.ru/auth_bix.php";
connectToDB();
?>
Структура файла function.php
<?php
function connectToDB() {
42
global $link, $dbhost, $dbuser, $dbpass, $dbname;
($link = mysql_pconnect("$dbhost", "$dbuser", "$dbpass")) || die("Couldn't connect to MySQL");
mysql_select_db("$dbname", $link) || die("Couldn't open db: $dbname. Error if any was: ".mysql_error() );
}
function displayErrors($messages) {
print("<b><small> Вы не можете войти в систему. Возможна одна из следующих
причин:</small></b>\n<ul>\n");
foreach($messages as $msg){
print("<li><small>$msg</small></li>\n");
}
print("</ul>\n");
}
function checkLoggedIn($status){
switch($status){
case "yes":
if(!$_SESSION["loggedIn"]){
header("Location: index.php");
exit;
}
break;
case "no":
if($_SESSION["loggedIn"]){
header("Location: members.php?".session_name()."=".session_id());
}
break;
}
return true;
}
function bitrix_pass($pass_baza,$password) {
global $link,$messages;
$salt = substr($pass_baza, 0, (strlen($pass_baza) - 32));
$realPassword = substr($pass_baza, -32);
$password = md5($salt.$password);
if ($password == $realPassword) return true;
}
function checkPass($login, $password, $auth) {
43
global $link,$messages;
$query="SELECT * FROM b_user WHERE login='$login'";
$result=mysql_query($query, $link) or die("checkPass fatal error: ".mysql_error());
if(mysql_num_rows($result)==1) {
$userData=mysql_fetch_array($result);
if ($auth == "open") {
if ($userData['PASSWORD'] == $password) return $userData;
}
elseif ($auth == "1") {
if(bitrix_pass($userData['PASSWORD'],$password)) return $userData;
};
}
else return false;
}
function cleanMemberSession($login, $password) {
global $link,$sid,$site;
$_SESSION["login"]=$login;
$_SESSION["password"]=$password;
$_SESSION["loggedIn"]=true;
header("Location: ".$site."?login=".$_SESSION["login"]."&pass=".$_SESSION["password"]."&id=$sid");
/*
header("Location: http://imkn.ru/test1.php?login=".$login."&pass=".$password."");
}
function cleanMemberSession2 ($login) {
global $link;
$_SESSION["login"]=$login;
$_SESSION["loggedIn"]=true;
}
function flushMemberSession() {
global $link;
unset($_SESSION["login"]);
unset($_SESSION["password"]);
unset($_SESSION["loggedIn"]);
session_destroy();
return true;
}
44
*/
?>
Структура файла index.php
<?php
include_once("config.php");
checkLoggedIn("no");
global $sid,$site;
if ($_GET['auth'] == "open") {
if( !($userData = checkPass($_GET["login"], $_GET["pass"],$_GET["auth"])) ) {
$messages[]="Mejsaitovaa avtorizacia ne proshla";
}
if($messages){
doIndex();
exit;
}
cleanMemberSession2 ($_GET["login"]);
sleep(1);
header("Location: members.php?".session_name()."=".session_id());
}
elseif (!isset($_GET['auth'])) {
header("Location: ".$site."?auth=qwerty&id=$sid");
};
if($_GET["submit"]) {
field_validator("логин", $_GET["login"], "alphanumeric_space", "1","50");
field_validator("пароль", $_GET["password"], "alphanumeric_space"," 1", "50");
if($messages){
doIndex();
exit;
}
if( !($userData = checkPass($_GET["login"], $_GET["password"],1)) ) {
$messages[]="Вы ввели неверный логин/пароль, попробуйте снова";
}
if($messages){
doIndex();
exit;
}
cleanMemberSession($_GET["login"], $_GET["password"]);
} else {
doIndex();
45
}
function doIndex() {
global $messages;
global $title;
?>
<html>
<head>
<?php meta()?>
<meta content="text/html; charset=Windows-1251" http-equiv="content-type">
<title>test ::.</title>
<?php doCSS()?>
</head>
<body onLoad = document.go.login.focus(); >
<table border="0">
<tr >
<td width="347" valign="top" >
<h2 >Тестовая страница ::.</h2>
<h3 >Авторизация</h3>
<?php
if($messages) { displayErrors($messages); }
?>
<form name="go" action="<?=$_SERVER["PHP_SELF"]?>" method="GET">
<table width="224" height="107" border="0">
<tr>
<td width="81" height="31" class="wpmd">Логин:</td>
<td width="133"><input type="text" title="логин" name="login" onKeyUp="changeButtonStatus()"
onChange="changeButtonStatus()" size="30" value="<?php print $_POST["login"] ?>" ></td>
</tr>
<tr>
<td height="29" class="wpmd">Пароль:</td>
<td><input type="password" title="пароль" name="password" onKeyUp="changeButtonStatus()"
onChange="changeButtonStatus()" size="30" ></td>
</tr>
<tr>
<td> </td>
<td><input name="submit" title="Войти в систему" type="submit" value="Войти"></td>
</tr>
</table>
</form>
<script language="JavaScript">
<!-var f=document.go;
function changeButtonStatus(){
f.submit.disabled=(f.login.value && f.password.value) ? false : true;
}
changeButtonStatus();
//-->
</script>
46
</td>
<td width="551" valign="top"> </td>
</tr>
</table>
</body>
</html>
<?php
}
?>
Структура файла logout.php
<?php
include_once("config.php");
global $sid,$site;
checkLoggedIn("yes");
flushMemberSession();
header("Location: ".$site."?auth=qwerty&close=1&id=$sid")
?>
Структура файла members.php
<?php
include_once("config.php");
checkLoggedIn("yes");
$query="SELECT * FROM b_user WHERE login='".$_SESSION["login"]."'";
$result=mysql_query($query, $link) or die("checkPass fatal error: ".mysql_error());
$myrow = mysql_fetch_array($result);
?>
<head>
<?php meta()?>
<meta content="text/html; charset=Windows-1251" http-equiv="content-type">
<title>test</title>
<?php doCSS()?>
</head>
<body>
<?php welcome($myrow['NAME']); ?>
<?php
print("<table border='0' ><tr ><td height='30'>");
47
print("<td><img src='ris/exit.gif' width='16' height='16'><a
href='logout.php?".session_name()."=".session_id()."' class='style1'><b> Выход</b></a></td>") ;
print("</tr></table>");
?>
</body>
</html>
48
Безопасность при межсайтовом взаимодействии
Суть протокола
Diffie-Hellman в генерации общего ключа К двумя
сторонами: А и Б. Но если у нас есть кто-то «посередине» т.е. находится ещё
один сервер (М), кто может изменять трафик, то может оказаться так, что А
сгенерировал общий с М ключ К1, а Б — общий с М ключ К2. В итоге Вы
(А) устанавливаете абсолютно защищённое соединение с М, думая, что
установили соединение с Б. После этого М устанавливает безопасное
соединение с Б и начинает передавать ему ваши запросы, а вам — его ответы.
Таким образом, М может прослушивать взаимодействие А — Б и даже
модифицировать
Разумеется,
передаваемые
подобная
атака
не
пройдёт,
сообщения.
если
клиент
и
сервер
взаимодействуют по HTTPS с полноценной проверкой сертификата.
Протокол SSL защищён от модификации и чтения сообщений, отправляемых
в обе стороны. Также протокол позволяет клиенту убедиться в том, что он
установил соединение именно с нужным сервером, а не с сервером
мошенника.
Многие разработчики не понимают сути секретного ключа. Вся безопасность
в инфраструктуре с использованием открытого ключа построена на том, что
взаимодействующие стороны кому-то могут безоговорочно доверять.
Второму серверу, третьей стороне — не важно. Как правило, вопрос
«доверия» упирается в проверку цифровой подписи с использованием
открытого ключа подписчика сообщения. Вся безопасность может рухнуть,
если этот открытый ключ (сертификат) передаётся по незащищённому
каналу и может быть по пути модифицирован.
Подчеркну ещё раз, что от этой атаки можно защититься,
устанавливающий
HTTPS-соединение
49
сервер
обладает
если
достаточным
количеством сертификатов основных CA Интернета (VeriSign, COMODO и т.
д.), но на практике это иногда сложно реализуемо.
50
Список литературы
1.
1С-Битрикс - CMS, ECM, управление сайтами
(http://www.1c-bitrix.ru/)
2.
PHP: Hypertext Preprocessor
(http://www.php.net/)
3.
OpenID Foundation website
(http://www.openid.net/)
4.
Институт математики и компьютерных наук
(http://www.imkn.kib.ru/)
5.
Арсений Чеботарёв, "Комиздат" «LDAP: каталог для всех».
(http://www.citforum.ru/operating_systems/linux/ldap_cat/)
6.
MySQL - справочное руководство
(http://opennet.ru/)
7.
isOpenID.ru - российский OpenID провайдер
(http://www.isopenid.ru/)
8.
Энциклопедия сайтостроения – CMS, OpenID (универсальность авторизации)
(http://www.site.nic.ru/)
9.
Всё о SSL технологиях
(http://www.inssl.com/)
10.
The OpenID Directory
(http://www.openiddirectory.com/)
11.
Битрикс – Центр поддержки разработчиков
(http://dev.1c-bitrix.ru/)
12.
Документация по MySQL.Ru
(http://www.mysql.ru/docs/)
13.
Битрикс – Центр поддержки разработчиков
(http://dev.1c-bitrix.ru/)
14.
Сети и системы связи
(http://www.ccc.ru/)
15.
PHP.Ru форум php программистов
(http://www.php.ru/)
16.
Криптография и шифромание
(http://cryptolog.ru/)
51
17.
kiev-security.org.ua-Криптография.Обмен ключами по алгоритму Диффи-Хеллмана
(http://kiev-security.org.ua/box/1/76.shtml)
18.
openPGP в России / Библиотека / Статьи
(http://www.pgpru.com/biblioteka/statji/)
19.
SSL Certificate Information Center - SSL Certificates and SSL from VeriSign, Inc
(http://www.verisign.com/ssl/ssl-information-center/)
20.
SSL-СЕРТИФИКАТЫ
(http://ssl.ru/ru/)
21.
Solid State Logic
(http://www.solid-state-logic.com/)
22.
Window Server 2003
(http://www.microsoft.com/windowsserver2003/default.mspx)
23.
Windows Live ID
(http://login.live.com//)
24.
The Times Literary Supplement
(http://tls.timesonline.co.uk/)
25.
OASIS Security Services (SAML) TC
(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security)
26.
SAML Single Sign-On (SSO)
(http://code.google.com/intl/ru/apis/apps/sso/saml_reference_implementation.html)
27.
Debunking SAML myths and misunderstandings
(http://www.ibm.com/developerworks/xml/library/x-samlmyth.html)
28.
Switch on SAML for PHP With Project Lightbulb
(http://developers.sun.com/identity/reference/techart/lightbulb.html)
29.
Twitter API Wiki / OAuth FAQ
(http://apiwiki.twitter.com/OAuth-FAQ)
30.
PECL :: Package :: oauth
(http://pecl.php.net/package/oauth)
52