Отчет о научно-исследовательской работе разработка концепции Объединенных Государственных и муниципальных Информационных ресурсов (огир) по теме
| Вид материала | Отчет |
- Отчет о научно-исследовательской работе по теме: №21 «Разработка рекомендаций по созданию, 4474.83kb.
- Отчет о научно-исследовательской работе, проведенной по заказу Министерства экономического, 6886.49kb.
- Отчет о научно-исследовательской и опытно-конструкторской работе по теме, 2858.14kb.
- Отчет о научно-исследовательской и опытно-конструкторской работе по теме, 5626.08kb.
- Отчет о научно-исследовательской работе разработка концепции архитектуры программного, 551.78kb.
- Отчет о научно-исследовательской работе профессорско-преподавательского состава, 617.56kb.
- Отчет онаучно-исследовательской работе по теме: «Моделирование деятельности органов, 1105.18kb.
- Отчет онаучно-исследовательской работе по теме: «Моделирование деятельности органов, 2423.22kb.
- Отчет о научно-исследовательской работе по теме: «Разработка комплекса мер по формированию, 2952.71kb.
- Отчет о научно-исследовательской работе «разработка концепции развития корпоративного, 4114.59kb.
7.7Концепция технического взаимодействия
Концепция технологической совместимости является составной частью АЭГ и содержит требования к обязательному применению стандартов, обеспечивающих технологическую совместимость ОГИР и поддержку ЭАР.
Стандарты здесь и далее определяются как открытые (свободные) спецификации, выработанные по известной технологии, изменения в которые вносятся по публичной процедуре.
В проектах ОГИР необходимо использовать:
- IETF протоколы интернета (TCP/IP) для организации транспортного уровня при связи отдельных информационных систем и подсистем (ietf.org);
- World Wide Web Consortium XML для описания и публикации используемых информационных структур (w3c.org/xml)
- Unicode Consortium unicode для кодировки всей входящей и исходящей информации (www.unicode.org);
- В качестве языка разметки документации к программам DocBook XML (ссылка скрыта).
- В любых других случаях применяются следующие правила:
- Никакое взаимодействие между различными ГИР, а также ГИР и информационными системами граждан и организаций не может проходить вне раскрытого ЭАР, предусматривающего такое взаимодействие и ссылающегося на раскрытый протокол агент-агентского взаимодействия.
- Протокол агент-агентского взаимодействия должен базироваться на одном из высокоуровневых стандартов, наиболее подходящих для данного случая. Запрещается взаимодействие агентов двух принципалов, которое проходит не в рамках стандарта.
- Стандарт считается допустимым к применению в ОГИР, если существует хотя бы одна свободная его реализация, дающая возможность независимой проверки его применимости.
8Приложение Г: Пример схемы аутентификации и авторизации на основе разработок Liberty Alliance
8.1Введение
Цель этого примера дать ясное и краткое описание принципов возможного устройства схем аутентификации и авторизации.
В основе этой схемы лежат три объекта:
- Агент — объект, выполняющий определенные действия и взаимодействующий с другими объектами.
- Сервис – объект, предоставляющий набор услуг.
- Удостоверяющий центр – сервис, предлагающий определенный набор услуг другим сервисам. Основная задача удостоверяющего центра заключается в аутентификации агентов.
Рисунок Г.1 - Компоненты и взаимодействия схемы авторизации и аутентификации.
Полная архитектура данной схемы может быть составлена из трех основных архитектурных компонентов:
- Сетевые Маршрутизаторы (Web redirection), состоящие из HTTP-redirect-based redirection и form-POST-based redirection, создают канал связи между удостоверяющим центром и сервисами через агента, использующего данные сервисы. Используемые маршрутизаторы имеют хорошо известные уязвимые места и ограничения, тем не менее, они вполне могут удовлетворять потребностям данной схемы.
- Веб сервисы (Web services) – протоколы, позволяющие объектам взаимодействовать друг с другом напрямую.
- Метаданные и схемы (Metadata and schemas) - общий набор метаданных и форматов, необходимых для эффективного взаимодействия сервисов и удостоверяющих центров.
8.2Описание Технологии
8.2.1Единый доступ
В системе с множеством сервисов и удостоверяющих центров, важно существование механизма, посредством которого агенты (по их усмотрению) могут быть однозначно идентифицированы всеми сервисами и удостоверяющими центрами, входящими в систему. Подход единого доступа заключается в возможности агента, проходить процедуру аутентификации удостоверяющим центром один раз за сессию и затем использовать эту аутентификацию для создания сессии с другими агентами и, возможно, даже с другими удостоверяющими центрами, без повторного прохождения процедуры аутентификации. Агенту необходим простой способ аутентификации у сервиса, даже если агент еще не взаимодействовал с удостоверяющим центром. Для этого, необходим механизм, с помощью которого сервис получает информацию от удостоверяющего центра, подтверждающего аутентификацию агента. Этот механизм должен работать и в случае, когда агент уже взаимодействовал с удостоверяющим центром и теперь хочет, чтобы сервис принял эту аутентификацию.
Наиболее распространенный метод аутентификации в распределенных сетях, обычно реализуется посредством имени и введения соответствующего пароля. Этот подход, вероятнее всего, останется преобладающим, однако в рассматриваемой схеме удостоверяющий центр не ограничен только этим механизмом аутентификации (Приложение 3 и 4). Возможны и более сложные и безопасные механизмы, использующие криптографические подписи, сертификаты и т.п.
8.2.2Объединение локальных ученых записей
При функционировании агенту может потребоваться услуги нескольких сервисов. Для упрощения процесса перехода от одного сервиса к другому, агент может создать Федерацию учетных записей (Identity Federation), т.е. связать свои множественные учетные записи в доступных сервисах и, возможно, в нескольких удостоверяющих центрах. Создав Федерацию, агент может использовать услуги этих сервисов без дополнительных процедур аутентификации каждым из этих сервисов. Для обеспечения единого доступа, при первоначальном обращении агента к удостоверяющему центру необходимо предусмотреть возможность объединения локальных учетных записей (local identity) на сервисе с учетными записями, используемыми удостоверяющим центром. Федерация основывается на предварительном соглашении между сервисами и удостоверяющими центрами. Дополнительно, должно существовать документальное подтверждение согласия агента на объединение, что позволит обеспечить юридическую чистоту взаимодействия.
Если агент может объединить свои учетные записи в Федерацию, он так же может ее аннулировать. Этот процесс называется дефедерация. Для этого удостоверяющий центр должен уведомить соответствующие сервисы о дефедерации. Данный процесс может быть инициирован как сервисом, так и удостоверяющим центром.
При едином доступе или создании Федерации, агент «направляется» от сервиса к удостоверяющему центру. При разрыве Федеративных связей повторяется эта же процедура.
Как пример решения этой задачи, можно использовать:
- Сетевые Маршрутизаторы (Web redirects) в комбинации с SOAP протоколом, для обмена информацией об идентификации, зашифрованной с помощью SAML протокола, и обеспечения единого доступа.
- Шифрование этого обмена информацией с помощью протокола SSL для обеспечения конфиденциальности.
Другой аспект Федерации состоит в том что, если какая-то локальная учетная запись агента скомпрометирована, остальные локальные учетные записи, объединенные в данную Федерацию, остаются нескомпрометироваными.
8.2.3Трастовый Круг
С точки зрения сервиса участники Федерации образуют Трастовый Круг (Trust Circle), т.е. объединение сервисов и удостоверяющих центров, вовлеченных в интерактивные взаимодействия, имеющие операционные соглашения, с которыми агенты могут совершать безопасные транзакции.
Члены Трастового Круга доверяют друг другу и поэтому не обязаны обеспечивать идентификатор учетной записи для агента, а вместо этого могут обеспечить маркер (handle) агента (см. ниже). Операционное соглашение регулирует взаимоотношения, правила аутентификации и раскрытия информации (Приложение 3).
В случае если в Трастовый Круг вошло несколько удостоверяющих центров, сервисам необходимо знать удостоверяющий центр, использующийся агентом, и это должно работать между различными доменами.
Варианты решения этой задачи:
- Создание общего домена доступного всем участникам Трастового Круга. Когда агент аутентифицирует себя у определенного удостоверяющего центра, удостоверяющий центр направляет агента к сервису общего домена удостоверяющего центра с атрибутом, указывающим на использование агентом того удостоверяющего центра. Сервис общего домена создает cookie с этой пометкой и переадресовывает агента назад к удостоверяющему центру. После этого сервисы и другие удостоверяющие центры в Трастовом Круге могут определить, какой удостоверяющий центр был использован агентом.
- Простое составление списка "известных" удостоверяющих центров и последующая сверка с этим списком.
8.2.4Псевдоним
При вхождении агента в сеть, ему присваивается Псевдоним — имя которым сервис и удостоверяющий центр обозначают агента. Этот Псевдоним имеет значение только в контексте взаимодействия между сервисом и удостоверяющим центром. С помощью Псевдонима несложно отслеживать историю взаимодействий агента, и, по желанию агента, быстро создавать те или иные Федеративные связи данного агента.
В системах с многочисленными сервисами и удостоверяющими центрами необходимо предусмотреть механизм, с помощью которого агенты могли быть однозначно идентифицированы среди многочисленных доменов. В то же время, требования конфиденциальности агента требуют, чтобы агент не был обязан иметь единственный идентификатор по всем доменам.
Эта задача может быть решена с помощью создания каждым членом Трастового Круга маркера (handle) каждого агента. Члены могут создавать множественные маркеры для каждого агента, но каждый удостоверяющий центр должен иметь единственный маркер для каждой пары (агент, сервис), даже если сервис распределен в сети.
Удостоверяющий центр и сервис в Федерации должны помнить маркеры друг друга, которые они присвоили агенту. Для этого они создают реестр агентов (на своем ресурсе) друг для друга и записывают маркеры друг друга, которые они присвоили агенту.
В некоторых сценариях, удобнее использовать только один маркер, присвоенный агенту удостоверяющим центром.
В целях безопасности сервисы и удостоверяющие центры могут периодически обновлять маркеры агентов, уведомляя друг друга об этом.
8.2.5Единый выход
Важной частью этой схемы является обеспечение единого выхода. Единый выход может быть инициирован сервисом и удостоверяющим центром. При выходе агента из системы удостоверяющий центр посылает соответствующее уведомление каждому сервису, с которыми была установлена сессия для агента.