Авторизация на уровне ресурсов в службе RESTful

Пусть / users / {id} будет URL-адресом ресурса в службе RESTful.

Базовая аутентификация включена, и только аутентифицированным пользователям разрешен доступ к URL.

Пример сценария:

Пользователь_1 и Пользователь_2 - аутентифицированные пользователи с userId 1 и 2. Поскольку оба аутентифицированы, они оба имеют доступ к

• / users / 1
• / users / 2

. Ожидается, что User_1 должен иметь доступ к / users. / 1 , а не в / users / 2 или другой идентификатор пользователя

Вопрос: Как выполнить авторизацию на уровне ресурсов в службах RESTful?

Примечание: я реализую RESTful с использованием Jax-RS (с реализацией Apache CXF), полезно, если вы могли бы объяснить с помощью Jax-RS.

-Barath

Изменить:

Как упомянул Донал, я ищу авторизацию не на основе ролей, а авторизацию на уровне ресурсов.

В качестве примера допустим, что / users / {id} / photos / {photoId} будет другим URL-адресом ресурса. Пользователь_1 должен иметь доступ только к принадлежащим ему фотографиям. Если photoId равняется 2, принадлежащему пользователю_2, мы должны предоставить код ошибки http_404 для пользователя_1 при запросе запроса / users / 1 / photos / 2. [Поскольку User_1 также является аутентифицированным пользователем, он может вызвать / users / 2 ] / photos / 2, поэтому мы должны идентифицировать идентификатор пользователя на основе параметров аутентификации, а не по URL-адресу ресурса]

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

Вместо этого из SELECT * FROM PHOTO_TBL WHERE PHOTO_ID = 2;

используйте SELECT * FROM PHOTO_TBL, USER_TBL WHERE PHOTO_ID = 2 AND USER_ID = 1 AND USER_ID = PHOTO_ID;

данные доставляют данные с этими ресурсами;

конкретному пользователю. [Должен быть механизм, предотвращающий изменение уникального идентификатора на стороне клиента, который используется для принятия решения об авторизации (в данном случае userId), поскольку все запросы являются БЕСПРОВОДНЫМИ запросами]

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

Мне еще предстоит изучить безопасность Spring и то, как ее можно использовать в этом случае использования.