Весенняя безопасность: почему аутентификация распространяется на Принципала?

Question

Spring Security предполагает, что аутентификация является Принципалом.

public interface Authentication extends Principal, Serializable {} 

HttpServletRequest имеет метод getUserPrincipal, который отвечает за доступ к основному объекту.

Давайте рассмотрим этот случай:

public interface RealPrincipal extends Principal { 
    public Integer getId(); 
} 

Общего модуль А имеет вещественный главный интерфейс и реализацию.

Модуль A использует общий модуль A, Servlet Апи и не зависит от Spring Security:

Модуль B использует общий модуль A, Servlet Апи и настраивает Spring Security. Этот модуль отвечает за безопасность и реализацию UserDetails.

Web А использует модуль A и B. Модуль

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

public ModelAndView someRequestHandler(Principal principal) { 
    User activeUser = (User) ((Authentication) principal).getPrincipal(); 
    ... 
} 

Это вынуждает меня есть зависимость Spring Security для модуля А и других модулей. Я считаю, что правильная абстракция сервлета не должна зависеть от весенней безопасности. request.getUserPrincipal должен возвращать реальный главный.

Пожалуйста, объясните, почему org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestWrapper возвращает

аутентификации вместо Real Principal.

Редактировать: я добавил общий модуль A к моему сценарию и обновил, что модуль B отвечает за безопасность.

Answer 1

Как утверждает Люк, Spring Security использует аутентификацию для Принципала, потому что она реализует Принципала. Он не использует аутентификацию # getPrincipal(), поскольку он не гарантированно является Принципалом (это объект). Фактически, в большинстве случаев аутентификация Spring Security # getPrincipal() возвращает пользователя (не реализует Principal), пользовательские UserDetails, предоставляемые пользователями фреймворка, или String.

Если вы хотите, чтобы Spring Security справилась с этим, вам, скорее всего, понадобится реализовать эту логику с помощью HttpServletRequestWrapper, как предложил Люк.Например, вы можете сделать следующее:

public RealPrincipalFilter extends OncePerRequestFilter { 

    public void doFiter(HttpServletRequest request, HttpServletResponse response, FilterChain) { 
     chain.doFilter(new RealPrincipalRequestWrapper(request), response); 
    } 

    private static final class RealPrincipalRequestWrapper 
      extends HttpServletRequestWrapper { 
     public Principal getUserPrincipal() { 
      Authentication auth = (Authentication) super.getPrincipal(); 
      return auth == null ? null : (RealPrincipal) auth.getPrincipal() 
     } 
    } 
} 

@Configuration 
@EnableWebSecurity 
public WebSecurityConfig extends WebSecurityConfigurerAdapter { 
    public configure(HttpSecurity http) { 
     http 
      // ... other config ... 
      .addFilterAfter(new RealPrincipalFilter(), SecurityContextHolderAwareRequestFilter.class); 
    } 
    ... 
} 

С другой стороны, посмотрите на мой ответ на ваш другой вопрос для вариантов интеграции с Spring MVC - Injecting Custom Principal to Controllers by Spring Security

Answer 2

Короткий ответ заключается в том, что Authentication является Principal, так что его можно использовать в API (например, упомянутый API-интерфейс сервлета), для которого требуется один.

Что это означает на практике? Не много. Интерфейс Java Principal имеет только один метод getName, поэтому, если вы хотите сделать больше, чем отображать имя пользователя, вам нужно знать что-то еще о реализации.

Возможно, вам стоит подумать о том, что вы имеете в виду, когда используете фразы «настоящий главный» и «правильная абстракция сервлета api». Как бы вы ожидали реализовать свой метод someRequestHandler, если, например, главный был «реальным»?