Конечная точка привилегий для интерфейса пользователя в приложении REST

Question

У меня есть приложение Spring Boot с бэкэндом REST (Spring MVC) и чистым интерфейсом JavaScript. Недавно мы включили безопасность с помощью весенней безопасности, и мы обсуждаем . Как сообщить UI, какие у пользователей привилегий, т. Е. какие элементы управления должны быть представлены пользователю в соответствии с ее ролями.

За то, что я пробовал:

• Мы можем только разоблачить и конечную точку со списком органов (ролей), и пусть дело UI с ним. Это просто для бэкэнд, но затем в нашем бэкэнд мы поддерживаем сопоставления ROLE -> Allowed URLs, и то же самое произойдет с интерфейсом. В какой-то момент они будут расходиться (я уверен!), И мы покажем элемент управления пользовательского интерфейса, который при использовании - приведет к 403 - Unauthorized.

• Сделать его URL-ориентированным, потому что это то, что REST: иметь конечную точку (скажем: /security/privileges?url=...&method=...), которая отвечает на вопрос: Могу ли я получить доступ к URL-адресу x через метод запроса y? Это позволит пользовательскому интерфейсу ориентироваться только на URL-адреса, которые, по-видимому, приятнее. Но выглядит как кошмар/невозможно для внутреннего интерфейса (особенно, когда вы объединяете веб безопасность через фильтры безопасности на уровне методы через @Pre/@Post аннотаций

Вопросы:.

1. я ищу по наилучшей практике, как подход, связывающий пользовательские привилегии с бэкэндом REST с пользовательским интерфейсом. Должен ли он быть URL-ориентированным или просто отправлять список ролей?

2. Если кто-то прошел через URL-ориентированный подход, то есть способ, как изучить метод меток контроллера ds для того, будет ли проходить проверки безопасности? Обратите внимание, что WebInvocationPrivilegeEvaluator не достаточно, так как он не учитывает безопасность уровня метода.

EDIT: Чтобы прояснить мои сомнения по поводу подхода с отправкой списка ролей. Если я это сделаю, то:

MVC контроллер:

@PreAuthorize("hasAnyRole('ADMIN', 'EDITOR'") 
@RequestMapping("/editStuff") 
public void editStuff(...) { 
    ... 
} 

JS:

if (hasRole('ADMIN') || hasRole('EDITOR')) { 
    showEditControllWhichOnClickCalls('/editStuff'); 
} 

Там четко дублируется чек за то, что какой-либо из ролей РЕДАКЦИЮ или ADMIN. Если с другой стороны, сделать в JS (и в идеале сохранить URL как константа в одном месте), он выглядит менее связан со мной:

if (doIHaveAccessTo('/editStuff', 'POST')) { 
    showEditControllWhichOnClickCalls('/editStuff'); 
} 

Answer 1

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

Бэкэнд: Вы можете использовать любую систему единого входа, чтобы ваш пользователь прошел аутентификацию после успешного входа в систему. Сеансы, памятка-токен, не имеет значения. Он просто связывает все ваши запросы с объектом аутентификации в SecurityContext и позволяет вам управлять правом доступа к различным службам.О токенов вы можете прочитать здесь: http://docs.spring.io/spring-security/site/docs/3.0.x/reference/remember-me.html

Задавайте любые конкретные вопросы, я постараюсь ответить