Введение в Simple Cloud Identity Management
РедакцияС ростом числа и популярности различных облачных услуг все острее встает задача надежного удостоверения идентичности пользователя и защиты этой информации. Без широкого применения стандартного способа для создания учетных записей пользователей компании вынуждены создавать собственные системы. Это, в свою очередь, ведет к удорожанию таких систем, недостаточной защищенности и создает серьезные трудности при переходе пользователя между провайдерами. Протокол SCIM предлагает прагматичное решение этой проблемы.
Работа над простым управлением идентичностью в облаках (Simple Cloud Identity Management или SCIM) перешла в фазу разработки стандарта в марте 2012 года во время IETF 83, застолбив за собой «полный сбор» на BoF-сессии. Чартер рабочей группы SCIM был представлен директорам областей месяцем позже и обсуждался в многочисленных сообществах по управлению идентичностью и доступом, таких, как Internet Identity Workshop (IIW), рабочие группы Internet2 и TERENA, в рамках Kantara Initiative и в нескольких информационно-разъяснительных кампаниях участников SCIM.
Что такое SCIM?
Протокол SCIM использует прагматичный подход к проблеме удостоверения идентичности пользователя среди многочисленных провайдеров облачных услуг. Слово Simple (простое) в названии протокола появилось отнюдь не случайно; это принцип, который использовали участники для эволюционного развития концепции и который, как они надеются, будет по прежнему применяться при ее прохождении через IETF на пути к превращению в формальный
стандарт. На веб-сайте SCIM размещена фраза, которая кратко резюмирует этот подход: «По сути, сделать это быстро, дешево и просто, обеспечив перемещение пользователей в облако, из облака и по облаку».
Почему именно теперь?
Без широкого применения стандартного способа для создания учетных записей пользователей, сервисы вынуждены создавать собственные системы. В свою очередь, любой компании, ведущей бизнес с таким сервисом, приходится нести затраты на использование специализированного интерфейса конфигурирования для каждого сервиса и специализированной схемы, которая практически не подлежит повторному использованию. Конфигурирование внутри самих организаций испытывает такие же проблемы.
Хотя в этой области и существуют стандарты, их принятие и распространение остается на низком уровне. Перед нами встает неожиданная проблема масштабирования – вместо того, чтобы беспокоиться об общей масштабируемости, основной вопрос касается возможности масштабирования до требуемого размера. Организации может требоваться только незначительная часть функциональности, предлагаемой этими протоколами, для возможности работы с соответствующей долей ресурсов и инфраструктуры.
Прагматичный подход SCIM привлекателен тем, что он задуман быть «проворным» и менее обременительным для внедрения по сравнению с существующими протоколами, а кроме того, его применение более эффективно и экономично, чем построение и обеспечение работы специально созданной среды конфигурирования.
Протокол
Протокол SCIM предоставляет общую пользовательскую схему и модель расширения, выраженные в формате JavaScript Object Notation (JSON)1 или формате XML через HTTP с помощью программного интерфейса Representational State Transfer (RESTful (ru.wikipedia.org/wiki/REST)).
На рис. 1 показаны следующие ключевые элементы SCIM:
• провайдер услуг, который хранит обрабатываемую информацию об идентичности;
• потребитель, который представляет собой веб-сайт или приложение, использующее протокол SCIM для управления данными идентичности, которые поддерживаются провайдером услуг;
• ресурсы, которые представляют собой управляемые провайдером услуг артефакты, содержащие один или несколько атрибутов.
Запросы SCIM составляются с помощью операций HTTP, а ответы возвращаются внутри тела HTTP-отклика, отформатированные как JSON или XML, в зависимости от запроса; при этом статус запроса указывается как в коде состояния HTTP, так и в теле запроса.
Операции и ожидаемые действия для HTTP
Действие операции HTTP
GET – извлекает ресурс полностью или частично.
POST – создает новый ресурс или массово модифицирует ресурсы.
PUT – модифицирует ресурс с использованием полного, указанного потребителем ресурса (замена).
PATCH – модифицирует ресурс с использованием набора указанных потребителем изменений (частичное обновление).
DELETE – удаляет ресурс.
Полную подробную информацию об откликах протокола можно найти в спецификации протокола SCIM (datatracker.ietf.org/doc/rfc7644).
Схема
Схема SCIM была создана под влиянием подхода, использованного в Portable Contacts, вместе с некоторыми дополнительными элементами, взятыми у исходных участников. По сравнению с другими форматами модель Portable Contacts обеспечивает дополнительную гибкость отображения сложности данных, что позволяет отражать сложные отношения данных на уровне пользователя. Сохраняя приверженность простоте, основная схема SCIM нацелена на охват 80% базовых атрибутов пользователя, позволяя внедрить ее максимально быстро и просто. Если отображения между используемым набором идентичности и SCIM не существуют, то доступны расширения для адаптации схемы. Конечные точки SCIM можно опросить подобно серверам LDAP, что позволяет определить индивидуальные настройки схемы.
Побочным эффектом такого подхода является то, что протокол SCIM способен инкапсулировать больше данных об идентичности, чем используемый в LDAP профиль inetOrgPerson или SAML (Security Assertion Markup Language). Подход к решению этой проблемы заключается в создании рекомендаций для отображений LDAP и SAML, которые будет управлять преобразованием высокоточной схемы SCIM в формат с низкой точностью. Целевой результат таких отображений – облегчить работу специалистов по внедрению и обеспечить непротиворечивость для тех, кому требуются отображения. Могут быть опубликованы и другие отображения, в зависимости от наличия спроса на них.
SCIM, схема и область действия
Схема была одной из наиболее часто обсуждаемых тем в SCIM и IETF, при этом ставились следующие вопросы:
• следует ли ограничивать значения атрибутов на базе значений других атрибутов?
• следует ли сделать ожидаемым или обязательным применение определенных методов управления доступом с использованием определенных атрибутов?
• чего ожидать от SCIM в области управления уникальными идентификаторами?
Каждый вопрос был интересен сам по себе в качестве темы управления идентичностью. И все-таки, простота как основополагающий принцип SCIM предполагает, что эти требования должны быть наложены/спрофилированы в самой верхней части спецификации с тем, чтобы обеспечить удовлетворение потребностей каждого уникального варианта использования. Ограничение протокола SCIM минимальной стандартной схемой, имеющей гибкую модель информации и объединенной со структурированным транспортом данных, обеспечивает повышение полезности и поощряет внедрение. В то же самое время, существует возможность использовать SCIM в качестве низкоуровневого строительного блока для более продвинутых прикладных областей, сконцентрироваться на применении политики и делегировать транспортировку данных протоколу SCIM.
Исполняемый код
Там, где это возможно, проводились сеансы совместимости спецификаций для отладки программного обеспечения и получения опыта их применения на практике. Еще до начала работы по стандартизации в IETF были проведены три таких сеанса, при этом второй состоялся в Париже накануне IETF 83, всего в нем было задействовано девять участников. Очные сеансы оказали неоценимую помощь при идентификации пробелов и неоднозначностей, которые подлежат прояснению.
Дальнейшие перспективы
Протокол SCIM находится в состоянии версии 1.0 с декабря 2011 года благодаря активному участию сообщества. Производители используют исполняемый код в течение месяцев – и целый ряд из них включили SCIM в состав ключевых возможностей своих продуктов, собирая благодаря этому ценный опыт в условиях реальной обстановки, принимая как должное эту технологию и проходя через жизненный цикл своих продуктов. Другие производители остались в стороне либо для того, чтобы посмотреть, наберет ли протокол популярность, либо по причине того, что они испытывают неудобства в связи с неопределенностью, окружающей новый протокол, и ждут, что в дальнейшем произойдет с SCIM и IETF.
Были предложены этапы реализации проекта концепции с целью принятия основной схемы SCIM, определения интерфейса RESTful и вариантов использования в качестве действующего документа к концу лета 2012 года, и формализации привязок SAML и отображений LDAP к лету 2013 года. Это позволит заполнить некоторые пробелы для тех производителей, которые ждут развития событий, и создаст определенность в других областях протокола.
Рабочая группа SCIM WG имеет в своей повестке дня целый ряд претендующих на внимание тем, которые мы здесь представим в качестве беглого наброска будущих дискуссий.
Определение и рекомендации для возможных топологий
Описание возможных топологий развертывания поможет идентифицировать, где и каким образом можно применить SCIM в качестве способа для поощрения внедрения. Слово «cloud» (облачное), входящее в состав наименования протокола SCIM, немного искажает смысл, его наличие не должно препятствовать развертыванию SCIM внутри организации. Внутреннее развертывание может быть более привлекательным, чем соединение с производителем продукта SAAS (Software as a Service). При внутреннем развертывании появляются дополнительные возможности для кастомизации, а также более полно реализуются владение и контроль над процессами конфигурирования, поэтому развертывание SCIM обеспечивает равную, если не большую полезность, упрощая внутреннюю среду подготовки и консолидируя компоненты в рамках общей модели с SCIM в качестве одного из основных элементов.
Детализация подходов к обеспечению безопасности конечных точек
Проблема заключается в том, что один размер не подходит для всех ситуаций, и не все узлы равно оснащены для выполнения одной модели вместо другой. Протокол SCIM требует использования TLS 1.2 и рекомендует применять OAuth Bearer Token в качестве метода для стимулирования взаимодействия между конечными точками SCIM, однако остается достаточно гибким, разрешая использование других протоколов.
Одной из привязок, которая изучается вместе с протоколом SCIM, является язык SAML и то, каким образом он может и должен взаимодействовать с SCIM. С точки зрения безопасности, SAML предоставляет SCIM модель доверия через федерации SAML (частные или общедоступные) и поднимает другие интересные вопросы в области безопасности. Необходимо ли в равной степени доверять всем конечным точкам внутри одного доверительного набора? И это лишь один из многих вопросов в этой сфере. Вероятно, что среды SAML получат выгоду от возможности расширить свой опыт с помощью формализации вокруг подготовки конечных точек SAML.
Схема
Существует целый ряд пунктов для обсуждения, которые могут касаться схемы. Некоторые из них уже упоминались, за исключением более тонкого и скользкого – «еще одной функциональной возможности» подхода к дополнениям схемы. Это проявляется в возникновении все большего числа атрибутов, находящихся вне основной схемы, до тех пор, пока в расширении становится больше атрибутов, чем в ядре. Протокол SCIM является достаточно гибким для того, чтобы это было возможно, но следует ли это поведение поощрять, препятствовать ему или это не должно нас заботить? Является ли это антишаблоном для укрепления базовой модели атрибутов?
Возможно, это приемлемый способ использования SCIM, если он упрощает инфраструктуру в целом, либо это метод для обеспечения неувядаемой популярности схемы и достижения максимальной гибкости с течением лет. Эту тему будет интересно обсудить.
Настоящий краткий экскурс в темы подготовки и конфигурирования высветил некоторые подлежащие дальнейшему исследованию области. По мере того, как протокол SCIM переходит к следующему раунду улучшений, поддержание баланса между простотой, практичностью и гибкостью – даже в том случае, если они противоречат друг другу – позволит повысить долговечность SCIM в качестве инструмента, входящего в состав комплекта промежуточного ПО.
Примечание редактора
Рабочая группа System for Cross-domain Identity Management (SCIM) была учреждена группой IESG 21 июня 2012 года в Прикладной области IETF и закончила свою работу в 2014, полностью выполнив стандартизацию протоколов и схемы SCIM. Хотя основные концепции SCIM не изменились, любознательный читатель может сам увидеть, как дискуссионные вопросы, обсуждаемые в этой статье, нашли свое отражение в окончательные спецификациях. Основные спецификации SCIM на настоящее время:
RFC7643 System for Cross-domain Identity Management: Core Schema – определяет основную схему SCIM
RFC7644 System for Cross-domain Identity Management: Protocol – определяет протокол SCIM
Источник: Rough Guide