SecurityContextHolder , SecurityContext 질문 드립니다.

[질문1] 예제 설명에서 Main Thread 에서 자식 Tread 를 새로 생성해서, 테스트 하는 예제가 있는데요.

실제 업무에서,  MVC 모델에서 자식 Thread 를 선언해서, 사용하는 예제를 그동안 못 봐서요. 

@Controller 에서 @Service 를 호출하고, 대부분 처리하는 방식인데요. 자식 쓰레드를 만드는 패턴은 실제적으로 어느때 사용하나요?

[ 답변 ]

사실 이부분은 사용 패턴이나 실무적 사용빈도가 딱히 정해져 있지 않습니다.

일반적으로 웹 어플리케이션에서 자식 스레드를 생성해서 요청을 처리하는 경우가 그렇게 많지는 않습니다.

그러나 필요에 의해서 비동기 방식으로 서버단에서 뭔가를 처리 할 경우 필연적으로 새로운 스레드를 생성해서 태스크를 처리하게 되는데 이때 현재 인증된 사용자의 정보를 비동기 처리에서 참조하고자 할 경우에 사용할 수 있습니다.

가령 서버단에서 실시간적인 배치 처리나  I/O 와 같은 무거운 작업을 할 경우에 별도의 스레드가 처리를 하도록 맡기게 되는 데 이 때에 해당이 된다고 볼 수 있습니다.

그리고 최근의 스프링 5 버전에서는 리액티브 개념을 도입해서 비동기 방식의 웹 요청 처리를 하게 되는데 이 경우에도 고려사항이 될 수 있습니다.

결론적으로 말씀드리면 웹 어플리케이션에서 뭔가 백그라운드로 비동기 방식의 처리를 해야 하는 경우에는 보안컨텍스트(SecurityContetxt) 를 메인과 자식 스레드간 공유가 되도록 해서 처리할 경우 해당이 된다고 볼 수 있습니다.

[질문2] 기본 설정이 strategyName = MODE_THREADLOCAL 인데요.

자식 쓰레드가 Authentication authentication = SecurityContextHolder.getContext().getAuthentication() 로 접근할때는 안 되지만, 세션으로 get 으로, 호출하면, 같은 WAS 세션에 존재함으로,  authentication 정보를 가져올 수 있는 건 아닌지요?

[ 답변 ]

네 가능합니다.

다만 이럴경우 HttpServletRequest 객체 혹은 HttpSession 객체를 참조해서 사용하고자 하는 장소 즉 해당 메소드로 이러한 파라미터를 계속 전달하거나 아니면 어디에서든 참조 가능하도록 별도의 맵에 저장해서 관리하는 등의 추가 로직이 필요하지만 SecurityContextHolder.getContext().getAuthentication() 방식은 ThreadLocal 를 통해 어디에서든지 참조가 가능하기 때문에 편리한 이점이 있습니다.

그리고 실제로 SecurityContextPersistenceFilter 도 SecurityContext 를 session.getAttribute() 해서 얻은 다음 SecurityContextHolder 에 담고 있기 때문에 우리가 직접 자식스레드 내에서 세션에 저장된 SecurityContext 를 꺼내어 authentication 정보를 참조하는 것이 가능합니다.

네...감사합니다.  도움이 많이 되었습니다.