Авторизация ресурсов на основе того, кто их создал

Мой коллега указал мне на интересный вопрос о StackOverflow и предположил, что мне будет полезно ответить на него из-за моего опыта работы со Spring.

Вопрос заключался в том, « Как авторизовать определенные ресурсы на основе пользователей, которые создали их в REST, используя аннотации ».

Суть этого заключается в следующем:

Я пытаюсь создать аннотацию с именем @Authorize и использовать ее в методах, для которых требуется авторизация пользователя, чтобы выполнить какое-либо действие (на этом этапе пользователь уже аутентифицирован). например. У меня есть служба заказа с getOrder() . Я хочу, чтобы только пользователь, который создал этот заказ, получил к нему доступ.

Мой ответ на StackOverflow

Чтобы реализовать средства управления авторизацией для методов в Java, я настоятельно рекомендую Spring Security с реализацией расширяемого языка разметки контроля доступа (XACML), которая имеет API-интерфейс Spring Security.

Spring Security

Spring Security предоставляет два основных средства защиты доступа к методам:

• Предварительная авторизация : это позволяет проверять определенные условия / ограничения перед выполнением метода. Неспособность проверить эти условия приведет к невозможности вызова метода.
• Поставторизация : это позволяет проверять определенные условия / ограничения после возврата метода. Это используется реже, чем проверка перед авторизацией, но может использоваться для обеспечения дополнительной безопасности вокруг сложных взаимосвязанных методов бизнес-уровня, особенно вокруг ограничений, связанных с объектом, возвращаемым методом.

Скажем, например, что одно из правил управления доступом заключается в том, что пользователь имеет полномочия ROLE_ADMIN, прежде чем он сможет вызвать метод getEvents (). Способ сделать это в среде Spring Security — использовать аннотацию PreAuthorize, как показано ниже:

В сущности, Spring Security использует ossaccess.AccessDeniedException AOP, выполняемый во время выполнения, для выполнения перед ossaccess.AccessDeniedException о методе и создания ossaccess.AccessDeniedException если указанные ограничения безопасности не выполнены.

Более подробную информацию о безопасности уровня безопасности Spring можно найти в разделе 27.3 этой документации .

Расширяемый язык разметки контроля доступа (XACML) — язык политики для ABAC

Spring Security делает большую работу по внедрению управления доступом с помощью управления доступом на основе выражений, но управление доступом на основе атрибутов (ABAC) обеспечивает более точный контроль доступа и рекомендуется Национальным институтом стандартов и технологий.

Чтобы устранить ограничения управления доступом на основе ролей (RBAC), NIST разработал новую модель, названную ABAC (управление доступом на основе атрибутов). В ABAC теперь вы можете использовать больше метаданных / параметров. Вы можете, например, рассмотреть:

• личность пользователя, роль, должность, место, отдел, дата рождения…
• тип ресурса, местоположение, владелец, стоимость, отдел…
• контекстная информация, например, время суток, когда пользователь пытается выполнить действие с ресурсом

Все это называется атрибутами. Атрибуты являются основой ABAC, отсюда и название. Вы можете собрать эти атрибуты в политику. Политика немного похожа на секретный соус ABAC. Политики могут предоставлять и запрещать доступ. Например:

• Сотрудник может просматривать запись, если сотрудник и запись находятся в одном регионе
• Запретить доступ к чтению записей между 5 вечера и 8 утра.

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

• разделение обязанностей
• временные ограничения (см. выше)
• управление доступом на основе отношений (см. выше)
• правила делегирования делегируют Бобу доступ к документу Алисы.

Существует два основных синтаксиса, доступных для написания политик:

• Сокращенный язык для авторизации (ALFA), основанный на XACML
• расширяемый язык разметки контроля доступа (XACML)

ABAC также поставляется с архитектурой, определяющей, как политики будут оцениваться и применяться.

Архитектура содержит следующие компоненты:

• Точка реализации политики (PEP): это компонент, который защищает API / приложение, которое вы хотите защитить. PEP перехватывает поток, анализирует его и отправляет запрос авторизации в PDP (см. Ниже). Затем он получает решение (Permit / Deny), которое он применяет.
• Точка принятия решения о политике (PDP) получает запрос на авторизацию (например, может ли Алиса просмотреть запись # 123?) и сравнивает его с набором политик, с которыми она была настроена. В конечном итоге он принимает решение, которое отправляет обратно в PEP. Во время процесса оценки PDP могут потребоваться дополнительные метаданные, например, должность пользователя. С этой целью он может обратиться к пунктам информации о политике (PIP)
• Информационная точка политики (PIP) — это интерфейс между PDP и базовыми источниками данных, например, LDAP, базой данных, службой REST, которые содержат метаданные о пользователях, ресурсах или других. Вы можете использовать PIP для получения информации, которая может понадобиться PDP во время выполнения, например, оценка риска, местоположение записи или другое.

Реализации XACML

Полное раскрытие информации. Я работаю в Техническом комитете XACML и работаю для Axiomatics , поставщика динамической авторизации, реализующей XACML.

Axiomatics предоставляет Spring Security SDK для своего сервера политики Axiomatics и предоставляет четыре выражения, которые можно использовать для запроса PDP в качестве части защиты вызова метода

1. xacmlDecisionPreAuthz, @PreAuthorize с помощью @PreAuthorize
2. xacmlDecisionPostAuthz, @PostAuthorize с помощью @PostAuthorize
3. xacmlDecisionPreFilter, @PostFilter с помощью @PostFilter
4. xacmlDecisionPostFilter, @PreFilter с помощью @PreFilter

Точные подписи для этих методов следующие:

1. xacmlDecisionPreAuthz(Collection<String> attributeCats,
Collection<String> attributeTypes, Collection<String> attributeIds,
ArrayList<Object> attributeValues)
2. xacmlDecisionPostAuthz(Collection<String> attributeCats,
Collection<String> attributeTypes, Collection<String> attributeIds,
ArrayList<Object> attributeValues)
3. xacmlDecisionPreFilter(Collection<String> attributeCats, Collection<String>
attributeTypes, Collection<String> attributeIds, ArrayList<Object>
attributeValues)
4. xacmlDecisionPostFilter (Collection<String>
attributeCats, Collection<String> attributeTypes, Collection<String>
attributeIds, ArrayList<Object> attributeValues)

Полный список реализаций XACML вы можете проверить в Wikipedia .