Пропустить авторизацию в сервисе Spring для внутренних сервисов к сервисным звонкам

Question

Я использую многоуровневую архитектуру Spring, выполняю авторизацию запросов в классах обслуживания.Один сервис может выглядеть так:

@Service
public class SomeService {

    public void findOne(Long id) {
        assertPrivilege("READ");
        // ...
    }
}

Теперь assertPrivilege() использует SecurityContextHolder для получения списка GratedAuthority объектов.Внедряя логику авторизации в сервисы, контролерам не нужно беспокоиться об этом - также при вызове нескольких сервисов с одного контроллера.

Проблема заключается в том, что все другие сервисы не могут получить доступ к этому методу сейчас, если они не авторизованы.Однако есть некоторые потоки (например, планировщики), которые в определенный момент вызывают этот метод, не имея готового объекта Authentication.В некоторых случаях, если это тот же поток, SecurityContext также возвратит текущую аутентификацию.

Теперь, как реорганизовать эту логику, чтобы другие внутренние потоки вызывали метод без авторизации.Требуется ли изменение дизайна, возможно, второй класс-обертка, такой как SomeService (без авторизации) и SomeClientService (с авторизацией)?Другой возможностью было бы получить прямой доступ к репозиториям.

Answer 1

Лучше использовать @PreAuthorize("hasRole('ROLE_VIEWER') or hasRole('ROLE_EDITOR') or #id == authentication.principal.username") вместо метода, см. Учебник, их много .

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

Нет простого способа отключить пружинную защиту для одного пользователя (внутренний вызов, внешнее приложение и т. Д.), Также не рекомендуется (ошибки и т. Д.), Вы можете создать специальную роль для внешнего приложения или использовать Поддержка параллелизма для выполнения внутреннего звонка от имени пользователя.

Answer 2

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