Как авторизовать определенные ресурсы на основе пользователей, которые создали их в REST, используя аннотации

Question

Как авторизовать определенные ресурсы на основе пользователей, которые создали их в REST, используя аннотации

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

public void getOrder(User user) {
   //current code does something like this
   if(order.getCreatedBy().equals(user)) {
     //then proceed. 
}

} `

Я не хочу смешивать эту логику с бизнес-логикой. Вместо этого я ищу что-то вроде этого

@Authorize
public void getOrder(User user) {
   //business logic
}

`Существует несколько методов, но не всем из них потребуется такое разрешение. Может кто-нибудь объяснить мне, как я могу соединить здесь кусочки? На данный момент я не понимаю, как AnnotationProcessor мог бы помочь мне в этом, поскольку он делает свое волшебство во время компиляции. Насколько я понимаю, это поможет мне сгенерировать некоторый код во время компиляции, но я понятия не имею, как использовать этот сгенерированный код. Я просмотрел множество примеров на AnnotationProcessors, но я все еще что-то упускаю. Эти ссылки помогли мне немного понять обработку аннотаций

http://hannesdorfmann.com/annotation-processing/annotationprocessing101 https://equaleyes.com/blog/2017/09/04/annotation-processing/

Даже если я иду с отражениями, где я должен разместить логику отражения? и это контрпродуктивно того, чего я пытаюсь достичь?

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

10

java spring annotations authorization annotation-processing

Источник

user807210 30 июн '18 в 15:59

1 ответ

Решение

Другие вопросы по тегам java spring annotations authorization annotation-processing

user8592142 02 июл '18 в 17:34 2018-07-02 17:34 · Accepted Answer · 2018-07-02 17:34

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

Spring Security

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

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

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

public interface Sample { ... 
@PostAuthorize("hasRole('ROLE_ADMIN')") 
Event getEvent(); }

По сути, Spring Security использует pointcut Аспектно-ориентированного программирования (AOP) во время выполнения, чтобы выполнить перед рекомендацией по методу и бросить o.s.s.access.AccessDeniedException если указанные ограничения безопасности не выполнены.

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

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

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

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

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

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

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

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

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

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

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 Policy Server и предоставляет четыре выражения, которые можно использовать для запроса PDP в качестве части защиты вызова метода

xacmlDecisionPreAuthz, вызывается с @PreAuthorize
xacmlDecisionPostAuthz, вызывается с @PostAuthorize
xacmlDecisionPreFilter, вызывается с @PostFilter
xacmlDecisionPostFilter, вызывается с @PreFilter

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

xacmlDecisionPreAuthz(Collection<String> attributeCats, Collection<String> attributeTypes, Collection<String> attributeIds, ArrayList<Object> attributeValues)
xacmlDecisionPostAuthz(Collection<String> attributeCats, Collection<String> attributeTypes, Collection<String> attributeIds, ArrayList<Object> attributeValues)
xacmlDecisionPreFilter(Collection<String> attributeCats, Collection<String> attributeTypes, Collection<String> attributeIds, ArrayList<Object> attributeValues)
xacmlDecisionPostFilter (Collection<String> attributeCats, Collection<String> attributeTypes, Collection<String> attributeIds, ArrayList<Object> attributeValues)

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