WikiDer > Доступ, управляемый пользователем

User-Managed Access

Доступ, управляемый пользователем (UMA) является OAuthстандарт протокола управления доступом. Версия 1.0 стандарта утверждена Кантара Инициатива 23 марта 2015 г.[1]

Согласно уставу группы, разработавшей UMA,[2] цель спецификаций протокола - «дать возможность владельцу ресурса контролировать авторизацию обмен данными и другой доступ к защищенным ресурсам между онлайн-сервисами от имени владельца или с его разрешения автономной запрашивающей стороной ». Эта цель имеет последствия для конфиденциальности и согласия для веб-приложений и Интернет вещей (IoT), как показано в коллекции тематических исследований, представленных участниками группы стандартов.[3]

История и предыстория

В Кантара Инициативы Рабочая группа UMA[4] провела свою первую встречу[5] 6 августа 2009 г. Принципы проектирования и технический дизайн UMA основаны на предыдущей работе сотрудников Sun Microsystems, начатой ​​в марте 2008 г., над протоколом ProtectServe. В свою очередь, на ProtectServe повлияли цели Управление взаимоотношениями с поставщиками движение и ответвление, называемое VRM на основе каналов.

В первых версиях ProtectServe и UMA использовались OAuth 1.0 протокол. Поскольку OAuth претерпел значительные изменения в результате публикации спецификации протокола авторизации веб-ресурсов (WRAP) и, впоследствии, проектов OAuth 2.0, спецификация UMA не отставала, и теперь в ней используется семейство спецификаций OAuth 2.0 для нескольких ключевых потоков протокола.

UMA не использует и не зависит от OpenID 2.0 в качестве средства идентификации пользователя. Тем не менее, он дополнительно использует протокол OpenID Connect на основе OAuth в качестве средства сбора утверждений об идентичности от запрашивающей стороны, чтобы попытаться удовлетворить политику доступа авторизующего пользователя.

UMA также не использует и не зависит от языка разметки расширяемого контроля доступа (XACML) как средство кодирования политики пользователя или запроса решений политики. UMA не диктует формат политики, поскольку оценка политики выполняется внутри сервера авторизации (AS) с точки зрения UMA. Обычно для реализации политик внутри AS используется XACML. Его реализация выходит за рамки UMA. Потоки протокола UMA для запроса разрешения доступа имеют некоторые общие черты с протоколом XACML.

Статус стандартизации

Группа UMA ведет свою работу в рамках инициативы Kantara Initiative.[6] а также внесла ряд спецификаций Internet-Draft в Инженерная группа Интернета (IETF) в качестве возможного центра работы по стандартизации UMA. С этой целью WG представила на рассмотрение IETF несколько отдельных Интернет-проектов. Одна из них, спецификация для динамической регистрации клиента OAuth,[7] служил входными данными для более общего механизма, в конечном итоге разработанного для OAuth.[8]

Статус внедрения и принятия

Базовый протокол UMA имеет несколько реализаций,[9] включая несколько реализаций с открытым исходным кодом. Источники активных и доступных реализаций с открытым исходным кодом включают ForgeRock,[10] Глуу,[11], IDENTOS Inc.,[12] MITREid Connect,[13] Атрикор, Узел-UMA[14], Роланд Хедберг[15], Keycloak.[16] и Сервер идентификации WSO2.[17] Группа Kantara Initiative работает над разработкой «бесплатного программного обеспечения с открытым исходным кодом (FOSS) на нескольких популярных языках программирования, которое дает разработчикам возможность включать защиту UMA и API авторизации в приложения, сервисы и устройства».[18]

Продукты с поддержкой UMA ​​доступны в Gluu.[19], Иерихон Системс[20], ForgeRock[21], IDENTOS Inc. [22] и сервер идентификации WSO2 [23]

Сравнение с OAuth 2.0

Эта диаграмма обеспечивает общий обзор сущностей и отношений, задействованных в спецификации UMA.

На диаграмме (см. Справа) показаны основные дополнения, которые UMA вносит в OAuth 2.0.

В типичном потоке OAuth владелец человеческих ресурсов (RO), работающий с клиентским приложением, перенаправляется на сервер авторизации (AS) для входа в систему и согласия на выдачу токена доступа, чтобы клиентское приложение могло получить доступ к серверу ресурсов. (RS) от имени RO в будущем, вероятно, в ограниченной (ограниченной) форме. RS и AS, по всей вероятности, работают в одном домене безопасности, и любая связь между ними не стандартизирована основной спецификацией OAuth.

UMA добавляет три основных концепции и соответствующие структуры и потоки. Во-первых, он определяет стандартизированный API в AS, называемый API защиты, с которым общается RS; это позволяет нескольким RS взаимодействовать с одной AS и наоборот, а поскольку сам API защищен с помощью OAuth, позволяет формально устанавливать доверительные отношения между каждой парой. Это также позволяет AS представлять RO с централизованным пользовательским интерфейсом. Во-вторых, UMA определяет формальное понятие запрашивающей стороны (RqP), которая автономна от RO, позволяя совместное использование между сторонами и делегирование авторизации доступа. RO не должен давать согласие на выдачу токена во время выполнения, но может установить политику в AS, позволяя RqP пытаться получить доступ асинхронно. В-третьих, UMA позволяет попыткам доступа приводить к успешной выдаче токенов, связанных с данными авторизации, на основе процесса повышения доверия в RqP, например, сбора от них утверждений идентичности или других утверждений.

Применимые варианты использования

Архитектура UMA может обслуживать множество вариантов использования как для потребителей, так и для предприятий. Группа UMA собирает тематические исследования на своей вики.[3]

Один из примеров набора вариантов использования - это ИТ в сфере здравоохранения и здоровье потребителей. В организации OpenID Foundation создана рабочая группа под названием Health Relationship Trust (HEART).[24] работает над «гармонизацией и разработкой набора спецификаций конфиденциальности и безопасности, которые позволят физическому лицу контролировать авторизацию доступа к API-интерфейсам обмена данными, связанными со здоровьем RESTful», опираясь, помимо других стандартов, на UMA.

Другой пример набора вариантов использования, который изначально повлиял на развитие UMA, относится к области «хранилищ личных данных» в стиле управление отношениями с поставщиками. В этой концепции человек может выбрать оператора службы авторизации, которая принимает соединения от множества хостов цифровых ресурсов, ориентированных на потребителя, чтобы предложить панель управления с возможностями управления совместным использованием ресурсов.

Рекомендации

  1. ^ https://kantarainitiative.org/confluence/display/LC/User+Managed+Access
  2. ^ http://kantarainitiative.org/confluence/display/uma/Charter
  3. ^ а б http://kantarainitiative.org/confluence/display/uma/Case+Studies
  4. ^ http://kantarainitiative.org/confluence/display/uma/Home Wiki Рабочей группы UMA
  5. ^ http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes?src=contextnavchildmode Протокол собрания рабочей группы UMA
  6. ^ http://kantarainitiative.org/confluence/display/uma/Home
  7. ^ http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg Интернет-проект: основной протокол динамической регистрации клиентов OAuth 2.0
  8. ^ https://tools.ietf.org/html/rfc7591
  9. ^ http://kantarainitiative.org/confluence/display/uma/UMA+Implementations
  10. ^ http://forgerock.org/openuma/
  11. ^ http://www.gluu.org/open-source/open-source-vs-on-demand/ В архиве 2014-02-09 в Wayback Machine Gluu OSS реализация UMA
  12. ^ https://identos.com/ IDENTOS Inc. Федеративный обмен конфиденциальной информацией (FPX)
  13. ^ https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/tree/uma[постоянная мертвая ссылка]
  14. ^ https://github.com/atricore/node-uma/ Атрикор OSS реализация UMA для Node.js
  15. ^ https://github.com/rohe/pyuma
  16. ^ http://www.keycloak.org/docs/4.0/release_notes/index.html
  17. ^ https://docs.wso2.com/display/IS580/User+Managed+Access
  18. ^ http://kantarainitiative.org/confluence/display/umadev/Home
  19. ^ http://www.gluu.org/gluu-server/access-management/
  20. ^ https://www.jerichosystems.com/company/pr04082015.html
  21. ^ https://www.forgerock.com/platform/user-managed-access/
  22. ^ https://identos.com/products-federated-privacy-exchange-fpe/
  23. ^ https://docs.wso2.com/display/IS580/User+Managed+Access
  24. ^ http://openid.net/wg/heart/

внешняя ссылка