Отчет о научно-исследовательской работе, проведенной по заказу Министерства экономического развития и торговли Российской Федерации Тема
| Вид материала | Отчет |
- Ежегодная Российско-Украинская Промышленная Выставка, 294.69kb.
- Министерство экономического развития и торговли российской федерации государственный, 5458.65kb.
- Министерство экономического развития и торговли российской федерации государственный, 5460.46kb.
- Министерство экономического развития и торговли российской федерации государственный, 5753.09kb.
- Министерство экономического развития и торговли российской федерации государственный, 5459.19kb.
- Отчет о научно-исследовательской работе, 392.92kb.
- Реферат отчет о научно-исследовательской работе состоит, 61.67kb.
- Утверждено Постановлением Президиума Правления тпп РФ от 12 октября 2010 г. №75-14, 43.93kb.
- Зубович Александр Сергеевич россия на мировом рынке вооружений и военной техники, 285.21kb.
- Отчёт о научно-исследовательской работе за 2011 год, 1208.93kb.
Приложение Д: Пример схемы аутентификации и авторизации на основе разработок 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Единый выход
Важной частью этой схемы является обеспечение единого выхода. Единый выход может быть инициирован сервисом и удостоверяющим центром. При выходе агента из системы удостоверяющий центр посылает соответствующее уведомление каждому сервису, с которыми была установлена сессия для агента.