Блог

Главная - Вопросы по программированию - Защита прокси-службы REST в WSO2ESB

Защита прокси-службы REST в WSO2ESB

#wso2 #wso2esb

#wso2 #wso2-esb

Вопрос:

Используя WSO2ESB, я пытаюсь добавить безопасность и предоставить незащищенные REST API, работающие в WSO2DSS. В принципе, я хочу сохранить имя пользователя / пароль в хранилище пользователей в ESB с ролями и предоставить доступ к API на основе ролей. Я понимаю, что клиент должен отправить токен авторизации в http-заголовке ‘Authorization’. Итак, как я могу настроить ESB для сравнения этого токена с пользовательским хранилищем и разрешить доступ только к определенным службам? Я использую ESB, потому что в ответе необходимо выполнить некоторые преобразования перед отправкой его клиенту. Любые общие идеи помогли бы.

Спасибо

Ответ №1:

Вы можете создать API в ESB для прокси-сервера вашего beckend REST API. Затем вы можете написать обработчик для авторизации вызовов API. Смотрите этот пост в блоге.

Кстати, разве вы не ознакомились с WSO2 API Manager? Для управления вашими API это больше подходит, чем ESB. Если у вас есть сложные преобразования, вы можете использовать ESB (поддерживается APIM). Если ваша логика посредничества не сложна, вы можете сделать это внутри самого APIM. Смотрите Этот документ для получения дополнительной информации.

Если вам нужна более детализированная возможность авторизации, вы можете использовать посредник предоставления прав с политиками XACML. Смотрите эту статью для получения дополнительной информации.

Комментарии:

1. Спасибо, Бхатия. Я сделал нечто похожее на блог, о котором вы упомянули. У меня всего несколько посредников в ESB, но мне нужно манипулировать XML-сообщениями и кодами возврата HTTP. Итак, думаю, ESB — единственный вариант.

Ответ №2:

Я могу использовать базовую аутентификацию HTTP с помощьюhttp://suhan-opensource.blogspot.co.uk/2016/08/wso2-dss-secure-data-service-using.html.

Пожалуйста, обратите внимание, что последняя версия WSO2ESB или DSS не позволяет добавлять защиту непосредственно из консоли управления. Либо используйте Developer studio, либо отредактируйте XML-источник напрямую.

Комментарии:

1. Отлично, в предыдущей версии были проблемы с сопоставлением ролей из файла политики 🙂 Мы оба узнали кое-что новое:D

Ответ №3:

Существует несколько подходов.

Прямая авторизация: Самый простой способ — включить безопасность службы (в консоли управления), выбрать «маркер имени пользователя», а затем выбрать разрешенные роли. Таким образом, клиент должен отправить либо:

  1. используйте базовую аутентификацию (Авторизация: Basic
  2. отправьте заголовок WS-Security с UsernameToken и отметкой времени

Пусть все будет просто. Для большинства вариантов использования этот подход достаточно хорош.

Делегированная авторизация: наличие стороннего PDP (службы, которая сообщает, что пользователь может получить доступ к вашей службе).

  1. Для точной авторизации (например, только определенная роль в определенные часы суток и т.д.) Вы можете использовать XACML EntitlementService (из WSO2IS или AM) для авторизации вызова.

  2. Для прошедших проверку подлинности пользователей из других систем простейшим подходом является использование токена на предъявителя, который вы можете проверить (например, используя API, управляемый, как уже упоминалось в других ответах)

Комментарии:

1. Спасибо. Я смог использовать базовую аутентификацию HTTP. Мне пришлось напрямую редактировать конфигурацию XML, хотя, как упоминалось в suhan-opensource.blogspot.co.uk/2016/08 /… .