Безопасность на уровне строк в JAX-RS с использованием MS SQL

Моя команда разрабатывает API RESTful в JAX-RS, и нам нужно ограничить доступность определенных строк в нашей базе данных на основе идентификатора аутентифицированного «Оператора» (наше слово для пользователя). Другими словами, Оператор должен иметь доступ только к объектам, находящимся под его юрисдикцией. В начале каждого запроса мы завершаем аутентификацию Оператора, делающего запрос, что позволяет нам предоставлять функции безопасности на основе роли и идентификатора оператора.

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

Обратите внимание: мы не используем Spring и не планируем использовать Spring Security в нашем проекте.

Мы придумали несколько потенциальных решений, но мы не уверены, что лучше. Также очень возможно, что есть решение, которое мы не рассматривали; На данный момент я открыт для всего. Вот что у нас есть до сих пор:

  1. Реализация уровня базы данных (как обсуждалось в этой статье ). Предположительно, это предполагает использование контекста безопасности запроса для передачи идентификатора оператора в базу данных по каждому запросу. Я не совсем понимаю особенности реализации этого подхода, поэтому, если это лучший способ выполнить безопасность на уровне строк, я был бы признателен за дальнейшие советы. Например, имеет смысл, как это будет работать для поиска объектов, но как мы будем изменять разрешения на уровне строк для вновь созданных или обновленных объектов?
  2. JPA (как обсуждалось в этой статье с 2008 года). Это может быть связано с созданием параметризованного фильтра Hibernate, в который мы будем передавать идентификатор оператора, делающего запрос. Я никогда не использовал фильтры Hibernate, поэтому очень возможно, что эта идея вне базы.
  3. Внедрение уровня фасада . Мы на самом деле дали эту идею достойную мысль, так как до недавнего времени нам не было известно о вариантах (1) и (2). Это предполагает выполнение соединений между нашими таблицами для построения предиката API Criteria, который ограничивал бы наши запросы только включением тех объектов, которые доступны данному оператору. Это, по сути, «ручной» подход, насколько я понимаю, и кажется далеким от идеала.

Было бы здорово, если бы кто-нибудь, знакомый с JAX-RS и / или безопасностью базы данных, мог помочь понять это.

Вот наш технический стек для проекта (по крайней мере, насколько это актуально для этой проблемы):

  • База данных : MS SQL
  • Поставщик JPA : спящий режим
  • Реализация JAX-RS : RESTEasy

java,sql-server,hibernate,authorization,jax-rs,

4

Ответов: 1


1

Используйте SQL Server 2016: Row Level Security (RLS) - концепция, обеспечивающая безопасность на уровне строк в уровне базы данных, а не на уровне приложения. RLS выполняется с помощью функции и новой функции политики безопасности, которая развертывается с SQL Server 2016. (Если вам действительно нужна безопасность на уровне строк)

Java, SQL-сервер, спящий режим, разрешение, JAX-RS,
Похожие вопросы
Яндекс.Метрика