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

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

0 голосов
/ 30 июня 2018

Я не понимаю аннотации 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/

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

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

1 Ответ

0 голосов
/ 02 июля 2018

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

Spring Security

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

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

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

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

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

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

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

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

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

  • личность пользователя, роль, должность, место, отдел, дата рождение ...

  • тип ресурса, местоположение, владелец, стоимость, отдел ...

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

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

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

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

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

Для написания политик доступно 2 основных синтаксиса:

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

ABAC GRAPH

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

  • Точка исполнения политики (PEP): это компонент, который защищает API / приложение, которое вы хотите защитить. ПКП перехватывает поток, анализирует его и отправляет запрос на авторизацию в 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 в качестве части защиты вызова метода

  1. xacmlDecisionPreAuthz, вызывается с @PreAuthorize
  2. xacmlDecisionPostAuthz, вызывается с @PostAuthorize
  3. xacmlDecisionPreFilter, вызывается с @PostFilter
  4. xacmlDecisionPostFilter, вызывается с @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 можно проверить в Википедии .

...