Доступ, управляемый пользователем - 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] ttps://kantarainitiative.org/confluence/display/LC/User+Managed+Access

[2] ttp://kantarainitiative.org/confluence/display/uma/Charter

[ki_case-3] а ^б http://kantarainitiative.org/confluence/display/uma/Case+Studies

[4] ttp://kantarainitiative.org/confluence/display/uma/Home Wiki Рабочей группы UMA

[5] ttp://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes?src=contextnavchildmode Протокол собрания рабочей группы UMA

[6] ttp://kantarainitiative.org/confluence/display/uma/Home

[7] ttp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg Интернет-проект: основной протокол динамической регистрации клиентов OAuth 2.0

[8] ttps://tools.ietf.org/html/rfc7591

[9] ttp://kantarainitiative.org/confluence/display/uma/UMA+Implementations

[10] ttp://forgerock.org/openuma/

[11] ttp://www.gluu.org/open-source/open-source-vs-on-demand/ В архиве 2014-02-09 в Wayback Machine Gluu OSS реализация UMA

[12] ttps://identos.com/ IDENTOS Inc. Федеративный обмен конфиденциальной информацией (FPX)

[13] ttps://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/tree/uma^{[постоянная мертвая ссылка ]}

[14] ttps://github.com/atricore/node-uma/ Атрикор OSS реализация UMA для Node.js

[15] ttps://github.com/rohe/pyuma

[16] ttp://www.keycloak.org/docs/4.0/release_notes/index.html

[17] ttps://docs.wso2.com/display/IS580/User+Managed+Access

[18] ttp://kantarainitiative.org/confluence/display/umadev/Home

[19] ttp://www.gluu.org/gluu-server/access-management/

[20] ttps://www.jerichosystems.com/company/pr04082015.html

[21] ttps://www.forgerock.com/platform/user-managed-access/

[22] ttps://identos.com/products-federated-privacy-exchange-fpe/

[23] ttps://docs.wso2.com/display/IS580/User+Managed+Access

[24] ttp://openid.net/wg/heart/

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]