Как сделать контроль доступа/авторизацию для конкретного компонента с помощью JAAS?

Мне нравится разрабатывать «бизнес»-компоненты независимо от приложения. Таким образом, каждый компонент представляет собой отдельный проект с довольно специфическими обязанностями, границами и зависимостями.

Пример: компонент закладки. Этот компонент отвечает за создание, хранение, удаление и запрос закладок.

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

  • Это сбивает меня с толку. С одной стороны, речь идет об управлении доступом и авторизации, которые являются сквозными проблемами, потому что они нужны многим компонентам.
  • С другой стороны, это ограничение тесно связано с закладками. Следовательно, это специфично для этого компонента. Может быть, это что-то вроде бизнес-правила.

Во всяком случае, я не уверен, какая часть приложения отвечает за это. Я уже реализовал аутентификацию с помощью JAAS. Так что было бы неплохо, если бы я мог использовать JAAS для контроля доступа и авторизации, но я не уверен, что это адекватное решение.

Учебники JAAS говорят, что я могу осуществлять авторизацию/управление доступом в зависимости от того, кто запускает код, и я могу создавать разрешения для своего приложения (или компонента в данном случае). С другой стороны, это частично работает с файлом политики, но я не хочу предоставлять доступ каждому пользователю через файл. Информация о том, какие закладки доступны пользователю, хранится в моей базе данных.

  1. Способен ли JAAS решить этот вид контроля доступа/авторизации, и если да, то как?
  2. Есть ли шаблоны, которые могут мне помочь?

java security authorization access-control jaas
person user573215    schedule 05.07.2013    source источник
comment
Возможно, у вас должна быть таблица в вашей базе данных, в которой вы связываете пользователей с их закладками и выбираете и показываете только те, которые есть у конкретного пользователя.   -  person jsedano    schedule 05.07.2013
comment
Да, но я рассматриваю возможность обернуть компонент REST API. Таким образом, кто-то может попытаться получить доступ к ресурсу, который ему не принадлежит, изменив идентификаторы в URL-адресе. Я также мог бы сделать запрос, который возвращает закладку, только если она принадлежит текущему пользователю. Но это может изменить API компонента. Также я думаю, что когда ресурс существует, но доступ запрещен, я должен сказать, что доступ запрещен, а ресурс не существует.   -  person user573215    schedule 05.07.2013
comment
Когда пользователь пытается получить объект, на который у него нет разрешения, правильным ответом будет 404. В противном случае вы предоставляете пользователю информацию, которую он не имеет права знать (о том, что запрошенный ресурс действительно существует).   -  person kgilpin    schedule 18.10.2013

Ответы (1)


arrow_upward
1
arrow_downward

Вы должны хранить владельца каждой закладки в таблице. Вы должны требовать, чтобы каждый запрос был аутентифицирован. Затем вы должны возвращать только те записи, которые принадлежат аутентифицированному пользователю.

Если вы хотите, чтобы пользователи могли делиться друг с другом, это становится намного сложнее.

person kgilpin    schedule 18.10.2013
comment
Да, я думаю, что это путь. Это больше похоже на проблему с доменом. Я думаю, что моделирование домена для многопользовательского доступа не так сложно. Ключевым следствием этой стратегии является (с моей точки зрения): API должен быть разработан или изменен, чтобы идти по этому пути. Таким образом, вместо того, чтобы иметь что-то вроде: BookmarkComponent.getBookmark(long bookmarkId), он становится BookmarkComponent.getBookmark(User user, long bookmarkId) или что-то подобное. - person user573215; 18.10.2013