Технологии и средства межорганизационной Аутентификации и Авторизации RELARN

Технологии и средства межорганизационной Аутентификации и Авторизации RELARN 2004 3 июня, 2004 Yuri Demchenko, University of Amsterdam June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z Slide 2_

Содержание · Особенности Аутентификации (Auth. N) и Авторизации (Auth. Z) в научных и образовательных сетях · Основные технологии u Особенности сервисов Auth. N/Auth. Z в Grid · Существующие системы распределенной аутентификации и авторизации u Инфраструкутра распределенной аутентификации A-Select · Примеры проектов (Collaboratory. nl, EGEE) · Справочная информация u Архитектура June 3, 2004 RELARN 2004 безопасности на основе XML Interorganisational Auth. N/Auth. Z 2

Auth. N/Auth. Z в научных и образовательных сетях · Доступ к многосайтовым Веб/Интернет ресурсам u Перенаправление + cookie (SSO) · Межуниверситетские ресурсы и доступ к внешним ресурсам или предоставление доступа для внешних пользователей u Например, библиотечные каталоги или научные БД · Распределенные университетские кампусы и дистанционное обучение · Грид-центры и Грид-приложения · Общие характеристики/проблемы Различные административные домены и домены безопасности u Единый доступ (SSO – Single Sign On) и множество паролей u Разделение идентификации/аутентификации и управления доступом u June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 3

Особенности Auth. N/Auth. Z в Grid · Операционые особенности Различные административные домены и домены безопасности u Задачи могут быть продолжительные, изменяемые и мобильные u – Требование к аутентичности, целостности и доверию Динамические ресурсы u Использование прокси-удостоверений (proxy-credentials) и делегирование u · Виртуальные организации (ВО) Сервисы безопасности как и в реальных организациях (РО), но создаваемые динамически u ВО как стандартный Грид-сервис u – Динамически создаваемые и ликвидируемые Обычно имеет место членство во многих ВО u Согласованность политики безопасности между ВО и РО u June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 4

Современная архитектура сервисов Auth. N и Auth. Z Требования к современной архитектуре Auth. N/Z · Разделение сервисов аутентификации (Auth. N) и авторизации (Auth. Z) u u Аутентификация в «домашней» / «родной» организации Авторизация ресурсом · Конфиденциальность, приватность и анонимность · Управление доступом на основе ролей (RBAC – Role Based Access Control) и использование политики безопасности Проблемы · Множество логинов/паролей – на каждый ресурс/сайт · Ограничение одним доменом безопасности или множество сертификатов открытых ключей · Сложность частичной динамической делегации полномочий Базовые технологии · LDAP директории и метадиректории для храненения данных о пользователях · Собственные системы авторизации June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 5

Использование LDAP в сервисах Auth. N/Auth. Z Структуры персональных данных в LDAP · Person (RFC 2256), organisational. Person (RFC 2256), Inet. Org. Person (RFC 2798) · Edu. Person – расширение для образовтельных организаций Основные атрибуты Person object. Class · · · · · sn/sur. Name cn/common. Name given. Name uid, display. Name user. Password x 500 unique. Identifier user. Certificate user. SMIMECertificate user. PKCS 12 June 3, 2004 RELARN 2004 · postal. Address · o/organization. Name · ou/organizational. Unit. N ame · st/state. Or. Province. Name · l/locality. Name · c/country · title, employee. Type · mail · photo Interorganisational Auth. N/Auth. Z Дополнительные атрибуты Edu. Person (всего 43) • edu. Person. Affiliation • edu. Person. Nickname • edu. Person. Org. DN • edu. Person. Org. Unit. DN • edu. Person. Primary. Affiliation • edu. Person. Principal. Name • edu. Person. Entitlement • edu. Person. Primary. Org. Unit. DN 6

Безопасность приложений на основе XML и традиционная модель сетевой безопасноти Традиционная модель сетевой безопасности (ISO 7498 -2): · Host-to-host или point-to-point безопасность · Ориентированная на архитектуру клиент/сервер · Ориентированные на соединении (connection-oriented) и без соединения (connectionless) · В общем случае единый доверительный домен (на основе PKI) Безопасность приложений на основе XML · Безопасность между конечными точками или приложениями (end-to-end) · Ориентированная на документ (или семантический обьект) u Мандаты и маркеры безопасности могут быть ассоциированы с документом или сообщением или их частью · Существующие технологии WS-Security обеспечивают безопасность между разными административными доменами безопасности · Позволяет создавать динамические и виртуальные ассоциации безопасности June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 7

Управление доступом на основе ролей RBAC – Role Based Access Control · Роль описывает функцию и определяет права/привилегии · Права определяют доступ к ресурсу в определенном режиме Преимущества RBAC · · · Легко управлять и контролировать Раздельное назначение роли-пользователи и роли-привилегии Масштабируемость и иерархия Поддерживает принцип минимально необходимых привилегий Наследование и агрегирование привилегий/прав u Новая роль может включать комбинацию уже существующих ролей с их правами · Упрощает процедуру делегирования June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 8

Инфраструктура управления привилегиями PMI – Privilege Management Infrastructure (ISO/IEC 10181 -3) · Строится на основе Сертификатов Атрибутов (AC – Attribute Certificate) · АС совместно с СОК определены стандартом X. 509 version 4 u СОК используется для аутентификации, АС используется для авторизации · PMI как основа для построения RBAC АС позволяет связать идентификатор пользователя с ролями и роли с привилегиями u Поддерживает иерархические системы RBAC, предоставляя возможность обьединения роли и дополнительных привилегий u Ограничивает глубину делегирования u · Политика PMI Используется для контроля доступа к ресурсам на основе ролей u Правила определения ролей для пользователей и привилегий для ролей u Раздельные политики для субьекта, иерархия ролей, делегирование, др. u June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 9

Основные компонены и потоки информации в PMI PEP (Policy Enforcement Point)/ AEF (authorisation enforcement function) PDP (Policy Decision Point)/ADF (authorisation decision function) PIP (Policy Information Point)/AA (Attribute Authority) PA – Policy Authority June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 10

Свободно распространяемые средства для Auth. N/Auth. Z Разработаны в рамках проектов Internet 2, FP 5 и национальных научных сетей · · A-Select - http: //a-select. surfnet. nl/ Shibboleth - http: //shibboleth. internet 2. edu/ PAPI - http: //www. rediris. es/app/papi/index. en. html PERMIS (Privil. Ege and Role Management Infrastructure Standards validation) - http: //www. permis. org/ · SPOCP - http: //www. spocp. org/ Для GRID-приложений · VOMS – Virtual Organisation Management System · GAAA Toolkit – http: //www. aaaarch. org/ June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 11

A-Select (1) A-Select представляет собой распределенную систему веб-доступа (weblogin) с использованием cookie Поддерживаемые методы аутентификации · · · IP address User/password через RADIUS Банковская карточка (с режимом Internet banking – SMS/TAN, Challenge generator) SMS (mobile phone) LDAP PKI (в перспективе) June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 12

Компоненты A-Select User Application Filter Remote Authentication Service Providers June 3, 2004 RELARN 2004 Local Authentication Service Providers A-Select Agent Local A-Select Server Remote A-Select Server UDB Interorganisational Auth. N/Auth. Z 13

A-Select (2) A-Select использует билеты/квитанции, которые содержат пользовательские мандаты/удостоверения. · Есть два типа квитанций: u u Квитанция, гарантирующая квитанцию ("ticket granting ticket"), выдаваемая после успешной аутентифиации ASP, and Квитанция придложения ("application ticket"), которая выдается приложением, использующим A-Select. · Единый доступ (Single-Sign-on) обеспечивается за счет назначения более длительного периода жизни для квитанция, гарантирующая квитанцию · Квитанции A-Select реализованы как не-постоянные (non-persistent) cookie, которые сохраняются в браузере пользователя и видимы только для целевого сервиса или сервера June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 14

PAPI – простейшая система котроля веб-доступа PAPI – распределенная система доступа к ресурсам Интернет · Может использоваться как для доступа внутри реалма так между реалмами · Использует HTTP/cookie и PKI PAPI Auth. N tokens Browser 302+data 302+ Hcook GPo. A Hcook- Lcook Po. A June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 15

PERMIS (Privil. Ege and Role Management Infrastructure Standards) PERMIS обеспечивает авторизацию на основе политики с использованием Сертификатов атрибутов X. 509 для хранения атрибутов/ролей пользователя · Может работать с любой системой Auth. N (например, username/pswd, PKI, Kerberos, etc. ), которая обеспечивает Auth. N и возвращает атрибуты пользователя · На основе идентификатора пользователя (Субьекта), целевой системы (Цели), Действия возвращает решение о доступе на основе принятой Политики безопасности для данной цели u Политика и атрибуты пользователя могут быть запрошены сответственно из БД политики и хранилища атрибутов · Политика основана на RBAC и описывается в форме XML подобной XACML · PERMIS может работать в режиме push или pull (т. е. , атрибуты передаются в PERMIS, или PERMIS запрашивает атрибуты от хранилища атрибутов) June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 16

SPOCP (Simple Policy Control Protocol) Использует S-выражения для построения иерархической системы правил доступа для ролей · Позволяет обрабатывать множество ролей и действий Пример: Политика: (role Um. U admin finance) <= (role Um. U admin) Запрос SPOCP от почтового SMTP сервера: (spocp (resource mailrelay)(action mail)(subject (smtpauth roland))) · SPOCP обеспечивает упрощенную процедуру обмена данными и запроса, а также упрощенный формат сообщений по сравнению со средствами общего назначения XACML и SAML June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 17

Базовая архитектура AAA Policy based Authorization decision Request/Response Generic AAA (RBE) Policy • Defined by Resource owner June 3, 2004 RELARN 2004 ASM ASM · Req {Auth. Ntoken, Resource. Ctx, Attr/Roles, Policy. Type. Id} · RBE (Req. Ctx + Policy) => => Decision {Response. AAA, Action. Ext} · Action. Ext = {Req. AAAExt, ASMcontrol} · Response. AAA = {Ack. AAA/Reject. AAA, Req. Attr, Req. Auth. N, Bind. AAA (Resource, Id/Attr)} • Translate log. Decision => Action • Translate State => Log. Condition Interorganisational Auth. N/Auth. Z 18

GAAA Toolkit (1) – формат политики if ( Auth. N == Trust. Domain ) then ( if ( Resource. State == Request. Resource. Context) then ( if ((Action == action 1)) then ( if ((Role == role 1)) then ( Reply: : Answer. Message = "Permit" ) else ( Reply: : Answer. Message = "Deny, Role is not valid" ) ) else ( Reply: : Answer. Message = "Deny, Action is not valid" ) ) else ( Reply: : Answer. Message = "Deny, Resource is not ready" ) else ( Reply: : Answer. Message = "Deny, Subject is not authenticated" ) June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 19

GAAA Toolkit (2) · RBE реализована на J 2 EE (платформа Tomcat 4. 5/5) · Формат политики Внутренний – GAAA u Обмен - XACML u · Автоматическая генерация политики на основе таблицы доступа · Формат сообщений Запрос/Ответ - XACML June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 20

Примеры проектов - Collaboratory. nl (CNL) · Консорциум: DSM, Corus, Philips, FEI, TI, Uv. A · Создание безопасной среды для кооперативного выполнения сложных аналитических задач/экспериментов u Широкое использование XML Security, Web Services, Grid-технологий · Архитектура безопасности на основе семантического описания работы/задачи · Аутентификация – распределенная система управления идентификацией пользователей (Identity Management) на основе виртуальных организаций (ВО) u Использование A-Select · Управление доступом на основе ролей и политики доступа u Архитектура AAA и язык для управления доступом XACML June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 21

Аритектура безопасности CNL Уровни услуг безопасности 1 - Сетевой/траспортный включает сервисы безопасности сетевого уровня 2 – Безопасность сообщений обеспечивает безопасность передачи XML-сообщений 3 – Политика безопасности обеспечивает применение политики безопасности ресурсов или ассоциаций для конкретных услуг безопасности 4 – Операционные сервисы безопасности включает базовые/конечные сервисы безопасности, включая Auth. N, Auth. Z, ау дит Услуги безопасности узла Управление ключами PKI, Управление пользователями, Управление политикой безопасности, Обнаружение вторжений в сеть и Реагирование на инциденты безопасности June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 22

CNL: Посстроене безопасности на основе описания работы Job. Descr • ------- • Job# • Job Attributes • Job Priority • ------- • User list • User roles/attr • Admin RBAC Заказ ------Order Descr Планировщик ------Schedule Подсистема безопасности • User. DB • Policy · Описание работы Job. Descr является семантическим обьектом, определяющим атрибуты Работы, Пользoвателя и Политику безопасности u Требует технологии безопасности XML, построенные вокруг семантического обьекта · Доверительный домен определяется бизнес-соглашением (BA - Business Agreement) или соглашением о доверии (TA - Trust Agreement) посредством СОК/PKI June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 23

CNL: Процессы Auth. N/Auth. Z PEP/Auth. Z – принимает запрос от Ресурса или Пользователя и в стандартной форме передает его PDP/PBE – принимает решение о доступе на основе запроса (Субьект, Ресурс, Действие) и Политики User. DB – хранит информацию о пользователе для Auth. N (пароль, СОК) и атрибуты/роли пользователя для Auth. Z Policy. DB – БД политики безопасности для различных ресурсов RBAC/PMI Admin. IF – административный интерфейс для управления доступом пользователей June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 24

Шифрование файла и XML-шифрование File. A/ Doc. A Шифр. с/для pub. K B Зашифр. файл (pub. K B) Дешифр. с priv. K B File. A/ Doc User B Дешифр с priv. K B Doc 1 Только пользователь B может прочитать File. A при помощи priv. K B Пользователь A (знает pub. K B) XML Doc 1 Шифровать определ. часть для определ. получателя Пользователь A (знает pub. K B, C, D) Зашифр. определ. части C D Пользователь B может проочитать весь Doc 1 и дешифровать только часть B B C D Дешифр с priv. K C Doc 1 B D Пользователь C может проочитать весь Doc 1 и дешифровать только часть C Для много-пользовательского шифрования Document может содержать ключ для дешифрации (симметричный или асимметричный), зашифрованный при помощи ОК всех целевых получателей June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 25

Связывание атрибутов с документом при помощи XMLSig XML Doc 1/ Job. Descr Signed selected parts Sig. B Sig. C XMLSig. A Signed selected parts Sig. B Sig. C Sig. D Пользователь/ система A создают XML Doc 1 и подписывают его с Sig. A XMLSig. A Sig. D XMLSig. A Пользователи B, C, D подписывают определенные части документа своими секретными ключами priv. K B, C, D • Новая ипформация может быть добавлена и документ подписан в целом • Подпись может также включать другие подписи Sig. B Sig. C Sig. D Получатель проверяет целостность XML Doc 1 посредством контроля цифровых подписей XML Signature позволяет подписывать отдельные части документа · Основа для аутетичности и целостности (Integrity and Authenticity) · Связывание атрибутов безопасности и прав с документом или его частями June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 26

Примеры проектов –EGEE JRA 3 – Security Architecture and Services Статус: · Определение требований и начало создания прототипа Предложение: · Потоколы транспортного уровня и уровня сообщений u SOAP over HTTPS или SOAP-XML Security over HTTP · Делегирование u WSDL Port. Type · Политика безопасности Связывание с Грид-сервисами на уровне описания WSDL u Комбинирование политик ресурсов и виртуальных организаций u Интерфейс администратора политики u June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 27

Примеры проектов – Безопасность в EGEE Trust anchors Revocation Access control Cred store VOMS VO policy Proxy cert Site policy process space GRAM + LCMAPS Policy based auth. Z g. Soap service Trust anchors Revocation Access control Site policy EDG CRL scripts SAML XACML EDG LCAS delegation HTTPG Audit Provisioning ? ? ? June 3, 2004 RELARN 2004 Intrusion Interorganisational Auth. N/Auth. Z 28

Справочная информация · · Компоненты XML Security XML Web Services WS-Security OGSA Security June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 29

Компоненты безопасности XML - приложений · XML Signature · XML Encryption · Декларации безопасности (Security Assertions) u SAML (Security Assertion Mark-up Language) u Xr. ML (XML Right Mark-up Language) u XACML (XML Access Control Mark-up Language) · XKMS (XML Key Management Specification) · Архитектурные расширения u Web Services Security (WS-Security) u OGSA Security June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 30

Основные черты XML-подписи Фундаментальная черта: возможность подписывать отдельные части документа так же как и целый документ. · XML-документ может иметь длинную историю, при этом различные части докумепнта могут создаваться и визироваться различными субьектами и в различное время · Различные стороны/субьекты могут иметь полномочия подписывать только различные части документа · Позволяет сохранять целостность одних частей документа и иметь возможность изменять другие части документа · Позволяют присоединять маркеры/мандаты безопасности к документу в отличие от использования безопасного соединения клиент/сервер · XML-подпись обеспечивает сервисы безопасности для протколов, основанных на XML u А также основу для включения информации о состоянии June 3, 2004 RELARN 2004 Interorganisational Auth. N/Auth. Z 31

Структура XML-подписи ( ()? )+ ()? (