Реферат: Настройка многосайтовой конфигурации в 1С-битрикс

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Институт математики и компьютерных наук

Кафедра информационной безопасности


Допустить к защите в ГАК
Заведующий кафедрой
информационной безопасности,
д.т.н., профессор А.А. Захаров

“____” _________ 2010 г.


Голышева Вячеслава Валерьевича

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

единого входа (Single Sign On)»

(выпускная квалификационная работа)


Научный руководитель:

старший преподаватель

__________Нестерова О.А.

Автор работы:

__________ Голышев В.В.


Тюмень 2010

Оглавление

Введение 3

Технологии 5

1С - Битрикс 5

Технология переноса посетителей между сайтами 7

Модуль AD/LDAP 9

Схема работы модуля 12

Настройка многосайтовой конфигурации в 1С-битрикс. 13

OpenID 21

Кто контролирует OpenID? 22

Терминология OpenID 23

Simple Registration Extension 23

Применение технологии OpenID 25

Протокол Диффи-Хеллмана 26

Описание алгоритма 26

Недостатки OpenID в системе университета 34

Windows Live ID 36

SAML 37

Настройка межсайтовой авторизации между битриксом и удалёнными сайтами. 39

Безопасность при межсайтовом взаимодействии 48

Список литературы 50



Введение
В настоящее время простые Интернет сайты отходят на второй план, и все большую популярность получают, так называемые, Интернет порталы. Интенсивному развитию порталов способствует ряд программных продуктов, позволяющих объединить в единое пространство информацию из различных источников (Например: форум, фотогалерея, библиотека, wiki, почта, новости и т.д.).

Каждый тип Интернет ресурса имеет собственный движок для работы с персональной информацией пользователя (phpBB для форума, Gallery для фотогалереи и т.д.).

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

Регистрация пользователей давно стала рутинной операцией для многих и многих интернет-сервисов, будь то форумы, блоги или новостные сайты. Зарегистрированные пользователи получают доступ к дополнительным функциям сервиса. По мере его учёбы студент получает доступ на все эти порталы в системе универсистета. И для каждого нужен свой пароль и пользователь. Минусы таких порталов в том, что происходят хранения/запоминания множества связок «логин/пароль». Зачастую в учебных заведениях данные для авторизации выдаются на кафедре и ладно если тебе выдали логин ivanov_123 так могут же ещё добавить сюда имя через нижнее подчеркивание и написать ещё это всё в разных регистрах такая картина не особо радует. Образуется своего рода «заповедник» с множеством логинов и паролей для каждого сайта — и это далеко не всегда удобно, так как пароли имею свойства забывается и теряться.

Исходя из этого, целью работы является разработать техногологию межсайтовой авторизации в сети интернет для портала ИМКН .

Для реализации технологии единого входа поставим перед собой следующие задачи:

Проанализировать существующие технологии единого входа (межсайтовой авторизации)

Настройка межсайтовой авторизации портала ИМКН

Тестирование настроек сайта или вопрос безопасности.



^ Технологии 1С - Битрикс


Идея технологии межсайтовой авторизации в том, что пользователь авторизировавшись на одном портале переходит из одного портала в другой без повторной авторизации.

Под сайтом понимается совокупность следующих понятий:

Учетная запись в общей базе данных;

Публичная часть сайта (файлы и папки);

Настройки сайта.

Другими словами, сайт – это созданная в системе сущность, обладающая определенным набором данных (контента) и параметров (язык, шаблон дизайна, форматы даты и времени). Данные могут быть уникальными в рамках этого сайта (публичная часть, индивидуальные инфоблоки, веб-формы, опросы, форумы и т.п.) или разделяемыми между несколькими сайтами.

Один из сайтов который находится в наличии у ИМКН это сатй imkn.kib.ru на котором установлена платформа 1С - Битрикс.

Программные продукты «1С-Битрикс» - профессиональные системы для управления веб-проектами и создания корпоративных порталов.

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

Для хранения данных сайта используется реляционная СУБД. Поддерживаются следующие СУБД: MySQL, Oracle, MS SQL. Продукт работает на Microsoft Windows и UNIX‐подобных платформах, включая GNU/Linux.

Идеология системы представляет собой разделение логики на модули и компоненты. Модули в «1С-Битрикс» — это набор программных компонентов, отвечающих за работу с различными типами баз данных, а также предоставляющих унифицированный API системы. Компоненты служат для связи конечного представления информации на сайте с программным ядром системы. Они используют API, созданный модулями, для организации выборки, модификации, управления информацией в базе данных.

Критерии по которым он был выбран для реализации межсайтовой авторизации:

- во-первых : в нём есть система управления контентом через которую можно добавлять, изменять новости структуру сайта и.т.д.;

- во-вторых : в нем имется встроенный модуль AD/LDAP который синхронизирует данные из Active Directory которые находятся на серверной станции и с базой битрикса.

- в-третих : это преимущества для разработчиков одной из которых является механизм информационных блоков (инфоблоков). Он позволяет легко создавать пользовательские типы содержания. Другой особенностью современных версий Битрикса является мощный визуальный HTML-редактор, позволяющий размещать на странице как обычную HTML информацию, так и различные динамические компоненты, работу которых обеспечивает CMS.


Технология переноса посетителей между сайтами


Особенностями многосайтовой системы являются:

единые права на все сайты

единый набор функций пользователей на все сайты

единая система ведения статистики на все сайты

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

Распознавание посетителей осуществляется с помощью файлов cookie (куков), представляющих из себя информацию, передаваемую между веб-сервером и браузером и хранимую только на локальном диске посетителя.

При первом заходе посетителя на сайт A ему выдаются ряд идентификаторов, используемых разными модулями (например, идентификатор посетителя или идентификатор покупателя в модуле интернет-магазина и т.д.), которые запоминаются в хранимых cookie принадлежащих сайту A.

Когда посетитель в следующий раз возвращается на этот же сайт A, он будет "узнан" благодаря информации хранимой в cookie, принадлежащих сайту A.

Теперь представим, что этот же посетитель пришел на сайт B. Возникает задача "узнать" его как посетителя в недавнем прошлом сайта A. Под термином "узнать" здесь понимается - получить идентификаторы, выданные ему на сайте A. Проблема осложняется тем, что если доменное имя сайта B отличается от доменного имени сайта A, то информация хранимая в cookie принадлежащих сайту A не может быть получена при заходе посетителя на сайт B. Также есть обратная проблема - 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, то этот идентификатор будет также сохранен и для других сайтов A, C, D. Таким образом мы добиваемся единого набора cookie для всех сайтов одного портала.

Использование данной технологии позволяет:

В модуле "Статистика" подсчитывать уникальных посетителей для всего портала.

В модуле "Реклама, баннеры" позволяет корректно учитывать количество показов одного баннера одному посетителю. Другие модули также активно используют эту методику. Указанная технология будет использоваться для сайтов многосайтовой конфигурациии, если активирована опция: Распространять куки на все домены в настройках главного модуля.
^


Модуль AD/LDAP


Модуль AD/LDAP интеграция реализован с учетом особенностей работы LDAP (Lightweight Directory Access Protocol) и AD (Active Directory) протоколов, один из которых должен быть установлен на корпоративном сервере.

В основе работы перечисленных протоколов лежит принцип хранения информации в виде записей, обладающих набором атрибутов и хранящихся в базе данных с древовидной иерархической структурой. Таким образом, при настройке на сервере локальной вычислительной сети LDAP или AD протокола информация о группах пользователей будет представляться в следующем виде (Error: Reference source not found):



^ Структура записей

Используя данную структуру хранения данных, модуль AD/LDAP интеграция позволяет настраивать соответствие групп пользователей корпоративной сети группам пользователей сайта.

Соответствие групп пользователей задается в специальной ^ Таблице соответствий в административном разделе сайта. При этом возможно несовпадение имен групп пользователей сайта с именами групп пользователей корпоративной сети. Например, группе пользователей корпоративной сети Techsupport, к которой относятся сотрудники технической поддержки корпоративной сети, может быть поставлена в соответствие группа пользователей Techsupport stuff, созданная на сайте. Теперь сотрудники службы технической поддержки корпоративной сети смогут выполнять обязанности сотрудников службы технической поддержки сайта.

Группы пользователей внутри компании обладают правами на доступ к определенным ресурсам корпоративной сети, а сопоставленные им группы пользователей на сайте обладают правами на доступ к ресурсам сайта. Например, группа пользователей Techsupport наделена правами на доступ к почтовому серверу сети, а группа пользователей сайта Techsupport stuff обладает правами на доступ к модулю Техподдержка.

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

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

Таким образом, модуль ^ AD/LDAP интеграция позволяет:

интегрировать систему "1С-Битрикс: Управление сайтом" в корпоративную сеть;

настроить соответствие групп пользователей корпоративной сети и групп пользователей сайта;

автоматически создавать бюджет пользователя после его регистрации исходя из Таблицы соответствий (данные для создания бюджета пользователя запрашиваются из базы данных корпоративного сервера);

централизованно управлять изменениями бюджетов пользователей системы через корпоративный сервер.

Модуль ^ AD/LDAP интеграция так же позволяет использовать NTML авторизацию. Чтобы ею воспользоваться, нужен веб-сервер IIS или Apache с модулем mod_ntlm или mod_auth_sspi.


^ Схема работы модуля
Общая схема работы модуля может быть описана следующей последовательностью действий:

Пользователь заходит на сайт и авторизуется (вводит логин и пароль, используемый для авторизации в корпоративной сети);

Система обращается к указанному в настройках AD/LDAP серверу и проверяет наличие пользователя с указанными данными (паролем и логином) в базе пользователей на корпоративном сервере:

если пользователя с такими данными в корпоративной сети не существует, то система запрещает вход на сайт;

если пользователь существует, то определяется группа пользователей корпоративной сети, к которой он относится, и сопоставленная ей группа пользователей сайта (с помощью Таблицы соответствий).

Далее проверяется наличие бюджета данного пользователя в системе:

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

Если бюджет пользователя в системе уже был создан, т. е. пользователь уже авторизовался на сайте, то система проверяет, были ли произведены какие-либо изменения с бюджетом пользователя на корпоративном сервере. Если да, то соответствующие изменения производятся и с бюджетом пользователя в системе управления сайтом.

Пользователь получает разрешение на доступ к ресурсам сайта и авторизуется. Права пользователя определяются в зависимости от настроек группы пользователей сайта, к которой он был приписан.
^ Настройка многосайтовой конфигурации в 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:



ServerAdmin admin@site1.com

DocumentRoot "/home/www/site1/"

ServerName site1.com

ServerAlias *.site1.com

ErrorLog logs/site1.log

CustomLog logs/site1.log common




для site2:



ServerAdmin admin@site2.com

DocumentRoot "/home/www/site2/"

ServerName site2.com

ServerAlias *.site2.com

ErrorLog logs/site2.log

CustomLog logs/site2.log common




Обратите внимание, что параметр DocumentRoot для каждого сайта указывает в разный каталог на диске, в котором должен быть размещен соответствующий сайт.

Строки указывают на то, что веб-сервер будет отвечать на любом IP адресе, но переменная ServerAlias говорит о том, что каждый из сайтов будет отвечать только по определенному доменному имени.

Т.е. доменное имя www.site1.com будет обрабатываться одним веб-сервером Apache, который работает с каталогом /home/www/site1/, а www.site2.com - другим вебсервером, работающим с каталогом /home/www/site2/.

Возможен так же вариант конфигурирования для разных IP адресов. Ниже приведен пример конфигурации Apache для двух разных IP адресов:



ServerAdmin admin@site1.com

DocumentRoot "/home/www/site1/"

ServerName site1.com

ErrorLog logs/site1.log

CustomLog logs/site1.log common

Options +FollowSymLinks






ServerAdmin admin@site2.com

DocumentRoot "/home/www/site2/"

ServerName site2.com

ErrorLog logs/site2.log

CustomLog logs/site2.log common

Options +FollowSymLinks




В этом случае при соответствующей настройке 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/

· 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 и выполняем те же команды.

Следующий шаг в настройке данной конфигурации - правильное конфигурирование сайтов в программном продукте.

Настройка сайтов выполняется в административном разделе системы в

административном пункте меню "Настройки системы" - "Сайты".

Выбираем "Изменить" параметры сайта #1 (www.site1.com) и указываем в них:

· Название: site1

· Доменное имя: www.site1.com

· Папка сайта: /

· Название сайта: Корпоративный сайт компании "Название компании"

· URL сервера: www.site1.com

· Путь к корневой папке веб-сервера для этого сайта: /home/www/site1/

Если DNS настроен таким образом что ваш сайт отвечает на адрес http://site1.com, то в поле Доменное имя желательно указывать без www. Можно перечислить в этом поле с новой строки любое число доменных имен, по которым вы хотите, чтобы отвечал сайт (или уже отвечает).

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

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

Аналогично настроим параметры сайта #2 (www.site2.com):

· Название: site2

· Доменное имя: site2.com

· Папка сайта: /

· Название сайта: Интернет-магазин компании "Название компании"

· URL сервера: www.site2.com

· Путь к корневой папке веб-сервера для этого сайта: /home/www/site2/

Обратите внимание, что для двух сайтов в параметре "Папка сайта" указано одинаковое значение - "/". Это связано с тем, что сайты обслуживаются разными "виртуальными серверами" (в терминологии Apache) у которых для размещения файлов использован разный каталог.

Также необходимо обратить на параметр "Путь к корневой папке веб-сервера для этого сайта". Для разных сайтов у него свое значение, взятое из параметра DocumentRoot настроек соответствующего "виртуального сервера" (см. выше пример части файла httpd.cnf настроек Apache).

Необходимо иметь в виду, что при организации многосайтовости по данному способу, вы можете использовать как виртуальные сервера одной инсталляции Apache, так и просто разные инсталляции Apache. Аналогично и для других веб-серверов: IIS, EServ и т.д.

Конфигурация готова к работе.

^ Настройка сайта

В момент добавления записи о новом сайте в таблицу сайтов необходимо указать следующие параметры:

· идентификатор сайта – двухсимвольная комбинация, например: ru, en, de, s1, s2 и т.п.

· название – произвольное название сайта, наряду с идентификатором сайта используется в различных административных формах для указания привязки к тому или иному сайту.

· доменное имя – указываются доменные имена, которые соответствуют данному сайту.

Теперь о минусах этого варианта многосайтовости.

Чтобы настроить этот проект многосайтовости нужно чтобы ядро системы битрикс для всех сайтов было едино как и база. Следовательно, нужно чтобы все порталы находились на одном сервере, что можно было ядро для порталов объединить в символической связью .Ещё один критерий версия Windows NT не должна быть ниже Windows NT 5 и файловая система должна быть NTFS.

Такой вариант тоже не подходит так как все порталы у университета находятся на разных виртуальных машинах. И переносить всё на одну не особо рационально.













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 используют свои аккаунты для доступа к более чем десяти тысячам сайтов.
^ Кто контролирует OpenID?
OpenID возник из сообщества открытых исходных кодов для решения проблем, которые не могут быть легко решены другими существующими технологиями. OpenID - это легкий метод авторизации на огромном количестве веб сайтов. Таким образом, OpenID не принадлежит никому. Сегодня каждый может быть в качестве OpenID пользователя или OpenID провайдера бесплатно и без регистрации.

В поддержку OpenID создан фонд (http://openid.net/foundation) – для решения всевозможных юридических вопросов, а так же поддержки разработчиков, создания инфраструктуры с целью расширения и продвижения OpenID.

Как сказал Брэд Фитцпатрик (автор OpenID): "Ни кто не должен планировать заработать деньги на этом. Наша цель – предоставить все возможности для использования этой технологии по наиболее либеральной лицензии. Этот принцип принесет пользу всем нам и всему обществу в целом.".

Это заявление продолжает звучать и сегодня в рамках OpenID сообщества.


^




Терминология OpenID

* Конечный Пользователь — лицо, которое хочет идентифицировать себя
* Идентификатор — URI или XRI, выбранный пользователем в качестве OpenID-идентификатора
* Провайдер Идентификации — лицо, предоставляющее сервис регистрации и аутентификации Идентификаторов
* Пользователь Аутентификации — лицо, желающее проверить подлинность Идентификатора Конечного Пользователя
* Сервер Аутентификации — сервер, проверяющий подлинность Идентификатора Конечного Пользователя (сервер Провайдера Аутентификации в большинстве случаев)
* Агент Пользователя — программа (браузер в большинстве случаев), используемая клиентом, для доступа к Провайдеру или Пользователю Аутентификации
^


Simple Registration Extension

Первоначально OpenID создавался исключительно для аутентификации пользователя, но после непродолжительной эксплуатации появилась острая потребность в предоставлении дополнительной информации о конечном пользователе. Для решения этой проблемы было разработано расширение протокола — Simple Registation Extension. Провайдеры аутентификации, которые поддерживают это расширение, могут хранить информацию о т. н. «персонах».
«Персона» — запись, содержащая Ваше имя, адрес электронной почты и другие данные, которые обычно требуются для регистрации на сайтах. Любая персона может быть выбрана, как «публичная» — её содержимое сможет посмотреть каждый даже без согласия персоны на это.




(Рис. № 1) Схема работы OpenID

На рис. №1 изображён порядок работы OpenID-аутентификации. Слева - OpenID-провайдеры ,а справа - другие сайты, поддерживающие OpenID-регистрацию. Мы будем считать, что в центре - это профиль пользователя. Справа - сайты, на которые он хочет залогиниться, указав в качестве OpenID-аккаунта ссылку на свой профиль. А слева - его, пользователя, OpenID-провайдеры, которых, к слову, он может и не иметь вовсе, иметь всего один (на схеме изображен черным цветом), или иметь несколько (на схеме дополнительные связи к другим OpenID-провайдерам указаны серым цветом).








OpenID Login

" method="post" onSubmit="this.login.disabled=true;">











^ Недостатки OpenID в системе университета


После тестированая технологии на первый взгляд показалась не совсем удобной с одной стороны, если говорить о плюсах единый логин и пароль для любого сайта который поддерживает эту технологию это находка для пользователя которому надоело вечная авторизация, тем более что в новой версии протокола на сайт клиента передаётся не только индификационные данные но и личная информация ФИО, дата рождения и т.д. А с другой если глядеть с точки безопасности провайдер OpenID может представиться своим пользователем. Это возможно или в случае недобропорядочности провайдера, или в случае его взлома.

Пользователь должен доверять провайдеру, так как тот может узнать, какие сайты посещал владелец OpenID. Хотя, с другой стороны, провайдер обычно даёт пользователю OpenID возможность проконтролировать, на каких сайтах был использован его логин, чтобы заметить кражу пароля.

Система OpenID для университета не идеальна, ещё одним минусом является то, что нет чёткого контроля за пользователями так как в системе где поддерживается OpenID авторизация может авторизироватся любой выбрав себе провайдера и пошел гулять по всем сайтом с поддержкой этой технологии. Зарегистрировавшись на одном из OpenID провайдеров он получает доступ ко всем ресурсам которые доступны обычному пользователю на других сайтах, но студенты у нас не являются простыми пользователями для них нужно открывать тесты, лабораторные и т.д.

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

В openid ситуация выглядит следующим образом после того как все авторизировались на портале к примеру imkn.kib.ru предварительно выбрав себе провайдера, преподаватель должен переписать все логины (ivanov.opnid.com, petrov.myopenid.com, sidirov.ya.ru (это openid яндекса)) и в процессе искать этого человека в базе и закреплять за ним определенную группу в которой он учится, а если кого то из студентов не было в университете, а тест открыли на неделю а преподаватель уехал в командировку возникает проблема. Ещё один минус даже больше не удобство то что если студент выбрал себе провайдера который не поддерживает передачу доп. данных (ФИО,дата рождения и т.д.) ( это возможно у тех провайдеров у которых старая версия протокола) преподавателю придётся самому мало того чтоб подтверждать пользователя в базе назначать ему группу так ещё и заполнять ФИО, дату рождения так как в базе клиента от openid провайдера останется только логин (ivanov.openid.com).

Вывод это технология для университета не особо удобная так как может возникнуть путаница с логинами и подтверждением пользователей что он студен, назначение правильной группы и т.д. плюсом в OpenID не встроена защита от фишинга (для ввода пароля пользователя могут не перенаправить на страницу провайдера, а показать поддельную страницу, похожую на страницу провайдера). Однако многие провайдеры и дополнительные программы (например, расширения для Firefox) предоставляют эту защиту.


^


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.



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 начинаются с префикса, задающего пространство имен saml, и каждый из трех видов утверждений имеет соответствующий протокол запроса.

Помимо базовых протоколов, стандарт SAML также определяет параметры (артефакты) перенаправления браузера и единой регистрации. Артефакт ссылается на утверждение SAML, позволяя приложению или Web-серверу получить его.











^ Тестовая страница ::.

Авторизация

<?php

if($messages) { displayErrors($messages); }

?>

" method="GET">





Логин:

" >





Пароль: