Microservice에서 Spring security 문제(2)
2장에서는 나의 경우 인증인가에 대해 어떠한 문제가 발생하고 있는지 소개 해보려고한다.
그전에 나의 개발 구축 기반부터 설명하려고 한다
1. Spring Cloud 기반
Spring cloud와 Netflix Eureka 등을 기반으로 한 microservice를 구축 하고 있다.
그리고 기존의 Monolithic방식으로 작성된 프로젝트를 MSA 기반으로 옮기는 작업을 진행중이다.
여기서 알아야 할 점은, Spring Cloud Api-gateway의 경우에는 비동기 방식 즉, Spring.io에서 밀고있는 Spring Webflux 방식이이라는 것이다. 이것이 왜 문제가 될까?
2. Spring.io에서 밀고 있는 2-Track
스프링에서는 2-Track으로 개발을 하고 있다.
Reactive Stack과 Servlet Stack이다
Servlet Stack의 경우에는 사실 낡은 시스템이라고 봐야한다.
비동기 동기 방식의 차이로 인해, 다른 프레임워크와의 성능대결에서 이길 수 가 없게 되는것이다.
한국시장의 경우에는 아직도 Servlet Stack을 강조 하고 있는데, 나의 경우에도 WebFlux기술에 대해서 잘은 모르지만 무척이나 경각심이 느껴지고 있고 매우 중요한 기술이라는(Spring 한정) 생각이 든다. 그래서 아마 다음 학습대상은 WebFlux 쪽이 아닐까 한다.
3. 발생하는 인증,인가 처리
결과적으로, 이 표를 보면 알 수 있다. WebFlux기반에서는 Spring Security Reactive을 사용해야하고 MCV에서는 그냥 Spring Security를 사용하고 있다.
나의 경우에는 기존 서비스를 microservice로 옮기는 작업을 하고 있기 때문에 spring mvc 기반이다.
일단 기존 서비스를 spring mvc에서 webflux로 변경 할 수는 없다.
또한 기존 서비스는 인증인가의 처리가 Access Token 기반이라는 점도 문제가 된다.
Spring Apigateway에서 filter단에서 jwt토큰의 유효성 검사를 통해, 인가 정보를 넘기는것은 매우 쉽게 구현이 가능하다.
하지만... 인증정보를 다른 서비스로 어떻게 전달한단 말인가..
Spring Security의 인증정보는 SpringSecurityContextHolder에 의해 관리된다.
쓰레드에 안전한방식으로 관리가 되고있으며, 이를 등록한 이후에 인증정보의 출력이 필요하게 된다.
쉽게 말해 위에서 Authorizaion의 로직은 가능하지만 Authentication의 로직이 그냥 전달 할 수는 없다는 의미이다.
이를 해결하기 위한 방법을 고민해본바, 2가지의 방안이 떠올랐다.
=1. 서비스의 구현자체를 인증정보를 사용하지 않고 인가정보만 사용하도록 한다.
예를들면, 인가정보인 email, nickname, userId를 전달하는 형태로 서비스를 구현하면 된다.
=2. gateway를 제외한 모든 마이크로 서비스의 인증 부분을 토큰의 유효성 검사를 하지않고 등록 하도록 한다.
Apigateway에서 모든 인가 부분은 처리가 되니, 모든서비스에 인증인가를 거치지 않고, 인가시에 발생한 정보를 그대로 전달해, 모든서비스의 SecurityContextholder에 저장하는 방식으로 처리한다.
물론 이 방법은 Apigateway의 보안성이 훼손되면, 그 뒤의 모든서비스는 심각한 보안문제를 갖게 된다. 하지만 당장은 좋은 방법이 떠오르지 않아 이 방법으로 서비스를 구축해보려고 한다..
다른 좋은 idea가 있다면 댓글을 남겨주시길 바랍니다...