Рекомендации по защите ресурсов Keycloak - PullRequest
1 голос
/ 14 июня 2019

Я пишу веб-сервисы в Spring Boot и использую Keycloak для защиты приложения.Приложение предоставит API для управления ресторанами.

В Keycloak У меня две роли: admin и manager .

Пользователь с ролью admin может посещать рестораны CRUD.В одной и той же компании есть несколько ресторанов, и в каждом ресторане есть менеджер. Я хочу, чтобы пользователи с ролью менеджера могли редактировать только свой ресторан ( ресторан, которым они управляют ).

В соответствии с моим пониманием документации Keycloak, я должен использовать Ресурс с Разрешение , но они заявили, что:

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

Для этого мне нужно создать ресурс, подобный этому /api/restaurants/12345, но дело в том, что я не могу жестко закодировать идентификатор, подобныйthis.

Пока я защищал свою конечную точку следующим образом при весенней загрузке:

http
  .authorizeRequests()
  .mvcMatchers(HttpMethod.PUT, "/api/restaurants/*").hasAnyRole("ADMIN", "MANAGER")
  .anyRequest().permitAll();

Это означает, что любой менеджер из любого ресторана может редактировать другой ресторан.Я хочу ограничить это только своим рестораном ( ресторан, которым они управляют ). Как я могу сделать это в Keycloak , если это вообще возможно?

1 Ответ

0 голосов
/ 14 июня 2019

Что вы ищете, это Управляемый пользователем доступ (UMA) . Позволяет управлять разрешением доступа для каждого ресурса.

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

Лучшим введением, вероятно, является пример Photoz . Вместо ресторанов речь идет о фотоальбомах.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...