Получать данные из базы данных в соответствии с разрешениями

Question

Я разрабатываю приложение, в котором мне нужно разработать контроль доступа на основе ролей. Я пробовал искать другие ответы, но они предлагают другое решение. Роли динамические c, но на данный момент разрешения имеют c в соответствии с модулями, которые есть в нашем приложении.

Вот мой сценарий.

У меня есть персонал и врач, Персонал подключен к врачу. Таким образом, права доступа: "View Physician", "Edit Physician", "View Appointment", "Edit Appointment", et c.

Персонал также может быть глобальным пользователем и локальным пользователем. Итак, предположим, что если персонал является глобальным пользователем, у него есть разрешения для каждого врача. Если персонал является локальным пользователем, у него есть разрешение на специфику c phyiscian.

Теперь, когда персонал переходит к списку встреч, api должен возвращать данные в соответствии с его разрешением, он должен иметь возможность видеть список назначений только для тех врачей, которые дали ему разрешение "Просмотр встречи">

Используя hasRole и hasAuthority, я могу ограничить весь API, но мне нужно получить данные из базы данных на основе разрешение. Жесткое кодирование разрешения в запросе JPA для каждого попадания в базу данных будет слишком большим.

Итак, я ищу некоторые предложения и помощь по архитектуре или шаблону дизайна для этого.

Answer 1

Ну, ваш вопрос действительно широкий, но я пытаюсь ответить на него ...

Для таких ситуаций весенняя безопасность - лучший способ контролировать доступ к любому API в соответствии с ролью, определенной для пользователь

configure метод класса WebSecurityConfigurerAdapter для настройки пользователя с его конкретными ролями c и сопоставления шаблонов URL в соответствии с ролями

Помните, что класс WebSecurityConfigurerAdapter имеет три версии метода configure , но для этого сценария вам нужны только две версии из них, одна для сопоставления пользователя, т.е. configure (AuthenticationManagerBuilder auth) с их конкретными c ролями и один для сопоставления шаблонов URL-адресов с их конкретными c ролями, т.е. configure (HttpSecurity http)

Таким образом, сопоставив URL-адреса с определенными c ролей, вы можете легко управлять вызовом API в соответствии с ролями пользователей, поэтому для запросов JPA не требуется жесткий код для ролей

Я поделюсь одним примером того, как вы можете сопоставить URL-адрес в соответствии с ролями

protected void configure(HttpSecurity http){
   http.authorizeRequests()
            .antMatchers("/")
            .hasRole("Physician")
            .and()
            .formLogin()

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

Надеюсь, это поможет и побудит вас изучить эту тему.

Answer 2

Исходя из требований вариантов использования разностных запросов, я бы использовал разные стратегии соответственно:

1. Для варианта использования, который возвращает одну запись (например, найти запись по ID ), запрос SQL не должен знать разрешения пользователя. После получения данных из базы данных выполните проверку безопасности на уровне приложения, используя @PostAuthorize.

2. Для варианта использования, который возвращает список записей, которые позволяют пользователю настройте такие вещи, как смещение или ограничение (например, вариант использования разбивки на страницы), запрос SQL знает разрешение пользователя, что означает, что нам нужно добавить необходимые предложения where к запросу SQL на основе разрешения пользователя.

   Основная причина этого в основном связана с производительностью, когда набор данных большой, и трудностями, если это делается на стороне приложения с использованием @PostFilter.

   Например, подумайте о случае, если вам нужно получить 5200-ю - 5400-ю записи, которые пользователю разрешено просматривать, но вам не разрешено добавлять какое-либо предложение where на основе разрешения пользователя на запрос SQL , как бы вы решили эту проблему, если бы все проверки безопасности выполнялись на стороне приложения? Я могу только представить, что коды будут очень беспорядочными и неэффективными, даже если я правильно его реализую ....

3. Для варианта использования, который возвращает список записей, но пользователь не может настроить такие вещи, как смещение или ограничение, я бы использовал ту же стратегию, что и (1), но на этот раз использовал @PostFitler.

Так что, если нет особых причин, таких как Как и (2), общая цель состоит в том, чтобы рассматривать logi c безопасности как сквозную проблему, насколько это возможно, чтобы коды logi c основного домена не знали о его существовании. Коды безопасности должны быть централизованы в одном месте / package / modules et c, но не разбросаны по всем кодам. По сути, это означает, что мы используем технику АОП, предоставляемую Spring security, для выполнения некоторых кодов проверки безопасности для возвращаемых объектов после выполнения метода запроса fini sh.

Answer 3

Один из наиболее часто используемых подходов - это создание групп пользователей и их привязка к соответствующим пользователям. Затем вы можете разработать структуру для ограничений, которая будет иметь функции для создания, обновления, удаления, включения, отключения и т. Д. c. ограничения. Когда у вас будет эта структура, вы можете применить ограничения к своим запросам JPA. Один из примеров, который вы можете проверить, - это это . Обратите внимание, что эта платформа использует собственный язык запросов, похожий на HQL , который называется гибким поисковым запросом. Это даст вам четкое представление о том, как начать с собственной системы ограничений.