Каков стандартный способ вызова WSO2 ESB в качестве PEP для авторизации XACML с помощью IDP из веб-приложения?

Я пытаюсь работать над авторизацией с помощью XACML.

Я успешно связался с сервером идентификации WSO2 (PDP) из обычного перехватчика Axis2.

Теперь я пытаюсь использовать Wso2 ESB в качестве PEP (упомянутый в примере ниже)

http://wso2.com/library/articles/2010/10/using-xacml-fine-grained-authorization-wso2-platform/

Проблема в том, что я не могу понять, как вызвать ESB из веб-приложения? В приведенной выше ссылке они используют Java-клиент для подключения к ESB, вызывая прокси-сервис ESB с помощью UT Security.

Я не уверен, что данный класс Java в этом примере является правильным способом сделать это. Поскольку для этого требуется знание прокси-сервиса и его политики безопасности.

Также я видел, что если вы хотите абстрагировать свой PDP, чтобы в будущем у вас была открытая возможность заменить его любым другим новым PDP, вам следует использовать стандарт WS-XACML для связи PEP с PEP.

Я еще не нашел ни одного образца на этом,

Есть ли другой стандартный способ добиться этого? Или любой пример, который может быть полезен.


pep wso2 esb pdp xacml
person Budhh    schedule 25.11.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

WSO2 ESB содержит PEP, который называется посредником прав. ESB можно использовать в качестве шлюза безопасности для серверных веб-сервисов. Позвольте мне объяснить некоторые варианты использования ESB. Например, в вашей системе есть некоторые устаревшие службы (или стандартные веб-службы с SOAP и REST). У вас есть требование применить безопасность (аутентификация и авторизация) для этих обратных служб. Таким образом, вы можете использовать эти сервисы с помощью WSO2 ESB и защитить их, не меняя существующую систему. Существующие службы можно легко представить как стандартную веб-службу на основе SOAP (прокси-службы) или REST API с помощью ESB. Затем вы можете использовать безопасность веб-службы (WS-Security, да UT или любую другую) или безопасность API (OAuth/Basic Auth). Вы можете легко управлять аутентификацией с помощью этих подходов. Если вам нужна тонкая авторизация, вы можете использовать посредник прав с WSO2IS.

Хорошо, я не уверен в вашем точном сценарии. Я думаю, у вас есть веб-приложение, и вам нужно вызвать веб-службу. Вы столкнулись с ним, используя ESB для авторизации. Как вы аутентифицировались? У вас может быть какой-то механизм аутентификации, реализованный в веб-приложении? Затем вы можете получить имя пользователя аутентифицированного пользователя, это значение имени пользователя может быть отправлено в ESB в заголовке HTTP (при условии, что веб-приложение и ESB находятся во внутренней сети и с SSL). Внутри потока медитации ESB вы можете извлечь это имя пользователя и установить его в качестве посредника прав (поэтому вам не нужно всегда применять UT). Единственное требование состоит в том, что имя пользователя должно быть доступно для работы посредника прав (это просто, пользователь должен быть аутентифицирован перед авторизацией)

Итак, от веб-приложения до ESB вам не нужен java-клиент, это может быть любой клиент, который может вызывать ваши веб-сервисы.

WS-XACML — это какой-то старый и не популярный профиль. Я не думаю, что лучше использовать его. Стандартный способ связи с PEP-PDP — это профиль REST/JSON. Но WSO2IS до сих пор его не поддерживает. Подробнее см. здесь

person Asela    schedule 30.11.2014
comment
Привет, Асела, Большое спасибо за ответ. Но если вы хотите создать архитектуру на данный момент, что мне следует использовать с продуктом WSO2, поэтому в будущем, когда WSO2 IS обеспечит поддержку JSOn/Rest, мы можем легко заменить ее без особых изменений. - person Budhh; 02.12.2014
comment
Во время входа в систему, когда мы запрашиваем авторизацию. Можем ли мы получить все данные авторизации для пользователя (например, какие ресурсы он может использовать), чтобы для каждого URL-адреса или любого другого ресурса нам не приходилось каждый раз вызывать ESB и сервер идентификации. ? - person Budhh; 02.12.2014
comment
В настоящее время вход через API на Identity Server или ESB (UT) дает логический результат. Есть несколько мест, где мы можем получить атрибуты пользователя при входе в систему (например, токен SAML, OpenId-connect). Я не думаю, что это хорошая идея, чтобы получить все разрешения пользователя во время входа в систему.. это займет больше времени для входа в систему.. и пользователь может не использовать все эти разрешения в этом сеансе.. Я думаю, в некоторых случаях это более эффективно загружать разрешение по запросу. Вы можете использовать несколько профилей решений в XACML, чтобы получить более одного результата. - person Asela; 02.12.2014
comment
xacmlinfo.org/2013/12/06/< /а> - person Asela; 02.12.2014
comment
Ты Рок Асела :) ! Да полностью с вами согласен. Еще раз спасибо. - person Budhh; 02.12.2014
comment
Еще один вопрос: можно ли вместо использования WSO2 ESB в качестве PEP (дополнительного уровня) создать абстрактный уровень PEP в приложении(ях) и напрямую обращаться к службам разрешений сервера WSO2 Identity? Таким образом мы удалим один слой из архитектуры, а также сможем получить максимальную производительность. Какие проблемы могут возникнуть, если мы выберем этот подход? - person Budhh; 03.12.2014