В этой записи блога давайте посмотрим, как мы можем реализовать XACML для авторизации API. Я желаю, чтобы вы были знакомы с OAuth 2.0 и давайте сразу перейдем к диаграмме
- Токен доступа OAuth предоставляется приложению с сервера авторизации OAuth. Приложение может использовать токен доступа для доступа к ресурсам API в шлюзе.
- Когда запрос получен с помощью токена доступа, API-шлюз может проверить токен доступа OAuth, вызвав сервер авторизации OAuth.
- Если токен доступа успешно подтвержден, API-шлюз может переслать запрос в конечный веб-сервис нужного банка.
Итак, если мы хотим обеспечить детальную авторизацию для API, лучшим способом является использование подхода авторизации на основе XACML .
Где должно произойти разрешение
Согласно диаграмме выше, вы можете видеть, что авторизация XACML может быть выполнена в двух местах.
1. Внутри сервера авторизации OAuth . После того как сервер авторизации OAuth проверит токен доступа OAuth, он может создать запрос XACML.
Запрос XACML может содержать следующее
- Имя конечного пользователя
- Имя приложения или идентификатор
- API, который собирается получить доступ
- HTTP глагол
- Область действия токена
В большинстве случаев API Gateway хочет знать, может ли этот токен доступа (конечный пользователь) или приложение получить доступ к данному API или нет. Поэтому запрос XACML может быть создан с помощью;
- Dnd имя пользователя (или идентификатор приложения / ключ) в качестве темы XACML
- Имя и версия API как ресурс XACML
- HTTP-глагол как действие XACML
Запрос XACML отправляется PDP для принятия решения об авторизации
2. В API Gateway . После того, как решение о проверке получено на шлюз, оно может дополнительно подтвердить авторизацию до того, как запрос будет переадресован на бэкэнд-сервис.
Запрос XACML может содержать соответствующие вещи, которые упомянуты выше. Он может быть сгенерирован на шлюзе API и может быть отправлен на PDP для принятия решения об авторизации.
Я думаю, что лучшее место для авторизации (для сохранения PEP ) — это сервер авторизации OAuth, а не шлюз API.
- При правильной разработке, шлюз API находится в DMZ. Сервер авторизации OAuth и PDP будут находиться в локальной сети, поскольку пользовательское хранилище Enterprise должно быть им открыто. Следовательно, требуется только один вызов службы от шлюза API к локальной сети. Если XACML PEP был в шлюзе API, может быть два запроса к локальной сети.
- В основном сервер авторизации OAuth и PDP могут быть встроены в сервер. Это создало бы хороший выигрыш в производительности, поскольку могло бы избежать вызова службы для PEP-PDP. Но API-шлюз и PDP не могут быть встроены, потому что API-шлюз обычно находится в DMZ, и пользовательское хранилище Enterprise не может быть ему открыто. Также API-шлюз полностью оптимизирован, чтобы выполнять посредничество и обработку сообщений. Следовательно, может быть трудно правильно сбалансировать использование ресурсов, если PDP находится на одном и том же сервере.
Авторизация API с помощью WSO2 Identity Server и API Manager
Identity Server может работать с сервером авторизации OAuth . Также это хорошо известный XACML PDP .
API Manager — это полностью API-решение, состоящее из API Gateway, издателя, магазина и менеджера ключей . Более подробную информацию об архитектуре можно найти здесь . В диспетчере API диспетчер ключей действует как сервер авторизации OAuth, и им также можно заменить Identity Server.
Identity Server и API Manager предоставляют расширяемую архитектуру, в которую можно подключить точку расширения. Поэтому мы можем расширить поддержку авторизации на основе XACML . Давайте посмотрим, как мы можем это сделать.
Мы предполагаем, что механизм XACML был встроен в сервер авторизации OAuth. Вы можете использовать Key Manager в качестве Identity Server или установить функции XACML в API Manager. Более подробную информацию вы найдете здесь.
1. Давайте расширим обработчик области по умолчанию для компонента OAuth2 и реализуем новый обработчик области, который поддерживает вызов XACML PDP. Пожалуйста, найдите проект здесь . Вы можете пройти проект и изменить его по своему желанию.
2. Развертывание обработчика настраиваемой области путем копирования org.xacmlinfo.xacml.oauth.scope-1.0.0.jar файл OSGI расслоение в к <Home> / хранилище / компонентов / dropins каталог
3. Зарегистрируйте пользовательский обработчик области, обновив следующий элемент в элементе <OAuth> в файле identity.xml, который можно найти в <HOME> / repository / conf
<OAuthScopeValidator class="org.xacmlinfo.xacml.oauth.scope.XACMLScopeValidator"/>
Если вам нужно реализовать обработчик области для вызова удаленного PDP XACML, вам нужно изменить обработчик области с помощью клиента с разрешениями, который вызывает службу прав. Вы можете найти более подробную информацию о Правах на услуги здесь .
Давайте создадим образец XACML с OAuth в следующем сообщении в блоге…!