Как работать с ролями с заданной областью, когда в XACML можно активировать несколько ролей

Это большой вопрос. Мы называем эту проблему проблемой атрибутов отношений. По сути, у пользователя есть роль в заданном контексте или области действия, как вы это называете.

Если бы я прочитал роль пользователя из базы данных только на основе личности пользователя, я бы вернул список ролей независимо от области действия, например. редактор, издатель, рецензент...

Это может привести к риску того, что я могу отредактировать сообщение, выходящее за рамки, для которых у меня есть правильная роль.

Есть несколько способов решить эту проблему. Один из способов — определить более строгие сопоставления в информационной точке политики.

Использование информационных точек политики

Предположим, что запрос XACML говорит: «Может ли Алиса редактировать сообщение 123?». В вашей политике будет указано (в синтаксисе ALFA):

policy editPost{
    target clause resourceType=="post" and actionId=="edit"
    apply firstApplicable
    rule allowEditors{
        target clause userRole=="editor"
        permit
    }
}

Понятие области непосредственно не отображается в политике. Базовое сопоставление с источником атрибутов будет следующим:

• map userRole to the field role of the table usersRoleAssignment using SELECT role FROM usersRoleAssignment WHERE uid=? AND scope=?
  • uid would be mapped to the user identity that came in the XACML request.
  • Scope будет атрибутом ресурса, который также будет отображаться в PIP следующим образом.
• map scope to the field scope of the table posts using SELECT scope FROM posts WHERE pid=?
  • pid would be mapped to the identifier of the post in question. That also came in the XACML request.

Это означает, что ваш атрибут userRole действительно должен называться scopedUserRole. Моделирование, которое я привел, является лишь одним из примеров. Есть несколько других способов моделирования с тем же эффектом. В любом случае, вся тяжелая работа происходит внутри PIP. Главный недостаток заключается в том, что вы теряете видимость семантики вашей логики авторизации.

Использование значений атрибутов и функций

Другой способ добиться аналогичного результата — сохранить связь между областью действия и ролью в самом значении. Это то, на что вы намекаете в своем вопросе.

Вы можете использовать строковые функции, такие как string-starts-with, string-ends-with или string-contains, чтобы достичь того, что вас интересует. Существует также функция сопоставления строк, которую вы можете использовать.

Подробности о функциях можно найти в Спецификация XACML 3.0.

Если функций в XACML недостаточно, вы можете:

• реализовать свой собственный
• реализовать PIP, который может обрабатывать значения ваших атрибутов и создавать новые. Подробнее о PIP здесь.

Создание нового типа данных с именем tuple

Проблема с XACML заключается в том, что он сглаживает отношения. Использование нового типа данных с несколькими частями, то есть Tuple, решит проблему. Это потребует пользовательского кодирования и довольно большой работы.

Использование содержимого XML внутри запроса XACML

Если вся информация исходит из запроса XACML, то ее можно выразить в виде полезной нагрузки XML как части элемента <Content/> внутри запроса XACML. Затем вы можете использовать селекторы атрибутов и XPath для получения того, что вас интересует.

ХТН. Проверьте как мой блог, так и Блог Axiomatics для получения дополнительных советов.