Разработка системы межсайтовой авторизации или технологии единого входа (Single Sign On)

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

 

 

 

 

 

 

 

 

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

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

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

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

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

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

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

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

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

Настройка многосайтовой  конфигурации в 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

    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>

 

<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/ 

·  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-идентификатора 
* Провайдер Идентификации — лицо, предоставляющее сервис регистрации и аутентификации Идентификаторов 
* Пользователь Аутентификации — лицо, желающее проверить подлинность Идентификатора Конечного Пользователя 
* Сервер Аутентификации — сервер, проверяющий подлинность Идентификатора Конечного Пользователя (сервер Провайдера Аутентификации в большинстве случаев) 
* Агент Пользователя — программа (браузер в большинстве случаев), используемая клиентом, для доступа к Провайдеру или Пользователю Аутентификации