Кэширование данных авторизации XACML на уровне приложения из WSO2 IDP

Мы работаем над приложением, в котором мы будем создавать и хранить политики XACML на сервере WSO2 для авторизации.

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

Один из способов справиться с этим - когда пользователь пытается войти в систему, в это время он получает все свои данные от IDP, чтобы мы могли кэшировать их на уровне приложения, и нам не нужно обращаться к wso2 idp каждый раз, когда пользователь выполняет какие-либо действия. действие. Это может привести к медленному входу в систему, но другие приложения будут работать быстрее.

Мы просто хотели подтвердить, что это правильный подход? Есть ли какие-либо проблемы с этим дизайном или есть ли лучший способ, который мы можем использовать?


person Budhh    schedule 20.01.2015    source источник


Ответы (1)


Я думаю, что это неправильный подход, особенно когда мы говорим об управлении доступом на основе атрибутов (ABAC) и когда атрибуты требуют частого изменения.

Кроме того, когда вы выполняете оценку политики, лучше позволить PIP извлекать необходимые атрибуты вместо того, чтобы приложение отправляло все атрибуты, и, кроме того, вы можете использовать кэширование на стороне WSO2 IS также для решения или атрибутов политики XACML.

Кроме того, для повышения производительности вы можете реализовать свой PEP на основе экономии. Мы сделали такую ​​же реализацию и провели успешное нагрузочное тестирование для одного из наиболее часто используемых приложений.

Я бы не рекомендовал кэширование на стороне приложения по следующим причинам:

  1. Вы должны сделать круговой обход для оценки политики, даже если вы кэшируете атрибуты локально в приложении.

  2. Кэширование атрибутов локально внутри приложения не принесет пользы, если та же политика будет использоваться другими приложениями в будущем.

  3. Рекомендуется разрешить PIP извлекать требуемые атрибуты на стороне WSO2, поскольку это упростит интеграцию нового приложения, когда вам не нужно беспокоиться о получении атрибутов для всех новых интеграций приложений.

  4. Кэширование может выполняться централизованно на сервере WSO2 IS вместо применения кэширования на уровне каждого приложения.

P.S. - Это мои личные взгляды и мнения, и они могут не быть идеальными или наилучшим образом соответствовать различным требованиям и потребностям бизнеса.

person Yusuf Khan    schedule 22.01.2015
comment
Привет Юсуф! Спасибо большое за ответ!! Я хотел бы узнать больше о вашей реализации, чтобы мы могли извлечь максимальную пользу из технологий с открытым исходным кодом. Не могли бы вы поделиться своей электронной почтой или контактами, чтобы мы могли поговорить? Еще раз спасибо за ответ. - person Budhh; 22.01.2015
comment
Привет, Будда, я доступен по адресу [email protected]. - person Yusuf Khan; 22.01.2015
comment
Я обнаружил, что кэширование WSO2 IS для XACML довольно раздражает. Если я включу кэширование с тайм-аутом 60 секунд, это никогда не сделает кэширование недействительным, а оценка политики XACML начнет вести себя ненормально, например, правила, которые должны фактически оцениваться как Разрешить, оценивать как Запретить или иногда журналы просто говорят, что ОШИБКА {org.wso2.balana. finder.AttributeFinder} — не удалось разрешить какие-либо значения для abcd.com/my-custom-id - person swapy; 22.12.2015