Сегодня мы хотим поделиться литературной находкой, напрямую относящейся к нашей предметной области.
Тема Identity and Access Management на данный момент является достаточно закрытой, что создает проблемы для нас, в первую очередь, с подбором высококвалифицированных специалистов от ведущего разработчика до РП и архитектора. Подготовка же таких специалистов, перешедших из другой предметной области, занимает немало времени. Не меньшей проблемой является настороженное отношение к данной сфере многих заказчиков, не понимающих «зачем нам это все», если есть нормальная доменная инфраструктура. Несмотря на то, что автор книги ориентирует читателя на создание IAM-инфраструктуры на базе OSS и приводит примеры конкретных решений, основная ценность книги, на наш взгляд, заключается в систематизации области, классов продуктов, предназначенных для решения задач в области идентификации, аутентификации и управления доступом, а так же в доступном описании открытых стандартов и технологий, собранном в одном месте и разложенном по полочкам.
Книга рекомендуется:
- Архитекторам и специалистам в области ИБ для формирования представления о IAM и существующих OSS-решениях рекомендуем читать полностью.
- Enterprise-архитекторам для получения целостной картины о продуктах и возможностях можно ограничиться первой главой.
- Software- и Solution- архитекторам для формирования представления о существующих решениях, как традиционных так и современных, и использования описанных подходов на практике желательно читать полностью.
- Руководителям ИТ и ИБ предприятий для получения картины о возможностях и задачах решаемых продуктами IAM первой главы будет достаточно.
- Разработчикам и ИТ-специалистам разного уровня для расширения кругозора — читать пока интересно, разработчикам обратить особое внимание на SAML и OpenID Connect, если вы еще с ними не встречались, то высока вероятность, что в ближайшее время столкнетесь.
Ниже мы рассмотрим главы книги и их содержание.
Глава 1. Предметная область: IDM, IAM, IAG, DS. IAM и DS как отправная точка. Опенсорс и немножко Gluu
В данной главе рассматриваются функции и задачи службы идентификации и управления доступом (Identity Service) уровня предприятия и производится сравнение решений/компонентов, реализующих функции такой системы — IDM (Identity Management), IAM (Identity and Access Management), IAG (Identity and Access Governance), DS (Directory Services). Дается краткое представление о стандартах и технологиях, доступных в данной области. Глава является фундаментом для формирования целостной картины.
Подробно
Глава посвящена службе идентификации и управления доступом (Identity Service), как компоненту enterprise-инфраструктуры в архитектуре уровня предприятия. Коротко может называться «служба управления доступом». В главе приведена классификация продуктов из области управления доступом и взгляд на них, как на компоненты целостной системы. В книге выделены четыре компонента службы управления доступом:
В компонент управления субъектами (IDM) изначально (исторически) закладывался исключительно смысл поддержания актуального состояния информации о субъекте в различных информационных системах. Для решения этой задачи используется источник актуальной и достоверной информации о субъектах, к примеру, кадровая система с информацией о работниках. Решение IDM должно обеспечивать создание и поддержку актуальности учетных записей работников в других системах в течение всего «жизненного цикла работника» (Identity Lifecycle), к примеру — в результате приема на работу, при переводе внутри организации, при смене фамилии и других данных, при увольнении и т.д. Также часто IDM решает задачу самообслуживания для управления своими собственными УЗ, их паролями и всем тем, что субъект может сделать самостоятельно.
Компонент управления доступом (IAM) в «идеальном мире» решает задачи авторизации и аутентификации субъектов. Данный компонент является потребителем услуг, которые предоставляет IDM. IAM считает, что данные о субъекте уже актуализированы, и на этом предположении IAM выстраивает свою политику. На практике граница между IDM и IAM очень размыта. К примеру, для того, чтобы выполнить сброс пароля через панель самообслуживания (задача, которую решает компонент IDM), нужно быть предварительно аутентифицированным (задача, которую решает компонент IAM). Или достаточно типичен кейс, когда сброс пароля (к примеру, устаревшего в соответствии с парольными политиками) осуществляется в процессе аутентификации, и возникает потребность в обратном взаимодействии компонентов IAM и IDM.
В первой главе любопытно рассмотрен исторический путь развития идей, которые выросли в то, что из себя представляет IAM. Начиная во второй половине 90-х от протокола аутентификации, авторизации и тарификации для сетевой инфраструктуры RADIUS. Переходя к концу 90-х к концепциям PDP-PEP Pattern, воплощенным в Netegrity SiteMinder. В начале 2000-х приходя к стандартами SAML и XACML, основанным на XML/SOAP-транспортных протоколах. И уже сегодня развиваясь в сторону OAuth-решений, основанных на RESTful/JSON-транспортах.
Компонент управления политиками (IAG) уже по сути не является сугубо техническим решением, какими являются в данном контексте компонент управления субъектами (IDM) и компонент управления доступом (IAM). IAG представляет из себя комбинацию систем, правил и процедур, которые определены между субъектом доступа и организацией. IAG «соединяет» отношения между организационно-штатными единицами (подразделениями, сотрудниками) и ресурсами организации. Если немного «спуститься с небес» красочного бизнес-языка на простой и понятный язык функциональности, то IAG решает задачи управления политиками, ролевой моделью, сертификации доступа, разделения ответственности (Segregation of Duties) и аналитики.
Наконец, знакомые всем службы каталогов (Directory Services). Большая часть организаций вчера и сегодня строит свою ИТ-инфраструктуру с использованием служб каталогов. А службы каталогов, ввиду своей вездесущности, интегрируемости и в определенной степени стандартизированности, часто используются всеми остальными компонентами службы управления доступом для решения некоторых задач хранения информации о субъектах и объектах доступа.
В данной главе также дается рекомендация, с чего же начинать при построении системы управления доступом. Нет, не с красочного IAG, а с комбинации IAM со службой каталогов. Причин множество, в числе основных — «слона нужно есть по частям» (а IAM с Directory Service является более коротким и быстрореализуемым проектом, чем IDM и тем более IAG), «аппетит приходит во время еды» (владельцы систем начнут понимать реальные потребности в защите своих систем только после того, как получат опыт работы с решением по контролю доступа сотрудников в ИС).
В финале главы рассмотрены стандарты: LDAP, SAML, OAuth, OpenID Connect (OIDC) и User Managed Protocol (UMA). И до кучи рассмотрено опенсорс-решение Gluu Server, а также приведена аргументация за OSS в целом: для кого и почему оpen source решения могут быть полезны при решении данной задачи, а также правильно рассказано, почему оpen source решения не бесплатны, и как следует понимать его «бесплатность».
- Компонент управления жизненным циклом учетных записей (Identity Management, IDM).
- Компонент идентификации и авторизации (Identity & Access Management, IAM)/
- Компонент управления политиками и контроля доступа (Identity & Access Governance, IAG).
- Компонент службы каталогов (Directory Services, DS).
В компонент управления субъектами (IDM) изначально (исторически) закладывался исключительно смысл поддержания актуального состояния информации о субъекте в различных информационных системах. Для решения этой задачи используется источник актуальной и достоверной информации о субъектах, к примеру, кадровая система с информацией о работниках. Решение IDM должно обеспечивать создание и поддержку актуальности учетных записей работников в других системах в течение всего «жизненного цикла работника» (Identity Lifecycle), к примеру — в результате приема на работу, при переводе внутри организации, при смене фамилии и других данных, при увольнении и т.д. Также часто IDM решает задачу самообслуживания для управления своими собственными УЗ, их паролями и всем тем, что субъект может сделать самостоятельно.
Компонент управления доступом (IAM) в «идеальном мире» решает задачи авторизации и аутентификации субъектов. Данный компонент является потребителем услуг, которые предоставляет IDM. IAM считает, что данные о субъекте уже актуализированы, и на этом предположении IAM выстраивает свою политику. На практике граница между IDM и IAM очень размыта. К примеру, для того, чтобы выполнить сброс пароля через панель самообслуживания (задача, которую решает компонент IDM), нужно быть предварительно аутентифицированным (задача, которую решает компонент IAM). Или достаточно типичен кейс, когда сброс пароля (к примеру, устаревшего в соответствии с парольными политиками) осуществляется в процессе аутентификации, и возникает потребность в обратном взаимодействии компонентов IAM и IDM.
В первой главе любопытно рассмотрен исторический путь развития идей, которые выросли в то, что из себя представляет IAM. Начиная во второй половине 90-х от протокола аутентификации, авторизации и тарификации для сетевой инфраструктуры RADIUS. Переходя к концу 90-х к концепциям PDP-PEP Pattern, воплощенным в Netegrity SiteMinder. В начале 2000-х приходя к стандартами SAML и XACML, основанным на XML/SOAP-транспортных протоколах. И уже сегодня развиваясь в сторону OAuth-решений, основанных на RESTful/JSON-транспортах.
Компонент управления политиками (IAG) уже по сути не является сугубо техническим решением, какими являются в данном контексте компонент управления субъектами (IDM) и компонент управления доступом (IAM). IAG представляет из себя комбинацию систем, правил и процедур, которые определены между субъектом доступа и организацией. IAG «соединяет» отношения между организационно-штатными единицами (подразделениями, сотрудниками) и ресурсами организации. Если немного «спуститься с небес» красочного бизнес-языка на простой и понятный язык функциональности, то IAG решает задачи управления политиками, ролевой моделью, сертификации доступа, разделения ответственности (Segregation of Duties) и аналитики.
Наконец, знакомые всем службы каталогов (Directory Services). Большая часть организаций вчера и сегодня строит свою ИТ-инфраструктуру с использованием служб каталогов. А службы каталогов, ввиду своей вездесущности, интегрируемости и в определенной степени стандартизированности, часто используются всеми остальными компонентами службы управления доступом для решения некоторых задач хранения информации о субъектах и объектах доступа.
В данной главе также дается рекомендация, с чего же начинать при построении системы управления доступом. Нет, не с красочного IAG, а с комбинации IAM со службой каталогов. Причин множество, в числе основных — «слона нужно есть по частям» (а IAM с Directory Service является более коротким и быстрореализуемым проектом, чем IDM и тем более IAG), «аппетит приходит во время еды» (владельцы систем начнут понимать реальные потребности в защите своих систем только после того, как получат опыт работы с решением по контролю доступа сотрудников в ИС).
В финале главы рассмотрены стандарты: LDAP, SAML, OAuth, OpenID Connect (OIDC) и User Managed Protocol (UMA). И до кучи рассмотрено опенсорс-решение Gluu Server, а также приведена аргументация за OSS в целом: для кого и почему оpen source решения могут быть полезны при решении данной задачи, а также правильно рассказано, почему оpen source решения не бесплатны, и как следует понимать его «бесплатность».
Глава 2. Курс молодого бойца по LDAP. LDAP в помощь IAM. Витрина данных
В главе 2 приведен весьма объемный для книги не про LDAP инструктаж, который можно вырезать и читать отдельно от всей книги. Содержится «курс молодого бойца» по LDAP для тех, кому не интересен сам LDAP, но необходимо понимать его структуру и механизмы для решения связанных с ним задач. В теории и на практике на примере разработки Python-приложения рассказана концепция витрины данных (Data Mart) для сбора в одно место разрозненных данных об УЗ. Немного указано про подключение Gluu Server к LDAP-серверу как к источнику данных об УЗ.
Подробно
Из того, что может в данной главе быть интересно тому, кто не интересуется собственно LDAP, хотелось бы выделить мотивацию использования и роль LDAP в построении систем управления доступом.
Топ-10 причин остаться с LDAP по мнению автора книги:
Приведено описание ключевых понятий, дана краткая справка про фильтры и формат LDIF-файлов как инструмента управления данными в LDAP-каталоге. Приведены эксплуатационные характеристики и способы их достижения в LDAP. И даже описано про работу распределенного LDAP. Приведен перечень инструментов для управления LDAP-сервером: как CLI-утилит, так и GUI:
Также интерес представляет описание концепции построения витрины данных (Data Mart) об учетных записях субъектов доступа, в которую собираются данные из множества (как это обычно случается) разрозненных корпоративных хранилищ информации. Например, если в организации имеется/используется Microsoft Active Directory, еще какой-нибудь отдельный LDAP-сервер (например, FreeIPA с 389Server под капотом), имеются базы данных приложений, хранилища приложений, построенных на ERP-системах (к примеру, SAP), тогда и возникает потребность в построении этого самого мастер-хранилища. Из данного хранилища IAM уже забирает «агрегированные сведения», и использует в своих нуждах (для аутентификации и авторизации). Ключевая идея — написать набор утилит на Python, которым собрать информацию из разнородных источников данных, и записать ее в витрину данных на базе LDAP-сервера посредством LDIF-файлов. И далее приводится пример практической реализации посредством разработки небольшого Python-приложения для решения этой задачи.
Из того, что собственно по теме управления доступом — коротко рассказано про то, каким образом «прицепить» Gluu Server к вашему существующему LDAP, чтобы Gluu мог далее использовать его данные и синхронизировать их в своем внутреннем кеше, и каким образом следует обновлять данный кеш.
Топ-10 причин остаться с LDAP по мнению автора книги:
- LDAP позволяет оставаться независимым от определенного решения.
Примечание: в некотором смысле да, в некотором — нет. Наглядный пример — MS AD, который по сути уже не является LDAP-каталогом. И слезть с MS AD часто очень сложно. - У LDAP много опенсорс-утилит для управления.
Примечание: отчасти да, но удобно ли их использовать на практике — вопрос риторический. - У некоторых реализаций LDAP зрелая и надежная репликация. То есть при необходимости расширения/распределения организации или переезда на другие вычислительные ресурсы это может сильно сэкономить нервы и время.
- Большинство LDAP-серверов поддерживают определенный ассортимент алгоритмов для хеширования паролей. А также предоставляют удобный интерфейс для верификации паролей.
- Имеются инструменты для генерации тестовых наборов данных в LDAP-серверах с целью тестирования характеристик функционирования (например, производительности).
- Высокая производительность поиска.
- Прекрасные UNIX CLI-утилиты.
- Наличие возможности горизонтального масштабирования.
- Наличие возможности выполнения текстовых и бинарных бэкапов.
- LDAP во многих организациях живет десятилетиями!
Приведено описание ключевых понятий, дана краткая справка про фильтры и формат LDIF-файлов как инструмента управления данными в LDAP-каталоге. Приведены эксплуатационные характеристики и способы их достижения в LDAP. И даже описано про работу распределенного LDAP. Приведен перечень инструментов для управления LDAP-сервером: как CLI-утилит, так и GUI:
- Для любителей UNIX-way: ldapserach, ldapmodify, ldapdelete.
- Для тех, кому нужен визуальный инструментарий: Apache Directory Studio, JXplorer, Web2LDAP, phpLDAPAdmin, FusionDirectory.
Также интерес представляет описание концепции построения витрины данных (Data Mart) об учетных записях субъектов доступа, в которую собираются данные из множества (как это обычно случается) разрозненных корпоративных хранилищ информации. Например, если в организации имеется/используется Microsoft Active Directory, еще какой-нибудь отдельный LDAP-сервер (например, FreeIPA с 389Server под капотом), имеются базы данных приложений, хранилища приложений, построенных на ERP-системах (к примеру, SAP), тогда и возникает потребность в построении этого самого мастер-хранилища. Из данного хранилища IAM уже забирает «агрегированные сведения», и использует в своих нуждах (для аутентификации и авторизации). Ключевая идея — написать набор утилит на Python, которым собрать информацию из разнородных источников данных, и записать ее в витрину данных на базе LDAP-сервера посредством LDIF-файлов. И далее приводится пример практической реализации посредством разработки небольшого Python-приложения для решения этой задачи.
Из того, что собственно по теме управления доступом — коротко рассказано про то, каким образом «прицепить» Gluu Server к вашему существующему LDAP, чтобы Gluu мог далее использовать его данные и синхронизировать их в своем внутреннем кеше, и каким образом следует обновлять данный кеш.
Глава 3. SAML: экскурс, утверждения, протоколы. Snibboleth IDP и Snibboleth SP. Python-SAML
Глава 3 целиком и полностью посвящена всестороннему «прощупыванию» SAML. Приведено понятное для восприятия описание структуры элементов SAML: утверждений, протоколов, профилей и многого другого. И с практической целью приведено описание различных способов взаимодействия с SAML Identity Provider, начиная от развертывания Snibboleth Identity Provider и до использования для этой задачи библиотеки Python-SAML.
Подробно
Сперва в главе идет краткий обзор на SAML. Указан исторический путь развития с конца 90-х, когда люди мучились из-за того, что им приходилось использовать одни и те же учетные данные на различных сайтах. В этой ситуации LDAP решал задачу единого хранилища учетных данных, но не решал проблему единого входа в различные системы (Single Sign-On, SSO), и пользователи по-прежнему вводили в разных веб-приложениях одной организации одни и те же учетные данные. Некоторые вендоры предлагали свои решения задачи WebSSO, а SAML совместно с рядом организаций-участников по разработке SAML сделали общеприменимое для корпоративного WebSSO решение. Неудивительно, что SAML, будучи технологией 2005 года, основан на XML. SAML 2.0 объединил в себе опыт предыдущих попыток стандартизации (SAML 1.1, Libery Alliance ID-FF 1.2 и Snibboleth 1.3). А термины, определенные в SAML 2.0 («assertion», «relying party», «identity provider» и т.д.), в итоге стали частью лексикона решений SSO и IAM вообще. Нетрудно заметить терминологическую и идейную схожесть в других стандартах, это в том числе заслуга SAML.
В главе приводится экскурс (весьма подробный для тех, кто впервые сталкивается с SAML) по терминологии и основам SAML: Assertions (утверждения), Bindings (способы передачи), Protocols (протоколы) и Profiles (профили). Приведены простые и понятные описания и иллюстрации к структуре SAML и взаимоотношениям между его структурными единицами. Раскрывается понятие «протокол» применительно к SAML, рассматривается концепция взаимодействия Service Provider и Identity Provider. Рассмотрены сценарии аутентификации в сравнении: аутентификация, инициируемая службой аутентификации (Identity Provider-initiated, IDP-initiated) в сравнении с аутентификацией, инициируемой поставщиком услуг (Service Provider-initiated, SP-initiated). Также рассмотрены способы передачи (HTTP Redirect (GET), HTTP Post, Simple Sign, SAML SOAP, Reverse SOAP, HTTP Artifact, SAML URI). Приведено описание трех профилей SAML: Web Browser SSO Profile, Single Logout Profile и Attribute Profile.
Далее заканчивается теория, и начинается практика с использованием Gluu Server (ну конечно же). На практике приводятся шаги по развертыванию Snibboleth Identity Provider, входящего в состав Gluu Server. Так как Identity Provider не очень интересен без Service Provider, приводится практический мануал по развертыванию собственного Service Provider на основе Snibboleth Service Provider.
И на десерт для любителей Python: практический пример использования библиотеки Python-SAML с целью написания утилит к SAML как для его тестирования, так и для решения связанных с SAML прикладных задач.
В главе приводится экскурс (весьма подробный для тех, кто впервые сталкивается с SAML) по терминологии и основам SAML: Assertions (утверждения), Bindings (способы передачи), Protocols (протоколы) и Profiles (профили). Приведены простые и понятные описания и иллюстрации к структуре SAML и взаимоотношениям между его структурными единицами. Раскрывается понятие «протокол» применительно к SAML, рассматривается концепция взаимодействия Service Provider и Identity Provider. Рассмотрены сценарии аутентификации в сравнении: аутентификация, инициируемая службой аутентификации (Identity Provider-initiated, IDP-initiated) в сравнении с аутентификацией, инициируемой поставщиком услуг (Service Provider-initiated, SP-initiated). Также рассмотрены способы передачи (HTTP Redirect (GET), HTTP Post, Simple Sign, SAML SOAP, Reverse SOAP, HTTP Artifact, SAML URI). Приведено описание трех профилей SAML: Web Browser SSO Profile, Single Logout Profile и Attribute Profile.
Далее заканчивается теория, и начинается практика с использованием Gluu Server (ну конечно же). На практике приводятся шаги по развертыванию Snibboleth Identity Provider, входящего в состав Gluu Server. Так как Identity Provider не очень интересен без Service Provider, приводится практический мануал по развертыванию собственного Service Provider на основе Snibboleth Service Provider.
И на десерт для любителей Python: практический пример использования библиотеки Python-SAML с целью написания утилит к SAML как для его тестирования, так и для решения связанных с SAML прикладных задач.
Глава 4. OAuth: не протокол, а фреймворк. Экскурс. Пример с Google API. Пример с Gluu Server
Объясняется место OAuth в «мире» протоколов аутентификации и авторизации. Разъясняется структура OAuth как фреймворка авторизации: роли участников OAuth-взаимодействий (Authorization Server, Resource Server, Client), токены (Bearer и JWT), сценарии взаимодействия (так называемые «grants»). Практический пример авторизации в Google API с OAuth. И практический пример настройки OAuth в Gluu Server.
Подробно
Как не сложно догадаться по предыдущим главам, здесь тоже будет много теории и немного практики про OAuth. Правильное замечание загружается в голову читателя с первых строк главы: что OAuth по сути не протокол (как его часто называют), а фреймворк авторизации (набор терминов и основополагающих «универсальных» шаблонов). OAuth не является протоколом аутентификации. В то время как SAML используется корпоративными приложениями, OAuth (чаще всего используемый вместе с расширениями типа OIDC) на практике больше применим для «потребительских» (consumer) приложений и инфраструктур.
Подробно рассматриваются роли участников OAuth-взаимодействия: сервер авторизации (Authorization Server), сервер ресурсов (Resource Server), клиент (Client). Рассмотрены токены, которые, собственно говоря, и используются участниками для авторизации: Bearer Token, JWT (JSON Web Token). Немного внимания уделено объяснению стандартизированных сценариев взаимодействия участников OAuth, которые называются «grants» (что логично, ведь OAuth используется именно для предоставления кому-либо доступа к данным Resource Server): Authorization Code Grant, Implicit Grant, Resource Owner Password Credential Grant, Client Credential Grant, Token Introspection.
С точки зрения практики рассмотрена работа с Google API с применением OAuth-авторизации: как авторизоваться в API с применением OAuth. И для продолжения идеи построения опенсорс-инфраструктуры для управления доступом рассмотрена практическая реализация Client Grant Flow на примере Gluu Server.
Развитие идей OAuth будет продолжено в главах 5, 6 и 8. В главе 5 рассматривается наиболее известное решение на OAuth — OIDC, который чаще всего применяется в общедоступных веб-приложениях. В главе 8 рассматривается UMA, который развивает идеи OAuth в части предоставления доступа к API (API access management). А в главе 6 рассматривается использование веб-прокси совместно с OAuth для защиты API.
Подробно рассматриваются роли участников OAuth-взаимодействия: сервер авторизации (Authorization Server), сервер ресурсов (Resource Server), клиент (Client). Рассмотрены токены, которые, собственно говоря, и используются участниками для авторизации: Bearer Token, JWT (JSON Web Token). Немного внимания уделено объяснению стандартизированных сценариев взаимодействия участников OAuth, которые называются «grants» (что логично, ведь OAuth используется именно для предоставления кому-либо доступа к данным Resource Server): Authorization Code Grant, Implicit Grant, Resource Owner Password Credential Grant, Client Credential Grant, Token Introspection.
С точки зрения практики рассмотрена работа с Google API с применением OAuth-авторизации: как авторизоваться в API с применением OAuth. И для продолжения идеи построения опенсорс-инфраструктуры для управления доступом рассмотрена практическая реализация Client Grant Flow на примере Gluu Server.
Развитие идей OAuth будет продолжено в главах 5, 6 и 8. В главе 5 рассматривается наиболее известное решение на OAuth — OIDC, который чаще всего применяется в общедоступных веб-приложениях. В главе 8 рассматривается UMA, который развивает идеи OAuth в части предоставления доступа к API (API access management). А в главе 6 рассматривается использование веб-прокси совместно с OAuth для защиты API.
Глава 5. OpenID Connect. Теория: структура, терминология. Развертывание Gluu Server OIDC Provider
Объясняется история появления и место OpenID Connect. Сравнение с SAML. Структура, действующие лица, сценарии взаимодействия в OpenID Connect. Развертывание OpenID Connect сервера на базе Gluu Server. Развертывание клиентского приложения на JavaScript для реализации OpenID Connect клиента.
Подробно
OpenID Connect (сокращенно OIDC либо, как в книге, Connect; нам больше нравится однозначный OIDC) появился в то время, когда возникла потребность в так называемом «Federated Identity» на фоне взлета Consumer Identity Provider (Consumer IdP) у Facebook, Google и Microsoft. Возникало множество проблем из-за различий OAuth-реализаций в каждом из этих IdP, что и привело в итоге к стандартизации и появлению OpenID Connect.
OIDC имеет много параллелей с SAML (подробно рассматриваемым в главе 3); в книге приведено сопоставление терминов SAML с терминами OIDC. Так как OIDC формировался позже SAML, он построен уже не на XML с SOAP, а на более современных и «модных» на тот момент формате сообщений JSON и идеях транспортных RESTful веб-сервисов. Из различий — сценарии использования SAML заточены больше под внутрикорпоративную аутентификацию (для аутентификации сотрудников в веб-приложениях компании), OIDC же — под «потребительскую» аутентификацию, когда перечень потребителей аутентификации может быть очень обширным и неконтролируемым.
Далее в главе приводится хороший и подробный обзор структуры, терминологии и механизмов OIDC. Если необходимо освежить свои представления об OIDC, то глава 5 из данной книги — очень компактный источник необходимых объяснений.
Немного раскрыта тема использования встроенного в Gluu Server OpenID Connect Provider. Для любителей практики раскрывается тема развертывания простого JavaScript клиента для подключения к Gluu Server OpenID Connect Provider.
OIDC имеет много параллелей с SAML (подробно рассматриваемым в главе 3); в книге приведено сопоставление терминов SAML с терминами OIDC. Так как OIDC формировался позже SAML, он построен уже не на XML с SOAP, а на более современных и «модных» на тот момент формате сообщений JSON и идеях транспортных RESTful веб-сервисов. Из различий — сценарии использования SAML заточены больше под внутрикорпоративную аутентификацию (для аутентификации сотрудников в веб-приложениях компании), OIDC же — под «потребительскую» аутентификацию, когда перечень потребителей аутентификации может быть очень обширным и неконтролируемым.
Далее в главе приводится хороший и подробный обзор структуры, терминологии и механизмов OIDC. Если необходимо освежить свои представления об OIDC, то глава 5 из данной книги — очень компактный источник необходимых объяснений.
Немного раскрыта тема использования встроенного в Gluu Server OpenID Connect Provider. Для любителей практики раскрывается тема развертывания простого JavaScript клиента для подключения к Gluu Server OpenID Connect Provider.
Глава 6. Proxy: веб-прокси для IAM. Apache httpd, Nginx, Kong, Istio
Предназначение веб-прокси. Опенсорс-решения: Apache httpd, Nginx, Kong, Istio.
Подробно
В главе рассматривается механизм веб-прокси. Ключевая идея главы применительно к IAM — прокси позволяет контролировать доступ к веб-ресурсам.
Указаны варианты возможного его использования (для IAM некоторые пункты не применимы):
Далее в общих чертах рассмотрены опенсорс-решения прокси-серверов: Apache httpd, Nginx, Kong и Istio. Для некоторых приведены краткие практические листинги команд по установке.
Указаны варианты возможного его использования (для IAM некоторые пункты не применимы):
- Для защиты веб-ресурсов организации от потенциальных атак на уязвимости ПО, от несанкционированного доступа к внутренним ресурсам организации.
- Балансировки нагрузки и обеспечения отказоустойчивости.
- Контроля и ограничения доступности ресурса для его потребителей.
- Кеширования и сжатия передаваемых потребителям данных.
- Телеметрии путем подстановки всяческих идентификаторов в передаваемый трафик.
- И даже монетизации на примере Amazon Web Services.
Далее в общих чертах рассмотрены опенсорс-решения прокси-серверов: Apache httpd, Nginx, Kong и Istio. Для некоторых приведены краткие практические листинги команд по установке.
Глава 7. Strong Authentication. TOTP/HOTP. SSL/TLS. FIDO UAF/U2F. Web Authentication, CTAP
Проблемы аутентификации с использованием паролей. Технология аутентификации с применением одноразовых паролей TOTP/HOTP. Аутентификация по сертификатам в Mutual SSL/TLS. Технологии FIDO UAF и U2F, W3C Web Authentication, CTAP. Поддержка FIDO в Gluu Server.
Подробно
Рассматриваются возможные варианты решения проблемы кражи паролей для обеспечения «сильной» аутентификации.
Прежде всего внимание уделено OTP (TOTP и HOTP), как способа избежать кражи постоянных паролей. Рассказано о пользе использования OTP в качестве второго фактора — так как в этом случае компрометация основного пароля лишается былого смысла. Рассмотрены различия между аппаратными OTP-устройствами и распространенными мобильными OTP-приложениями (Google Authenticator и так далее).
Для защиты взаимодействия между клиентом и сервером рассмотрено применение SSL и TLS (Mutual SSL/TLS). Применение SSL/TLS позволяет на уровне пользовательского браузера проверить сертификат сервера (который выпущен Certificate Authority, CA), и установить между клиентом и сервером защищенный обмен. Но это еще не все — далее сервер может аутентифицировать клиента по предоставленному клиентом сертификату (полученному клиентом также от CA) и предоставить доступ к запрошенному клиентом ресурсу. Несмотря на кажущуюся простоту, данная технология не получила широкого распространения. На сегодня Mutual SSL/TLS используется все реже и реже по причине сложности установки сертификатов клиентам, и трудностей, которые вызывает сопровождение клиентских сертификатов на клиентских устройствах.
Далее рассматривается работа аутентификации с использованием Fast Identity Online (FIDO) от одноименной организации FIDO Alliance, состоящего из двух фреймворков: Universal Authentication Framework (UAF) и Universal Second Factor (U2F). Фреймворк FIDO UAF ориентирован на реализацию беспарольной (passwordless) аутентификации. А FIDO U2F предназначен для поддержки универсального второго фактора (2FA), дополняющего основную аутентификацию. К клиенту, который будет аутентифицироваться посредством FIDO, предъявляется требование — наличие поддержки данных фреймворков в клиентском ПО, которое осуществляет аутентификацию пользователя. В современных версиях браузеров поддержка FIDO встроена по умолчанию. Преимущество использования FIDO заключается в том, что он выступает в роли стандартизированной прослойки для работы с различными аппаратными факторами, включая биометрию, смарт-карты, токены и многое другое.
Про W3C Web Authentication API, также разработанный в FIDO Alliance, и который по сути является развитием FIDO, предложена очень наглядная схема взаимодействующих компонентов и стандартов. Указаны стандарты, описывающие взаимодействие между пользовательским устройством и сервером (Signature, Key Attestation), взаимодействие между браузером и приложением, осуществляющим для него аутентификацию (W3C Web Authentication API), а также взаимодействие между браузером и аппаратными внешними факторами (Client to Authenticator Protocol, CTAP).
Далее в общих чертах рассмотрена поддержка многофакторной аутентификации в Gluu Server. И так же коротко рассмотрена поддержка FIDO в Gluu Server. Также очень актуально разъясняются возможные расходы на внедрение и поддержку 2FA/MFA в случае применения опенсорс-решений.
Прежде всего внимание уделено OTP (TOTP и HOTP), как способа избежать кражи постоянных паролей. Рассказано о пользе использования OTP в качестве второго фактора — так как в этом случае компрометация основного пароля лишается былого смысла. Рассмотрены различия между аппаратными OTP-устройствами и распространенными мобильными OTP-приложениями (Google Authenticator и так далее).
Для защиты взаимодействия между клиентом и сервером рассмотрено применение SSL и TLS (Mutual SSL/TLS). Применение SSL/TLS позволяет на уровне пользовательского браузера проверить сертификат сервера (который выпущен Certificate Authority, CA), и установить между клиентом и сервером защищенный обмен. Но это еще не все — далее сервер может аутентифицировать клиента по предоставленному клиентом сертификату (полученному клиентом также от CA) и предоставить доступ к запрошенному клиентом ресурсу. Несмотря на кажущуюся простоту, данная технология не получила широкого распространения. На сегодня Mutual SSL/TLS используется все реже и реже по причине сложности установки сертификатов клиентам, и трудностей, которые вызывает сопровождение клиентских сертификатов на клиентских устройствах.
Далее рассматривается работа аутентификации с использованием Fast Identity Online (FIDO) от одноименной организации FIDO Alliance, состоящего из двух фреймворков: Universal Authentication Framework (UAF) и Universal Second Factor (U2F). Фреймворк FIDO UAF ориентирован на реализацию беспарольной (passwordless) аутентификации. А FIDO U2F предназначен для поддержки универсального второго фактора (2FA), дополняющего основную аутентификацию. К клиенту, который будет аутентифицироваться посредством FIDO, предъявляется требование — наличие поддержки данных фреймворков в клиентском ПО, которое осуществляет аутентификацию пользователя. В современных версиях браузеров поддержка FIDO встроена по умолчанию. Преимущество использования FIDO заключается в том, что он выступает в роли стандартизированной прослойки для работы с различными аппаратными факторами, включая биометрию, смарт-карты, токены и многое другое.
Про W3C Web Authentication API, также разработанный в FIDO Alliance, и который по сути является развитием FIDO, предложена очень наглядная схема взаимодействующих компонентов и стандартов. Указаны стандарты, описывающие взаимодействие между пользовательским устройством и сервером (Signature, Key Attestation), взаимодействие между браузером и приложением, осуществляющим для него аутентификацию (W3C Web Authentication API), а также взаимодействие между браузером и аппаратными внешними факторами (Client to Authenticator Protocol, CTAP).
Далее в общих чертах рассмотрена поддержка многофакторной аутентификации в Gluu Server. И так же коротко рассмотрена поддержка FIDO в Gluu Server. Также очень актуально разъясняются возможные расходы на внедрение и поддержку 2FA/MFA в случае применения опенсорс-решений.
Глава 8. User-Managed Access (UMA) Profile. UMA Grant/Federated Authorization. Gluu Server, Gluu Gateway
Рассматривается протокол авторизации UMA 2.0, расширяющий OAuth 2.0. Практические кейсы. Теоретический обзор UMA Grant. Обзор UMA Federated Authorization. Реализация UMA Authorization Server на основе Gluu Server. Использование Gluu Gateway для подключения клиентских приложений к UMA.
Подробно
В данной главе рассматривается протокол доступа, управляемого пользователем (User-Managed Access Protocol, UMA 2.0). Данный протокол уже не про аутентификацию, а про авторизацию. И он, подобно OIDC, является расширением OAuth 2.0, рассмотренного в деталях в главе 4. Также такое взаимодействие называют «Alice to Bob Sharing». Как указано во введении в главу, ее не следует рассматривать как полное руководство по UMA, а скорее как обзор и введение в столь сложную область задач, для решения которых может использоваться UMA. В книге рекомендуется при реализации клиента UMA обращаться прежде всего к документу «UMA 2.0 Grant for OAuth 2.0 Authorization». А при реализации сервера (будь то UMA Resource Server или UMA Authorization Server) обязательно знакомиться с «Federated Authorization for UMA 2.0».
UMA может быть интересен для реализации различных кейсов, с которыми мы сталкиваемся в реальных ситуациях передачи доступа к чему-либо кому-либо. Например, при реализации федеративного предоставления доступа к документам (federated document sharing), как это делает Google Docs. Также пример из реальной жизни — авиакомпания предоставляет своим клиентам услугу аренды автомобиля. И авиакомпании с компанией по прокату автомобилей может очень здорово помочь возможность «шэринга» определенной информации между собой и клиентом для того, чтобы предоставить общему для них клиенту удобный сервис.
По UMA рассмотрены варианты экосистем (narrow, medium, wide), определен специфический «жаргон» (Resource Owner (RO), Requesting Party(RqP), Permission Ticket и т.д.). В одной из теоретических частей главы в деталях рассмотрены сценарии для UMA Grant (UMA RPT Requests with Interactive Claims Gathering, UMA RPT Requests with a Pushed Claim Token), а также уделено внимание рассмотрению RPT Request Options и клиентских данных (Client Credentials). В последующей части уделено много внимания рассмотрению UMA Federated Authorization, предназначенной на случай взаимодействия в среде нескольких независимых серверов авторизации (authorization servers) с несколькими серверами ресурсов (resource servers).
Применительно к Gluu Server рассмотрена практическая реализация UMA Authorization Server с управлением scopes, политиками, и с управлением сценариями динамически вычисляемых утверждений о субъекте доступа (interactive claims gathering workflows). А так как для UMA-сервера авторизации (authorization server) конечно же требуется UMA-клиент в лице сервера ресурсов (resource server), рассматривается применение библиотеки Gluu Gateway из состава Gluu Federation. Это позволит решить проблему немногочисленности существующих на сегодняшний день клиентских реализаций для UMA 2.0.
UMA может быть интересен для реализации различных кейсов, с которыми мы сталкиваемся в реальных ситуациях передачи доступа к чему-либо кому-либо. Например, при реализации федеративного предоставления доступа к документам (federated document sharing), как это делает Google Docs. Также пример из реальной жизни — авиакомпания предоставляет своим клиентам услугу аренды автомобиля. И авиакомпании с компанией по прокату автомобилей может очень здорово помочь возможность «шэринга» определенной информации между собой и клиентом для того, чтобы предоставить общему для них клиенту удобный сервис.
По UMA рассмотрены варианты экосистем (narrow, medium, wide), определен специфический «жаргон» (Resource Owner (RO), Requesting Party(RqP), Permission Ticket и т.д.). В одной из теоретических частей главы в деталях рассмотрены сценарии для UMA Grant (UMA RPT Requests with Interactive Claims Gathering, UMA RPT Requests with a Pushed Claim Token), а также уделено внимание рассмотрению RPT Request Options и клиентских данных (Client Credentials). В последующей части уделено много внимания рассмотрению UMA Federated Authorization, предназначенной на случай взаимодействия в среде нескольких независимых серверов авторизации (authorization servers) с несколькими серверами ресурсов (resource servers).
Применительно к Gluu Server рассмотрена практическая реализация UMA Authorization Server с управлением scopes, политиками, и с управлением сценариями динамически вычисляемых утверждений о субъекте доступа (interactive claims gathering workflows). А так как для UMA-сервера авторизации (authorization server) конечно же требуется UMA-клиент в лице сервера ресурсов (resource server), рассматривается применение библиотеки Gluu Gateway из состава Gluu Federation. Это позволит решить проблему немногочисленности существующих на сегодняшний день клиентских реализаций для UMA 2.0.
Глава 9. IDM: функциональный обзор. MidPoint, Syncope, Wren:IDM, Gluu Casa
В развитие идей главы 1 рассмотрены причины, почему IDM важен для организации. Приведен функциональный обзор опенсорс-IDM систем Evolveum MidPoint, Apache Syncope, Wren:IDM, Gluu Casa.
Подробно
Несмотря на то, что книга прежде всего про IAM, а не про IDM или IAM (см. обзор главы 1), в ней нашлось место и столь важной теме, как Identity Management. Поэтому приведен краткий обзор opensource-решений: Evolveum MidPoint, Apache Syncope, Wren:IDM и Gluu Casa.
Важность IDM для построения инфраструктуры управления доступом неоспорима, так как именно IDM обеспечивает «чистоту» входных данных, с которыми затем работают IAM и IAG. IAM-платформа выступает здесь потребителем данных, которые подготовлены и приведены в порядок IDM-решением. А с ростом размера организации критичность соблюдения «чистоты» и актуальности данных о субъектах доступа постоянно возрастает.
MidPoint, Syncope и Wren:IDM предоставляют привычную функциональность IDM: подтверждения (approvals), сценарии согласования доступа (workflows), коннекторы к кадровым источникам (synchronization connectors) и самообслуживание с управлением паролями (self-service password management). Gluu Casa добавляет к этим функциям возможность самостоятельного управления вторыми факторами (2FA; подробнее про тему «сильной» аутентификации многое сказано в главе 7). По каждой системе приведен обзор функций, и в целом данная глава представляет из себя обзорный материал для того, чтобы более внимательно присмотреться к различным IDM системам и понять, что они из себя представляют.
Важность IDM для построения инфраструктуры управления доступом неоспорима, так как именно IDM обеспечивает «чистоту» входных данных, с которыми затем работают IAM и IAG. IAM-платформа выступает здесь потребителем данных, которые подготовлены и приведены в порядок IDM-решением. А с ростом размера организации критичность соблюдения «чистоты» и актуальности данных о субъектах доступа постоянно возрастает.
MidPoint, Syncope и Wren:IDM предоставляют привычную функциональность IDM: подтверждения (approvals), сценарии согласования доступа (workflows), коннекторы к кадровым источникам (synchronization connectors) и самообслуживание с управлением паролями (self-service password management). Gluu Casa добавляет к этим функциям возможность самостоятельного управления вторыми факторами (2FA; подробнее про тему «сильной» аутентификации многое сказано в главе 7). По каждой системе приведен обзор функций, и в целом данная глава представляет из себя обзорный материал для того, чтобы более внимательно присмотреться к различным IDM системам и понять, что они из себя представляют.
Глава 10. Multiparty Federation. Топологии. Роли. SAML Feredation/OpenID Federation. Стандарты OTTO Federation, Trustmarks. Jaagger Federation Mgmt Tool/Fides
Объединение участников предоставления доступа в сети доверия (Multiparty Federation). Треугольник доверия (Trust Triangle). Характеристики LOA, LOP, LOC. Топологии: Meshed Federation, Proxy Federation, Interfederation Trust. Federation Actors: Registration Authority, Federation Operator, Entity. Технологии SAML Federation, OpenID Federation. Стандарты OTTO Federation, Trustmarks. Инструменты Jagger Federation Management Tool, OTTO-Node/Fides.
Подробно
В заключительной главе рассматривается проблема доверия в среде, объединяющей множество участников взаимодействия в части предоставления доступа (Multiparty Federation). Несмотря на то, что эта глава обзорна, она очень обширна, так как погружает сразу в целый ассортимент стандартов, понятий, технологий и инструментов.
В так называемом «треугольнике доверия» (Trust Triangle, описанном на терминах OpenID Connect) указано, что хочет получить каждый из участников «отношений»:
На основании этого треугольника вводятся три важных характеристики для распределенной среды управления доступом:
В условиях распределенной инфраструктуры предоставления доступа возникает потребность в более системном подходе к обеспечению необходимых уровней доверия. В числе концепций распределенного управления доступом в главе рассмотрены следующие топологии объединения участников Identity Provider и Service Provider в «сети доверия»:
Далее в главе подробно рассматриваются соглашения в части защиты информации в подобных распределенных «топологиях доверия», в том числе с отсылками к регламентным документам (NIST Special Publication 800-63C, NIST 800-63-C). Дано описание ролей такого распределенного взаимодействия (Federation Actors) в лице Registration Authority (RA), Federation Operator (FO), Participant и Entity с описанием зон ответственности каждого.
Применительно к рассмотренным ранее стандартам в главе дано описание SAML Federations и OpenID Federations. В дополнение к SAML Federation рассмотрен инструментарий Jagger Federation Management Tool. Пристальное внимание уделено набору стандартов Open Trust Taxonomy for OAuth (OTTO) Federation, а также стандарта Trustmarks.
Также рассмотрено веб-приложение OTTO-Node/Fides. Данное решение позволяет развернуть систему самообслуживания для «вступления» в объединение (federation): когда пользователь может самостоятельно зарегистрироваться в веб-портале и стать полноправным участником объединения.
В так называемом «треугольнике доверия» (Trust Triangle, описанном на терминах OpenID Connect) указано, что хочет получить каждый из участников «отношений»:
- Пользователь (Person) хочет контролировать (control) свои данные (например, обновить или удалить свою информацию).
- Провайдер аутентификации (OpenID provider) хочет, чтобы ресурс мог защитить (protection) свои данные.
- Ресурс (Relying Party) хочет быть уверенным (assurance), что субъект, которому он предоставляет данные, действительно тот, за кого себя выдает.
На основании этого треугольника вводятся три важных характеристики для распределенной среды управления доступом:
- Уровень гарантии (Level of assurance, LOA).
- Уровень защиты (Level of protection, LOP).
- Уровень контроля (Level of control, LOC).
В условиях распределенной инфраструктуры предоставления доступа возникает потребность в более системном подходе к обеспечению необходимых уровней доверия. В числе концепций распределенного управления доступом в главе рассмотрены следующие топологии объединения участников Identity Provider и Service Provider в «сети доверия»:
- Ячеистая топология (Meshed Federation), на практике реализованная среди учреждений высшего образования в США и координируемая организацией InCommon. Аналогичный подход воплощен для высших учебных заведений в Евросоюзе под эгидой организации eduGAIN.
- Топология объединения с доверенным прокси (Proxy Federation Service). В данной схеме имеется общий доверенный посредник для остальных участников. Он соединяет между собой другие Identity Provider, являясь для них Service Provider, и выступает в роли Identity Provider для остальных Service Provider. Собственно говоря, прокси как прокси, ничего необычного.
- Доверие между доверенными объединениями (Interfederation Trust). В данной схеме устанавливается доверие между объединениями. В качестве такого примера также можно рассматривать уже упомянутые InCommon и eduGAIN, которые осуществляют между собой двустороннее доверенное взаимодействие.
Далее в главе подробно рассматриваются соглашения в части защиты информации в подобных распределенных «топологиях доверия», в том числе с отсылками к регламентным документам (NIST Special Publication 800-63C, NIST 800-63-C). Дано описание ролей такого распределенного взаимодействия (Federation Actors) в лице Registration Authority (RA), Federation Operator (FO), Participant и Entity с описанием зон ответственности каждого.
Применительно к рассмотренным ранее стандартам в главе дано описание SAML Federations и OpenID Federations. В дополнение к SAML Federation рассмотрен инструментарий Jagger Federation Management Tool. Пристальное внимание уделено набору стандартов Open Trust Taxonomy for OAuth (OTTO) Federation, а также стандарта Trustmarks.
Также рассмотрено веб-приложение OTTO-Node/Fides. Данное решение позволяет развернуть систему самообслуживания для «вступления» в объединение (federation): когда пользователь может самостоятельно зарегистрироваться в веб-портале и стать полноправным участником объединения.
Резюме от прочтения книги
Книга дает очень обширный обзор всех тем, которые могут интересовать специалиста, которому необходимо строить защищенную инфраструктуру авторизации и управления доступом в современных реалиях. Именно благодаря компактному охвату столь сложных тем, собранному под одной обложкой, читатель получает пищу для размышлений в необходимой для того дозировке. Книга будет полезна как тем, кому впервые необходимо разобраться в идеях и технологиях данной области, так и тем, кому требуется актуализировать и освежить свои познания в этой теме.