Блог

Это скорее вопрос на ранней стадии, касающийся идиоматических подходов к моделированию разрешений/ролей для пользовательских ресурсов, созданных в Keycloak. В этом случае я не уверен, следует ли мне просто использовать Keycloak для управления идентификацией и оставить управление доступом приложению.

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

Более конкретным примером является AWS IAM. Несколько пользователей могут находиться в одной учетной записи AWS, но доступ можно контролировать на разных уровнях. Например, может быть настроена роль, предоставляющая разрешения S3 на чтение, а у другой роли может быть разрешение S3 на удаление в сегменте маркетинга.

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

Я не уверен, что это хорошая идея — я предполагаю, что мне нужно будет часто общаться с серверами маскировки ключей, чтобы убедиться, что у данного пользователя есть доступ к ресурсам, которые они пытаются запросить/изменить. Похоже, что маскировка ключей больше подходит для областей/разрешений, которые не привязаны к определенным ресурсам, созданным пользователем? Если это стандартный вариант использования, есть ли какая-либо документация о таких подходах (я ничего не смог найти)?

Keycloak способен очень плавно управлять ролями пользователей, которые вы можете использовать далее в коде Java с такими аннотациями, как:

 @Secured("ROLE_ADMIN")
 

Или

 @RolesAllowed({"ROLE_USER", "ROLE_ADMIN"})
 

внутри контроллера, вместе с отображением методов HTTP или внутри HTML-кода, например

 sec:authorize="hasRole('ADMIN')"
 

Это означает, что вы можете управлять доступом к просмотру/изменению файлов в папке «Маркетинг». Чтобы продвинуться дальше по уровню доступа пользователей, вы можете использовать авторизацию токенов; пожалуйста, прочитайте, например, эту статью.