Почему бы вам не отделить своих пользователей и группы, из которых они состоят, от ролей и служб, к которым они могут получить доступ.
Существуют различные способы сделать это, но один из подходов состоит в том, чтобы инфраструктура центральной аутентификации предоставляла вам группы пользователя, когда он выполняет аутентификацию.
Теперь внутри каждой службы будет отображаться соответствие между группами и ролями.Роли зависят от приложения, служба аутентификации или другие приложения не заботятся о них.Вы можете сохранить это отображение в базе данных отдельного приложения или в простом файле конфигурации (возможно, просто в application.yaml конкретного приложения).
В настоящее время ваши группы Admin и Normal, но у вас могут быть другие.Пользователь также может быть членом нескольких групп.Таким образом, в приложении 1 можно сказать, что Admin пользователи могут выполнять роль 1, роль 2, роль 3, тогда как Normal пользователи могут выполнять только role 1.Опять это много для многих.Это то, что ваш экземпляр UserDetails будет нести, как только он распознает аутентифицированного пользователя и его группы, которые затем сопоставляются с ролями как часть вашей конфигурации Spring Security.После этого вы сможете выполнять PreAuthorise("hasRole('OWNER')") и т. Д. В своих службах.
Таким образом, если вы добавляете больше пользователей, вы просто помещаете их в нужные группы, чтобы предоставить им доступ к отдельным службам.Если вы хотите создать новые профили, а не просто Admin и Normal или специальные группы, вы просто делаете это один раз и обновляете конфигурацию отдельного приложения, чтобы распознать эту группу, если она имеет отношение к ней (запомните пользователяможет быть членом нескольких групп, поэтому вам даже не нужно, чтобы каждое приложение знало о каждой группе).
Я не знаю, какой механизм вы используете для единого входа при аутентификации.Но в духе микросервисов и минимального совместного использования между приложениями вы могли бы фактически поместить группы в качестве областей в свой токен (например, если вы используете JWT).Таким образом, приложение, получающее токен, не только знает, что пользователь прошел проверку подлинности, но и знает группы пользователя, даже не отправляя запрос в какую-либо другую систему.
Эта архитектура, которую вы получите, показана на рисунке.
Каждый сценарий использования (метод обслуживания, отмеченный @PreAuthorise) будет играть свою роль.Каждый пользователь будет связан с несколькими группами, которые предоставит система аутентификации.(Например, группы в Active Directory).После получения информации об аутентификации пользователя группы будут сопоставлены с ролями, специфичными для приложения, и заполнены в объекте UserDetails Spring Security.Каждый аннотированный метод получит специфичные для приложения роли (а не глобальные группы).
Это дает вам возможность добавлять столько групп, сколько вам нужно, которые могут иметь одну и ту же роль приложения.