You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
현재 MSA 서버에 SSO(Single Sign On) 방식을 통한 인증과정이 필요한 상황인 것은 이해했다. 그래서 일반적인 MSA에서 어떤 방식으로 인증 절차가 이루어 지고 있는지 찾아 보았다.
위 와 같이 gateway api 별로 각 서비스에 라우팅을 가능하게한다. 그리고 인증 과정으로는 인증서버를 따로 두어 token을 발급 받는게 일반적이라고 한다. 현재 우리 프로젝트는 세션과 쿠키를 기반으로한 oauth 로그인 방식을 사용하고 있다.
그래서 세션이 SSO 방식에 적합한가를 찾아보았다.
찾아본 결과, MSA 아키텍처라 할지라도 각 서버마다 세션을 공유한다면 가능할 것이라고 한다.
세션 클러스터링 혹은 별도의 세션공유서버나 Redis와 같은 인메모리 세션 저장소를 두어서 서버끼리 API 를 호출할 때마다 사용자의 세션여부를 체크해서 동일한 세션인지 아닌지 판단해서 처리하면 되기는 하나 Redis 같은 경우에는 유료 서비스에다, 세션 클러스터링 혹은 별도의 세션공유서버를 유지하는 것은 복잡할뿐더러 세션 자체가 서버 자원을 많이 소모하기에 MSA MSA 아키텍처에서 세션방식은 추천하지 않는다고 한다.
그래서 위와 같이 일반적으로 인증서버를 별도로 두어서 먼저 인증을 받은 후 token 을 발급받고 API Gateway 를 통과할 때 api Url 과 token 을 가지고 서버에 접속하게 되는데 이때 인증서버에서 발급받은 token 이 유효한 것인지 검증을 받은 후 처리하게 되는 구조 인 것 같다.
찾아보니 spring cloud security 프로젝트가 있는데 세션을 이용한 방식이 아닌 oauth2, jwt 를 사용해서 MSA 인증처리를 할 수 있도록 제공하고 있다고 하는데 이는 더 알아보아야 할 듯하다.
결론 :
지금과 같이 MSA 서비스를 운영하고, 환자 정보와 같이 보안적으로 신경 써야할 서버에 접근을 제한 하기 위해서는 리버스 프록시를 도입해 Gateway 단에서 인증과정이 필수 인것 같다. 문제는 현재 세션을 사용한 로그인 방식을 고수 할 것인가, 아니면 JWT 토큰 인증을 통한 방식으로 전환할 것인가 인듯하다..
근데 뭐 사실.. 우리가 dicom이나 뷰어 쪽에서 세션관련해서 사용자 정보를 필요를 하는게 없지 않나..? 그럼 굳이 세션이 공유 되어야하나도 사실 약간 의문이긴함. 그냥 우리는 접근을 위한 인증과정이 필요한거니깐
The text was updated successfully, but these errors were encountered:
찾아본 결과, MSA 아키텍처라 할지라도 각 서버마다 세션을 공유한다면 가능할 것이라고 한다
세션을 각 서버마다 공유해야 하는 이유가 있음?
세션 클러스터링 혹은 별도의 세션공유서버나 Redis와 같은 인메모리 세션 저장소를 두어서 서버끼리 API 를 호출할 때마다 사용자의 세션여부를 체크해서 동일한 세션인지 아닌지 판단해서 처리하면 되기는 하나 Redis 같은 경우에는 유료 서비스에다, 세션 클러스터링 혹은 별도의 세션공유서버를 유지하는 것은 복잡할뿐더러 세션 자체가 서버 자원을 많이 소모하기에 MSA MSA 아키텍처에서 세션방식은 추천하지 않는다고 한다.
그래서 위와 같이 일반적으로 인증서버를 별도로 두어서 먼저 인증을 받은 후 token 을 발급받고 API Gateway 를 통과할 때 api Url 과 token 을 가지고 서버에 접속하게 되는데 이때 인증서버에서 발급받은 token 이 유효한 것인지 검증을 받은 후 처리하게 되는 구조 인 것 같다.
API Gateway에서만 사용자의 권한 여부를 체크하고 각 서버에 접근하는건 API Gateway를 통해서만 가능하도록 하면 될 듯. 따라서 각 서버가 사용자를 체크할 필요는 없으므로 세션 공유 서버는 필요하지 않을듯
근데 뭐 사실.. 우리가 dicom이나 뷰어 쪽에서 세션관련해서 사용자 정보를 필요를 하는게 없지 않나..? 그럼 굳이 세션이 공유 되어야하나도 사실 약간 의문이긴함. 그냥 우리는 접근을 위한 인증과정이 필요한거니깐
지금 구조는 구글 로그인만 하면 누구든지 서비스에 접근 가능함. 추후 관리자가 승인한 이메일을 가지고 있는 사용자만 접근 할 수 있도록 해야 할듯
issus : #168
생각 :
현재 MSA 서버에 SSO(Single Sign On) 방식을 통한 인증과정이 필요한 상황인 것은 이해했다. 그래서 일반적인 MSA에서 어떤 방식으로 인증 절차가 이루어 지고 있는지 찾아 보았다.
위 와 같이 gateway api 별로 각 서비스에 라우팅을 가능하게한다. 그리고 인증 과정으로는 인증서버를 따로 두어 token을 발급 받는게 일반적이라고 한다. 현재 우리 프로젝트는 세션과 쿠키를 기반으로한 oauth 로그인 방식을 사용하고 있다.
그래서 세션이 SSO 방식에 적합한가를 찾아보았다.
찾아본 결과, MSA 아키텍처라 할지라도 각 서버마다 세션을 공유한다면 가능할 것이라고 한다.
세션 클러스터링 혹은 별도의 세션공유서버나 Redis와 같은 인메모리 세션 저장소를 두어서 서버끼리 API 를 호출할 때마다 사용자의 세션여부를 체크해서 동일한 세션인지 아닌지 판단해서 처리하면 되기는 하나 Redis 같은 경우에는 유료 서비스에다, 세션 클러스터링 혹은 별도의 세션공유서버를 유지하는 것은 복잡할뿐더러 세션 자체가 서버 자원을 많이 소모하기에 MSA MSA 아키텍처에서 세션방식은 추천하지 않는다고 한다.
그래서 위와 같이 일반적으로 인증서버를 별도로 두어서 먼저 인증을 받은 후 token 을 발급받고 API Gateway 를 통과할 때 api Url 과 token 을 가지고 서버에 접속하게 되는데 이때 인증서버에서 발급받은 token 이 유효한 것인지 검증을 받은 후 처리하게 되는 구조 인 것 같다.
찾아보니 spring cloud security 프로젝트가 있는데 세션을 이용한 방식이 아닌 oauth2, jwt 를 사용해서 MSA 인증처리를 할 수 있도록 제공하고 있다고 하는데 이는 더 알아보아야 할 듯하다.
결론 :
지금과 같이 MSA 서비스를 운영하고, 환자 정보와 같이 보안적으로 신경 써야할 서버에 접근을 제한 하기 위해서는 리버스 프록시를 도입해 Gateway 단에서 인증과정이 필수 인것 같다. 문제는 현재 세션을 사용한 로그인 방식을 고수 할 것인가, 아니면 JWT 토큰 인증을 통한 방식으로 전환할 것인가 인듯하다..
The text was updated successfully, but these errors were encountered: