Публикации сотрудников

Интервью с Романом Шеломановым – руководителем направления программных продуктов компании Девпарк.

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

Сегодня собственник занят развитием бизнеса, он все время “в теме” – думает, как бы привлечь клиента, увеличить доход, у него не остается времени для такого занятия  как автоматизация, внедрение современных компьютерных технологий  и прочих непрофильных умных слов.  Но, увы, сейчас без компьютера и хорошей программы в нем будет сложно держать в голове клиентскую базу данных и график платежей. Кто-то должен придумать эту хорошую программу, установить ее пользователю, поддерживать, резервировать данные, складывать бекапы базы данных в несгорающий сейф.  Именно для решения сложнейшего вопроса избавления бизнес-пользователя от решения IT задач придумали модные сейчас слова “облачные” сервисы, SaaS, Оffice 365, Google Docs… По сути, означающие, что нужная Вам программа разработана, уже установлена и настроена специалистами, которые ежедневно о ней заботятся. Вам всего лишь нужно зарегистрироваться на сайте программы и получить доступ к ней на необходимое количество времени. Доступ к такой “облачной”, читай  – развернутой в интернете знающими людьми, программе с Вашими данными Вы можете получить из любого компьютерного устройства – IPhone, ноутбук, компьютер соседа. Соответственно, пользователю не нужно больше быть IT специалистом, чтобы пользоваться современным программным обеспечением.  Я бы использовал термин “IT деградация”, возможно слишком резкий, но, все-же, отражающий суть процесса уменьшения квалификации рядовых пользователей во владении навыками установки и настройки компьютерных программ.

В какой-то весьма недалекий момент времени пользователю покажется несколько странной необходимость покупки и установки программы только на свой компьютер. Тот же пользователь будет неприятно удивлен, если ему предложат программу, к которой нельзя получить доступ из любой интернет точки. Уже сейчас, большая часть бизнес приложений – CRM, 1С, бухгалтерия, документооборот  предлагаются разработчиками как “облачные” сервисы.  

Каким Вы видите участие в этом процессе компании «Девпарк»?

Уже сейчас мы активно разрабатываем интернет версию нашего продукта: Девпарк. Фитнес – системы автоматизации фитнес клуба. Далее перенесем в интернет складской и кассовый модули.  Интернет на автостоянках тоже перестает быть диковинкой, поэтому мы планируем и нашу программу для автоматизации стоянок сделать интернет сервисом.  Фитнес клубы, бассейны, стоянки – те организации, где IT специалисты весьма слабо представлены, либо отсутствуют вовсе. Но при этом требуется обеспечить стабильную работу программного обеспечения,  и решение этой проблемы в использовании   интернет сервисов «Девпарк». 
Мы готовы будем предложить нашим клиентам защищенные стабильные сервисы доступные через интернет. Уникальность предлагаемых решений в том, что к “облачным” сервисам Девпарк можно будет подключать все тоже оборудование, что и к локально установленным – фискальные регистраторы, сканеры штрихкода, сканеры смарт карт, веб-камеру.  В дальнейшем мы предложим возможность подключения системы контроля доступа к нашим интернет сервисам.
Также сейчас мы тестируем возможности современного IP видеонаблюдения  для предоставления Клиентам сервиса видеохостинга через интернет, тоже SaaS проект. Клиент покупает видеокамеру, подключает ее к домашней сети, регистрирует камеру на специальном интернет сайте, и получает возможность смотреть видео с нее из любой точки мира, помимо этого мы обеспечиваем сервисные функции систем видеонаблюдения – видеоархив, поиск, распознавание движения, сообщения пользователю при наступлении видео событий.  Обратите внимание, я нигде не сказал -“пользователь устанавливает и настраивает программное обеспечение”.  Подобные сервисы развиты вне России, у нас пока все впереди.

Расскажите пожалуйста о технологиях, которые Вы используете в интернет сервисах Девпарк.

Это, безусловно,  наш самый большой секрет, но все же часть я открою.  Мы предлагаем нашим Клиентам настраиваемую, конфигурируемую Систему, в которой Клиент может доделать все то, что мы могли упустить. При подключении Клиент войдет в программу, в которой мы уже постарались настроить удобный и логичный интерфейс, после чего, по желанию, этот интерфейс можно настроить для себя. Также мы  предоставим возможность клиентам передавать  свои конфигурации, в том числе и  на платной основе, другим клиентам. Помимо настройки интерфейса, полей форм, справочников,  Клиент сможет воспользоваться дизайнером для настройки «под себя» печатных форм и отчетов.
Кратко о технологиях –  мы  используем возможности современных браузеров и технологии, которые позволяют делать современные удобные Интернет приложения – AJAX, HTML5, Silverlight.

Статья описывает монтаж оборудования для работы в системе «Платный доступ» для точки прохода в составе – турникет, картоприемник, контроллер СКУД Сфинкс E500.

Документация по настройке контроллеров СКУД “Сфинкс”. Внимательно ознакомьтесь с документацией по монтажу и настройке конфигурации контроллера. Один неверно установленный джампер на дип-блоке может привести к неправильной работе оборудования и потери времени на установку причины.

Шаг 1. Конфигурация контроллера.
Перед монтажом необходимо сконфигурировать контроллер, выставив переключатели на дип-блоке CONF2. В нашем случае в соответствии с инструкцией по монтажу «Сфинкс» (п. «Подключение турникетов и калиток «Ростов–Дон») переключатели 2, 4 и 7 необходимо установить в положение «ON». Остальные переключатели необходимо установить в положение «OFF».

Шаг 2. Установка программного обеспечения «Сфинкс».
Далее необходимо установить программное обеспечение для конфигурации и работы с контроллером «Сфинкс». Если у Вас в системе работает только одна точка доступа, то Вы можете скачать бесплатную версию программного обеспечения с сайта. Установка программного обеспечения проста и занимает немного времени.  Процесс установки подробно описан в инструкции администратора, которую можно скачать на сайте «Сфинкс».

Шаг 3. Подключение линии связи.
Благодаря тому, что контроллер подключается к сети Ethernet стандартным (прямым) патч–кордом, его интеграция в систему не вызывает проблем. Достаточно заранее протянуть кабель от места расположения контроллера, до места его подключения к активному Ethernet оборудованию (хаб, свич и т.п.). Данный шаг описан в п. «Подключение линии связи Ethernet» руководства по монтажу.
После подключения контроллера к сети Ethernet, необходимо произвести настройку его IP-параметров (п. «Настройка IP-параметров контроллера» руководства по монтажу и п. «Работа с IP–устройствами» руководства администратора). Контроллер и серверный компьютер должны находиться в одной подсети. Также, следует уделить особое внимание пункту, касающемуся настройки сетевых брандмауэров:
 «При использовании в IP-сети брандмауэров, необходимо для нормальной работы контроллера разрешить свободный обмен UDP-датаграммами между сервером и контроллерами системы по портам 3303 и 3305.» 
В случае невыполнения данной рекомендации возможны проблемы в работе системы в следствии потери событий приходящих от контроллера.

Тут следует упомянуть, что в системе «Платный доступ» предусмотрена вероятность потери связи системы с контроллером в следствии различных причин. В этом случае события, пришедшие с контроллера за время отсутствия связи, не будут утеряны, и при возобновлении связи будут зарегистрированы в системе «Платный доступ». Это обеспечивает корректное списание посещений и регистрацию проходов.
После выполнения настроек можно проверить связь с контроллером с помощью клиентской части программного обеспечения (см. «Руководство пользователя»).

Шаг 4. Подключение считывателей.
К контроллеру может быть подключено до четырёх считывателей, поддерживающих стандартный выходной интерфейс Wiegand-26 или Touch memory. В нашем случае использовались уже имеющиеся считыватели фирмы «Legos» PLR 2EH, подключаемые по интерфейсу Wiegand-26. Считыватели подключаются к клемникам контроллера, обозначенными PORT1 (выход) и PORT2 (вход) в соответствии со схемой и описанием подключения считывателей п. «Подключение считывателей с интерфейсом Wiegand» руководства по монтажу. Никаких затруднений данный процесс не вызвал.

Шаг 5. Подключение турникета «Ростов-Дон».

Данный шаг описан в п. «Подключение турникетов и калиток «Ростов–Дон». В нашем случае в турникете используется старая электроника. В соответствии с этим контроллер был сконфигурирован по схеме, указанной в шаге 1. Новые турникеты данного типа выпускаются с фотодатчиком для регистрации прохода. Турникет, подключение которого описано здесь, для регистрации прохода использует встроенный геркон. Данный турникет необходимо подключать по нижеприведенной схеме, в которой также указано правильное подключение геркона.

Необходимо уделить внимание инструкции по формированию зоны прохода для данного турникета, так как неправильная установка турникета может привести к потере событий прохода через турникет. Данную инструкцию можно найти в руководстве по монтажу турникета.
Также необходимо проверить настройку контроллера «Время фильтрации датчика прохода турникета». Данный пункт можно найти, выбрав в клиентской части программного обеспечения «Сфинкс» на вкладке «Оборудование» нужный контроллер, а затем зайти в его настройки. Далее снять галочку «Отображать только базовые настройки». Если значение этого параметра слишком большое – кратковременные замыкания геркона при быстром повороте планок могут игнорироваться контроллером. Нормальное значение данного параметра составляет 0.03 сек.

Если в системе будет использоваться пульт для управления турникетов, то его также необходимо подключить к контроллеру в соответствии с п. «Подключение пульта управления турникета «Ростов–Дон». Следует заметить, что существует возможность подключения пульта напрямую к контроллеру, но такой способ, хоть и не вызывает сбоев в работе системы, является неправильным, так как при команде с пульта с контроллера будут приходить события взлома.

Шаг 5. Подключение картоприемника «Эликс PW-500»
Данный шаг описан в «Подключение картоприёмников Эликс PW-500» руководства по монтажу. .

После подсоединения картоприемника к контроллеру, необходимо в настройках контроллера, доступных в клиентской части программного обеспечения «Сфинкс», переназначить клеммы в соответствии с руководством по монтажу:
«назначить на выход общего назначения O1 функцию «Линия «Вернуть карту» в направлении «выход», состояние – «нормально неактивен», на выход O2 — функцию «Линия «Изъять карту» в направлении «выход», состояние – «нормально неактивен» (см.раздел «Переназначение клемм контроллера» в «Руководстве пользователя»). Перемычку X1 на плате управления картоприёмника нужно установить в положение 1-2. Параметр «Длина импульса разрешения/запрета доступа» во временных настройках контроллера нужно установить равным 2-3 с (см. раздел «Настройка временных параметров контроллера» в «Руководстве пользователя»)»

Шаг 6. Синхронизация режимов и ключей из системы «Платный доступ» с системой «Сфинкс».

Данный шаг необходим для занесения в БД «Сфинкс» (и соответственно в контроллер) режимов (правил доступа) и ключей (карт доступа) уже существующих в системе «Платный доступ». 
Новый контроллер необходимо зарегистрировать в системе «Платный доступ». Для этого с помощью клиентской части программного обеспечения «Сфинкс» необходимо выяснить идентификатор контроллера в БД «Сфинкс». Сделать это можно на вкладке «Оборудование». Если в системе один контроллер, то его идентификатор скорее всего будет 1. 
Далее в программе «Платный доступ» необходимо перейти на вкладку «Администратор» – «Контроль доступа» – «Контроллеры СКУД» и нажать кнопку «Новый». В открывшейся форме указать любое название для создаваемого контроллера, указать тип контроллера – Сфинкс E500 (турникет) и в поле «Адрес» указать идентификатор контроллера. Далее нажать «Сохранить и закрыть». Затем необходимо перезапустить программу и снова перейти на вкладку «Администратор» – «Контроль доступа» – «Контроллеры СКУД». В списке контроллеров необходимо выбрать необходимый контроллер и нажать кнопку «Записать параметры». Произойдет синхронизация и все существующие режимы и ключи будут записаны в контроллер.

Заключение.
Благодаря простоте подключения, наличию подробной документации и грамотной, а главное оперативной помощи службы поддержки СКУД «Сфинкс» процесс монтажа СКУД «Сфинкс» с различным оборудованием и интеграция ее в систему «Платный доступ» не вызывает каких-либо значительных проблем и при наличии некоторого опыта не займет много времени.

Компания Девпарк представляет настольную программу для фитнесс клубов  fitness365

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

Описание программы и покупка на нашем новом сайте: fitness365.ru

«Девпарк Фитнес» –  компьютерная программа для учета и контроля в спортивных клубах. 

Уникальность продукта обеспечивают:

• Модульная автоматизация функций фитнес клуба, что позволяет приобрести только необходимые компоненты программного обеспечения. От клиентской базы и абонементной системы до сервера репликации данных для сетевых фитнес клубов. Такой подход к внедрению программы в клубы делает ее доступной для самых небольших спортивных организаций.
  
• Интеграция с современным торговым оборудованием и системами контроля доступа в том числе и биометрическими.
  
• Бесплатная установка ПО и последующая поддержка помогают нашим Клиентам экономить время и средства на решении IT задач. 
  

«Девпарк Фитнес» используется для

• автоматизации деятельности фитнес клубов;
• автоматизации деятельности спортивных школ;
  
• автоматизации спортивно-оздоровительных комплексов;
• автоматизации небольших фитнес залов;
  

Более подробно на сайте продукта “Девпарк Фитнес”  http://www.автоматизация-фитнеса.рф/

Компания  Девпарк успешно завершила проект по внедрению системы автоматизации фитнес клуба. Специалисты Компании провели интеграцию системы контроля доступа и управления автоматикой с установленной ранее учетно-кассовой системой клуба. Особенностями данного проекта являлись необходимость поэтапной замены поставленной ранее системы контроля доступа и интеграция новой СКУД с уже имеющейся учетной системой без каких-либо сбоев в работе фитнес центра.

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

Компания Девпарк была приглашена в спортивный клуб “Банифаций” г.Электросталь, где в то время уже была установлена система контроля доступа, разработанная сторонней компанией. Так как отсутствовала документация,  каждый компонент оборудования такой системы был уникален и не имел аналогов для замены в случае поломки, то поддержка данной системы стала невозможной. Вследствии чего было принято решение о поэтапной замене старой системы.

Первый проект реализованный на базе программы для учета и контроля доступа в фитнес клубе “Девпарк Фитнес”

2009 г. Спортивно оздоровительный  комплекс Банифаций. 

Исходные условия

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

Текущая система контроля доступа установленная в клубе представляла собой комбинацию оборудования, управляющей оборудованием программы – сервера и клиентских программ,  установленных у администраторов клуба для продажи услуг и администрирования. Оборудование представляло собой электронные контроллеры, управляющие солярием, турникетами, дверьми, тенами в саунах, считывателем штрих-кодов и считывателями отпечатков пальцев.
С помощью клиентских программ администраторы клуба продавали доступ в солярий, бронировали сауну, продавали разовые и депозитные карты в бани и зал для фитнеса. При этом клиент получал на руки карту доступа или чек со штрих-кодом,  по которым мог воспользоваться услугами клуба. Данные по продажам аккумулировались в единой Базе Данных, и  администратор клуба мог посмотреть отчеты по работе клуба. На рисунке 1 представлена схема системы управления доступом установленной в клубе.

  Рисунок 1 “Схема системы управления доступом в спортивном клубе”

Контроллеры системы  являлись кустарно разработанными, не имели возможности замены. Управляющая программа  взаимодействовала с контроллерами по собственному протоколу, используя шифрацию данных. Прошивка PIC процессоров  на контроллерах была закрыта от копирования.  Исходные коды управляющей программы отсутствовали.

Задача проекта

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

Выбор системы управления доступом

Компанией DevPark были  определены следующие критерии выбора:

• Подключение дверей, турникетов, сканера штрих-кодов, сканера отпечатков пальца.
• Управления солярием и тенами в саунах.
• Разработка управляющих программ должна быть под силу программистам, владеющим скриптовыми языками типа VBScript, JavaScript
• Гибкость конфигурирования и настройки
• Возможность интеграции с существующей базой данных
• Простота в поддержке. Эксплуатацию системы должен обеспечивать местный приходящий администратор
• Возможность оперативно приобретать и заменять компоненты системы
• Компания производитель должна иметь широкую клиентскую базу и иметь среди клиентов предприятия критичные к сбоям техники
• Наличие службы поддержки

После анализа существующих систем мы решили остановиться на системе управления доступом  компании “Легос”, как соответствующей нашим критериям. 
Компания “Легос” существует на рынке с 1991 года, ее решения используются во множестве компаний, включая такие крупные компании как «Ростелеком». Оборудование компании «Легос» имеет все необходимые государственные сертификаты. 
Использование оборудования компании «Легос» даст свободу в выборе управляющего программного обеспечения. Большая сеть партнерских компаний дистрибьюторов и установщиков  оборудования «Легос» дает гарантию решения проблем поддержания в работоспособном состояние и дальнейшем расширение системы контроля доступа и не даст попасть в зависимость от одного поставщика.
Гарантия на оборудование 2 года

Реализация проекта

Специалистами компании DevPark были  выделены две функции в старой системе контроля доступа в клубе:
1. функция учетно-кассовой системы – продажа услуг, учет средств, предоставление отчетности;
2. функция системы контроля и правления доступом.

Учетно-кассовую функцию было решено оставить на установленной в клубе программе от старой системы. А функция системы контроля и управления доступом была перенесена в СКУД «Легос».  Интеграция между учетной системой и СКУД производится через базу данных учетной системы.  
Сценарий работы такого решения – администратор продает услугу, о чем делается запись в базе данных учетной системы. Клиент получает на руки карту доступа и прислоняет ее к считывающему устройству установленному, например, в солярии.  Информация о карте доступа поступает на сервер СКУД «Легос». Сервер запускает  программу – скрипт, которая связана с событием прикладывания карты к считывателю и передает в нее параметры карты. Скрипт обращается к базе данных учетной системы и если там есть услуга по указанной карте, то передает команду на включение солярия. 
Интеграцию сильно ускорила и упростила возможность подключать в серверу Легос скрипты собственной разработки, без какой либо компиляции или разработки собственной серверной программы. Такую возможность дает программный модуль «Скриптов и реакций» входящий в СКУД Легос.

Наиболее интересные части проекта

Система управления саунами

В учетную систему вносятся данные о бронировании сауны на дату. На сервере СКУД «Легос» скрипт через некоторые интервалы сканирует базу данных учетной системы. Если на текущее время сауна забронирована, тогда скрипт посылает сигнал на включение электричества на тены, иначе он подаёт сигнал на выключение.

Необходимое оборудование

Система управления доступом в солярий

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

 Необходимое оборудование

Система управления доступом в Фитнес зал

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

Взаимодействие оборудования.

К контроллеру L4T16 подключается турникет (считыватель и замки). Котроллеры BioSmart подключаются к адресным микрочипам, которые в свою очередь подключаются к контроллеру L3U.
При считывании отпечатка пальца контроллер BioSmart передаёт на адресный микрочип номер карты, которая ассоциирована с этим отпечатком. Адресный микрочип передаёт номер карты на контроллер L3U, который в свою очередь передаёт его на сервер Легос.
При поднесении карты к считывателю на турникете скрипт проверяет права доступа по её номеру в следующем порядке: 
• Является ли эта карта картой сотрудника.
• Является ли эта карта разовой или дисконтной.
• Является ли эта карта абонементной.
Если карта является абонементной, скрипт проверяет в базе Легоса наличие события с номером карты на контроллере L3U. Это событие должно прийти, когда клиент приложит палец к считывателю отпечатков.
Считыватель отпечатков должен содержать соответствия между номером карты и отпечатком пальца. Эти соответствия программируются при заведении абонементной карты при помощи базового ПО “BioSmart-Studio”, для этого считыватель отпечатков подключается к компьютеру через преобразователь интерфейса USB-RS485.

Необходимое оборудование
 

посмотреть презентацию системы (pdf файл)

СКУД для фитнес-клуба

Автоматизация водно-спортивного комплекса

Благодарственное письмо компании “Девпарк” от компании ЗАО “Легос” 

Автор материала : Константин Станев

По вопросам покупки и установки систем управления доступом обращайтесь по телефону +7(499) 999-01-85 и по адресу sales@devpark.ru

Введение

В статье рассматривается пример решения задачи по аутентификации и авторизации клиентов Web-сервера на сервере приложений, где под Web-сервером понимается работающее на нем приложение ASP.NET, а под сервером приложений – .NET-приложение. Взаимодействие осуществляется через .NET Remoting (TCP/Binary).

Что есть интересного в рассматриваемом решении:

• Использование серверных и клиентских специализированных канальных приемников.
• Организация сессий на стороне сервера приложений и стороне Web-сервера
• Установление зависимости между клиентом и его сессиями на Web-сервере и сервере приложений.
• Организация авторизации без добавления дополнительных аргументов в методы сервера приложений.
• «Протаскивание» пользовательских данных через все методы в потоке без добавления дополнительных аргументов в методы.

В статье не рассматриваются вопросы, связанные с защитой канала передачи данных. О шифровании трафика можно прочитать тут: http://msdn.microsoft.com/msdnmag/issues/03/06/netremoting/

Задача

Архитектура использования

На рисунке 1 изображена схема некоторой информационной системы (ИС). ИС состоит из ядра – совокупности серверов приложений, выполняющих бизнес-логику, и Web-интерфейса, расположенного на WEB сервере и предоставляющего доступ к системе через Интернет. В приведенной архитектуре и будет использоваться рассматриваемое решение.

Рисунок 1.

Требования

1. Web-сервер не должен иметь прямого доступа к ИС.
2. ИСдолжна определять права пользователей на выполнение того или иного запроса (авторизованные и анонимные запросы).
3. Права пользователей определяются их ролью в ИС.

Дополнительные ограничения

Все сервисы ИС реализованы на базе платформы MS Windows (не ниже MS Windows 2000).

Серверы приложений системы расположены в пределах одной локальной сети.

Решение

Архитектура решения

В соответствии с требованиями разрабатываем архитектуру, представленную на рисунке 2

Рисунок 2.

Web-сервер – предоставляет доступ к ИС через Интернет посредством Web-интерфейса, который реализуется на технологии ASP.NET.

Сервер приложений – аутентифицирует пользователей, авторизует запросы пользователей, маршрутизирует запросы от Web-сервера к серверам ИС. Реализуются в виде .NET-приложения с возможностью удаленного вызова его методов.

База данных системы – хранит данные ИС.

Серверы приложений системы – совокупность сервисов, реализующих бизнес-логику ИС.

Firewall 1,2 – шлюзы, защищающие ИС от несанкционированного доступа.

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

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

Рисунок 3

Интересующий нас участок цепи: Web-сервер – сервер приложений для Web. Мной выбран протокол взаимодействия .NET Remoting через TCP с бинарной сериализацией по причине высокой эффективности этого сочетания по сравнению с HTTP вместе с SOAP.

Идея решения

Идея решения состоит в реализации аутентификации на уровне канальных приемников (ChannelSink), встраиваемых в инфраструктуру канала Remoting на стороне клиента и сервера. Аутентификационная информация передается в заголовках запроса (TransportHeaders), результаты аутентификации передаются в заголовках ответа сервера. Авторизация выполняется с помощью декларативной проверки соответствия роли пользователя.

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

Сессии на сервере приложений и Web-сервере различны по содержанию, так как сервер приложений может хранить обязательные для каждого пользователя объекты, вполне возможно unmanaged (COM). Взаимосвязь между клиентом, Web-сервером и сервером приложений осуществляется по идентификатору сессии.

Развертывание

На рисунке 4 приведена диаграмма развертывания рассматриваемого решения.

Рисунок 4

Решение состоит из трех основных .NET-сборок, обеспечивающих процессы аутентификации, авторизации, поддержку сессий:

SecurityBase – сборка, содержащая общие для Web-сервера и сервера приложений типы и константы.

SecurityClient – сборка, содержащая типы для клиентской части схемы аутентификации и типы, обеспечивающие поддержку сессий на Web-сервере. Устанавливается на Web-сервер.

SecurityServer – сборка, содержащая типы для аутентификации и поддержки сессий на стороне сервера приложений.

Также в пример входит сборка BusinessFacade, содержащая типы, обеспечивающие интерфейс с сервером приложений. На Web-сервер устанавливается сокращенная версия этой сборки, в ней содержатся только сигнатуры методов, без содержания.

На сервере приложений устанавливается полная версия BusinessFacade.

На Web-сервере и сервере приложений настраивается конфигурация Remoting.

На Web-сервере конфигурация содержится в Web.config

  "SHR">
    
      "RemotingExample.BusinessFacade.SomeSystem,  
       BusinessFacade" url="tcp://localhost:8039/SHR/SomeSystem.rem"/>
    
    
      "tcp client">
        
          "binary" includeVersions="false"/>
          "RemotingExample.Security.ClientChannelSinkProvider, 
           SecurityClient"/>
        
      
    
  

Не сервере приложений в ConsoleServer.exe.config:

  "SHR">
    
      "Singleton"     
       type="RemotingExample.BusinessFacade.SomeSystem,
       BusinessFacade" objectUri="SomeSystem.rem" />
    
    
      "ServerCnannel" ref="tcp server" port="8039" >
            
          "binary" includeVersions="false"/>
          "RemotingExample.Security.ServerChannelSinkProvider, 
           SecurityServer"/>
            
      
    
  

Инициализация конфигурации Remoting на Web-сервере происходит в методе:

        protected
        void Application_Start(Object sender, EventArgs e)
{
  string configPath = System.IO.Path.Combine(Context.Server.
    MapPath(Context.Request.ApplicationPath ),"Web.config");
  RemotingConfiguration.Configure(configPath);
}

Инициализация на сервере приложений:

RemotingConfiguration.Configure("ConsoleServer.exe.config");

Диаграмма классов

На рисунке 5 приведена диаграмма используемых классов, в таблице 1 – краткое описание классов.

Рисунок 5.

Таблица 1.

Аутентификация

На рисунке 6 изображен сценарий первичной аутентификации пользователя в ИС.

Рисунок 6.

Пользователь вводит логин и пароль в Web-форме. Обработчик отправки формы пытается выполнить аутентификацию:

        // Создаем контекст для аутентификации.
        // Цель: привязать к текущему потоку выполнения аутентификационные данные,
        // чтобы иметь к ним доступ из клиентского канального приемника 

ClientSecurityContext context = new  ClientSecurityContext(tbName.Text,tbPassword.Text);
try 
{
  // Обращаемся к серверу приложений
  userData = (new RemotingExample.BusinessFacade.SomeSystem()).
  GetUserData();
}
catch (System.Security.SecurityException ex)
{
  //Аутентификация на сервере приложений прошла неудачноthis.lblMessage.Text = ex.Message;
  return;
}
//Аутентификация удалась//Создаем и записываем пользователю в Cookie билет аутентификации. 
SetAuthTiket(tbName.Text, context.SessionID);

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

Когда мы создаем контекст для аутентификации, мы готовим тем самым поле деятельности для клиентского канального приемника – ClientChannelSink, который и будет выполнять всю работу по аутентификации клиента на сервере приложений.

После вызова удаленного метода:

userData = (new RemotingExample.BusinessFacade.SomeSystem()).
GetUserData();

управление получает клиентский канальный применик ClientChannelSink, а именно его метод :

        public
        void ProcessMessage(IMessage msg, 
  ITransportHeaders requestHeaders, Stream requestStream,
  out ITransportHeaders responseHeaders, out Stream responseStream)
    
//Вытаскиваем контекст запроса
ClientSecurityContext context =  ClientSecurityContext.Current;

//Проверяем, аутентифицирован ли контекст  switch (context.AuthState)
{
  case AuthenticationStates.Authenticated:
    //Если аутентифицирован, то добавляем в заголовки запроса к серверу //приложений SID контекста  
    requestHeaders[ChannelSinkHeaders.SID_HEADER] = context.SessionID;
  break;
  default :
//Иначе добавляем логин и пароль
    requestHeaders[ChannelSinkHeaders.USER_NAME_HEADER] = context.Login;
    requestHeaders[ChannelSinkHeaders.PASSWORD_HEADER] =  сontext.Password;
  break;
}        
  
//Выполняем запрос на сервер приложений
_nextSink.ProcessMessage(msg, requestHeaders, requestStream, out     
                         responseHeaders, out responseStream);

AuthenticationStates serverAuth = AuthenticationStates.NotAuthenticated;
//Получаем заголовок состояния аутентификации сервера приложенийstring serverAuthHeader =     
       (string)responseHeaders[ChannelSinkHeaders.AUTH_STATE_HEADER];
//Анализируем  полученный заголовокswitch (serverAuth)
{
//Контекст аутентифицирован на сервере приложенийcase AuthenticationStates.Authenticated:
  if (context.AuthState != AuthenticationStates.Authenticated)
  {
    //На Web-сервере контекст еще не аутентифицирован//Создаем Principal объект для контекстаstring roles = 
         responseHeaders[ChannelSinkHeaders.ROLES_HEADER].ToString();
    string[] rolesArr = roles.Split(newchar[]{','});
    IIdentity identity=new 
    GenericIdentity(ClientSecurityContext.Current.Login);
    IPrincipal userPrincipal = new GenericPrincipal(identity,rolesArr);
    //Аутентифицируем контекст
    context.SetAuthState(AuthenticationStates.Authenticated);
    context.SetPrincipal(userPrincipal);
    //Устанавливаем идентификатор сессии
    context.SetSessionID(responseHeaders[ChannelSinkHeaders.SID_HEADER].
            ToString());
//Создаем сессию на Web-сервере          
    SecurityContextContainer.GetInstance()[context.SessionID] = context;
  }  
  break;
}

Во время выполнения запроса

_nextSink.ProcessMessage(msg, 
  requestHeaders, requestStream, out responseHeaders, out responseStream);

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

ServerProcessing ProcessMessage(IServerChannelSinkStack sinkStack,IMessage   
       requestMsg, ITransportHeaders requestHeaders, 
       Stream requestStream, out IMessage responseMsg, 
       out ITransportHeaders responseHeaders,  out Stream responseStream)

  //Получаем идентификатор сессии из заголовков запросаstring SID = (string)requestHeaders[ChannelSinkHeaders.SID_HEADER];
  ServerSecurityContext context = null;
  if (SID == null)
  //Если SID отсутствует, пробуем аутентифицировать запрос
  {
    //Пробуем получить логин и пароль из заголовков запросаstring userName = 
      (string)requestHeaders[ChannelSinkHeaders.USER_NAME_HEADER];
    string password =   
      (string)requestHeaders[ChannelSinkHeaders.PASSWORD_HEADER];
    AuthenticationStates authResult = AuthenticationStates.NotAuthenticated;
    if ((userName != null) && (password != null))
    {
      //Если логин и пароль найдены, выполняем аутентификациюstring roles;
      authResult = Authenticate(userName,password, out roles);
      switch (authResult)
      {
        case AuthenticationStates.Authenticated:
          //Аутентификация прошла успешно//Создаем серверный контекст для пользователя
          context = new ServerSecurityContext(userName,roles);
          context.SetAuthState(AuthenticationStates.Authenticated);
          //Создаем сессию на сервере приложений
          SecurityContextContainer.GetInstance()[context.SessionID]=context;
        break;
        default:
          //Аутентификация не удалась.   thrownew System.Security.SecurityException("Authentication 
                                                                failed");
       }
     }
   }
   //Если SID существует в заголовках запроса, то авторизируем запрос //по этому SIDelse
   {
     //Воостанавливаем сессию по ее идентификатору
     context = 
        (ServerSecurityContext)SecurityContextContainer.GetInstance()[SID];
     if (context == null)
     {
       thrownew System.Security.SecurityException("Authorization failed");        
     }
     else
     {
       //Ассоциируем текущий контекст с полученным по SID
   ServerSecurityContext.Current = context;
     }
  }
      
  System.Security.Principal.IPrincipal orginalPrincipal = 
                                                Thread.CurrentPrincipal;
  if (ServerSecurityContext.Current != null)
  {
    //Ассоциируем Principal текущего потока с Principal объектом контекста
    Thread.CurrentPrincipal = ServerSecurityContext.Current.Principal;
  }

  sinkStack.Push(this, null);
  ServerProcessing processing;
  //Выполняем полученный запрос на сервере приложений
  processing = _nextSink.ProcessMessage(sinkStack, requestMsg, requestHeaders, 
                  requestStream ,out responseMsg, out 
              responseHeaders, out responseStream);
  sinkStack.Pop(this);      
      
  //Восстанавливаем Principal объект для потока
  Thread.CurrentPrincipal = orginalPrincipal;
  AuthenticationStates serverAuthState =     
              AuthenticationStates.NotAuthenticated;
  if (ServerSecurityContext.Current != null) 
          serverAuthState = context.AuthState;
  responseHeaders = new TransportHeaders();
  switch (serverAuthState)
  {
    case AuthenticationStates.Authenticated:
      //Если аутентификация прошла успешно, //выставляем заголовки для отправки на Web-сервер
      responseHeaders[ChannelSinkHeaders.AUTH_STATE_HEADER] =   
                              AuthenticationStates.Authenticated;
      responseHeaders[ChannelSinkHeaders.SID_HEADER] =  
                          ServerSecurityContext.Current.SessionID;
      responseHeaders[ChannelSinkHeaders.ROLES_HEADER] = 
                          ServerSecurityContext.Current.Roles;
    break;
    default :
      responseHeaders[ChannelSinkHeaders.AUTH_STATE_HEADER]=serverAuthState;
    break;
  }
  //Очищаем текущий контекст
  ServerSecurityContext.Current = null;
  //Возвращаем управление и результаты запроса в клиентский канальный приемникreturn ServerProcessing.Complete;

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

Сценарий процесса приведен на рисунке 7.

Рисунок 7.

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

Идентификация пользователя происходит в методе AuthenticateRequest Web-сервера. Этот метод вызывается сервером в начале обработки каждого запроса.

        //Получаем  из Cookies билет аутентификации
        string cookieName = FormsAuthentication.FormsCookieName;
HttpCookie authCookie = Context.Request.Cookies[cookieName];
System.Web.Security.FormsAuthenticationTicket authTicket = null;
try
{
  authTicket =   
      System.Web.Security.FormsAuthentication.Decrypt(authCookie.Value);
}
catch(Exception)
{
return;
}
if (null == authTicket)
{
return; 
} 
//Получаем идентификатор сессии пользователя из билета аутентификацииstring sessionID = authTicket.UserData;
ClientSecurityContext securityContext = null;
//Восстанавливаем сессию пользователя по ее идентификатору
securityContext = 
   (ClientSecurityContext)SecurityContextContainer.GetInstance()[sessionID];
if (securityContext != null)
{
  ClientSecurityContext.Current = securityContext;
  //Ассоциируем Principal объект с текущим потоком 
  Context.User = securityContext.User;
}
else
{
  System.Web.Security.FormsAuthentication.SignOut();
  Response.Redirect("logout.aspx");
}

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

Авторизация

Функциональность авторизации реализуется с помощью атрибута System.Security.Permissions.PrincipalPermissionAttribute, устанавливаемого перед соответствующими методами фасадного объекта (BusinessFacade):

[PrincipalPermissionAttribute(SecurityAction.Demand, Authenticated=true, 
  Role = "Admin")]
publicvoid DoAdminWork (string arg)
{
  Console.WriteLine(DateTime.Now.ToString()+": Doing Admin work: " + arg);
}

Поддержка сессий

Осуществляется с помощью объектов ServerSecurityContext, SecurityContextContainer, ClientSecurityContext на клиентской и серверной сторонах. Инициализация сессии происходит в методах AuthenticateRequest для Web-сервера и в ProcessMessage канального приемника для сервера приложений. Объекты ISecurityContext(ServerSecurityContext, ClientSecurityContext), содержащие состояние сессии, хранятся в коллекции SecurityContextContainer. Ключом к сессии является SID (идентификатор сессии). При инициализации сессия извлекается из коллекции(SecurityContextContainer) и с помощью статического метода Current ассоциируется с текущим потоком выполнения.

        public
        static ClientSecurityContext Current
{
  get 
  {
    ClientSecurityContext currentContext = (ClientSecurityContext)System.
      Runtime.Remoting.Messaging.CallContext.
      GetData("ClientSecurityContext");
    if (currentContext != null)
    {
      currentContext.lastActivity = DateTime.Now;
    }
    return currentContext;
  }
  set
  {
    if (value != null)
    {
      value.lastActivity = DateTime.Now;
    }
    System.Runtime.Remoting.Messaging.
          CallContext.SetData("ClientSecurityContext", value);
  }
}

После инициализации сессии ее состояние доступно в любом месте кода.

[PrincipalPermissionAttribute(SecurityAction.Demand, Authenticated=true)]
publicstring  GetUserData()
{
  Console.WriteLine("GetUserData " +  
      Security.ServerSecurityContext.Current.Login);
}

Главное – проставить для этого ссылки на SecurityBase и SecurityServer(SecurityClient).

Заключение

Тестовое приложение WebCl (рисунок 8) демонстрирует возможности описанного решения. Это приложение, впрочем, как и все решение, прилагается к этой статье в виде проекта в формате Visual Studio .Net 2003.

Рисунок 8

Приведенный пример может быть расширен. Например, результатом аутентификации, помимо сообщения о ее успешности или неуспешности, может стать требование сменить пароль.

Можно организовать проверку – «один пользователь – одна сессия». Можно добавить шифрование трафика. Свойство Items объектов IsecurityContext может служить контейнером для сохранения различных объектов в сессии пользователя. Путем небольшой переработки клиентской части, это решение можно адаптировать для Windows Forms-приложений. В общем, поле для деятельности большое.

Если у кого возникнут вопросы, или идеи и замечания по улучшению описанного механизма, пишите sun_shef@msn.com.