마이크로 서비스 아키텍처의 싱글 사인온

여러 서비스 (데이터 제공) 및 웹 응용 프로그램 (HTML 제공)을 갖는 그린 필드 프로젝트를 디자인하려고합니다. 나는 마이크로 서비스에 대해 읽었으며 잘 맞는 것처럼 보입니다.마이크로 서비스 아키텍처의 싱글 사인온

여전히 문제는 SSO를 구현하는 방법입니다. 사용자가 한 번 인증을 받고 모든 다른 서비스와 응용 프로그램에 액세스 할 수 있기를 바랍니다.

나는 여러 가지 방법을 생각할 수 있습니다

는 신원 서비스 및 응용 프로그램을 추가합니다. 보호 된 리소스가있는 서비스는 ID 서비스와 통신하여 자격 증명이 유효한지 확인합니다. 일치하지 않으면 인증을 위해 사용자를 리디렉션합니다.
OpenID와 같은 웹 표준을 사용하고 각 서비스에서 고유 한 ID를 처리하도록합니다. 즉, 사용자가 각 서비스/응용 프로그램을 개별적으로 인증해야하지만 이후에는 SSO가됩니다.

다른 아이디어를 기꺼이 들려 드리겠습니다. 특정 PaaS (예 : Heroku)가 독점적 인 솔루션을 가지고 있어도 수용 가능합니다.

출처

2014-08-31 Ido Ran

그래서 이것을 읽으면 이런 종류의 문제를 해결할 공식 표준 방법이 없다고 생각합니까? –

당신 말이 맞아요. 내 OAuth 공급자를 사용하여 SSO 결과를 얻지 만 이것이 유일한 방법은 아닙니다. –

나는이 스레드 (그리고 더 많은 사이트)를 우연히 발견했다. 나는이 2 개의 위치가 이것에서 아주 유용하다는 것을 찾아 냈다 : https://medium.facilelogin.com/securing-microservices-with-oauto-2-0-jwt-and-xacml-d03770a9a838 http : // nordicapis./microservices/ – Yogi

필자의 이전 업무에서 마이크로 서비스 아키텍처를 구현하는 동안 최상의 접근 방식은 # 1과 일치하여 신원 서비스를 추가하고이를 통해 서비스 액세스 권한을 부여한다고 판단했습니다. 우리의 경우 이것은 토큰으로 수행되었습니다. 요청이 인증 토큰과 함께 제공된 경우 서비스와의 사용자 세션에서 첫 번째 호출 인 경우 ID 서비스로 해당 토큰을 확인할 수 있습니다. 토큰이 확인되면 세션에 저장되어 사용자 세션의 후속 호출이 추가 호출을하지 않아도됩니다. 해당 세션에서 토큰을 새로 고쳐야하는 경우 예약 된 작업을 만들 수도 있습니다.

이 경우 Google은 OAuth 2.0 엔드 포인트로 인증했으며 도메인에 대한 호출을 위해 토큰이 HTTP 헤더에 추가되었습니다. 모든 서비스가 해당 도메인에서 라우팅되었으므로 HTTP 헤더에서 토큰을 가져올 수 있습니다. 우리 모두가 동일한 애플리케이션 생태계의 일부 였기 때문에 초기 OAuth 2.0 인증은 사용자가 자신의 계정에 대한 권한을 부여 할 애플리케이션 서비스를 나열합니다.

신원 확인 서비스는 HTTP 요청 필터 체인에 추가 될 프록시 클라이언트 라이브러리를 제공하고 서비스에 대한 인증 프로세스를 처리한다는 것이 추가되었습니다. 이 서비스는 ID 서비스에서 프록시 클라이언트 라이브러리를 사용하도록 구성됩니다. 우리가 Dropwizard를 사용하고 있었기 때문에이 프록시는 실행중인 서비스 프로세스에 필터를 부트 스트래핑하는 Dropwizard Module이 될 것입니다. 이로 인해 인터페이스가 크게 변경되지 않는 한 종속 서비스가 쉽게 사용할 수있는 무료 클라이언트 측 업데이트가있는 ID 서비스에 대한 업데이트가 허용되었습니다.

우리의 배포 아키텍처는 AWS 가상 사설망 (VPC)과 자사의 데이터 센터에 분산되어 있습니다. OAuth 2.0 인증 서비스는 회사의 데이터 센터에 위치했으며 모든 애플리케이션 서비스는 AWS VPC에 배포되었습니다.

Google의 접근 방식이 귀하의 결정에 도움이되기를 바랍니다. 다른 질문이 있으면 알려줘.

출처

2014-12-04 00:29:53

심지어 같은 상황으로 끝났지 만 제 경우에는 많은 마이크로 서비스가 있지만 사용자가 큰 허가를 받기를 원하지 않습니다 (Oauth를 사용한다면 가정하십시오.) 다른 마이크로 서비스에 대한 명시 적 예 : 전자 상거래 사이트에서 사용자가 메인 앱에서 인증 된 경우 사용자가 카트 앱, 추천 앱을 명시 적으로 승인하지 못하도록합니다 (최종 사용자에게는 원활해야 함). Oauth 또는 SAML을 사용하여이를 달성합니까? –

"모든 서비스가 해당 도메인에서 라우팅되었습니다"라는 의미는 무엇입니까? – wonder

팁 주셔서 감사합니다; 팁을 기반으로 sso를 구현했습니다. 다음은 내 댓글에 설명 된 접근 방식에 대한 나의 해석 비디오입니다. https://www.youtube.com/watch?v=r7FAuAlKIqY&t=36s –

Chris Sterling은 위에서 설명한 표준 인증 방법을 설명했으며 절대적인 의미를 갖습니다. 나는 실용적인 이유로 여기에 또 다른 생각을하고 싶습니다.

우리는 자원을 인증하기 위해 인증 서버와 인증 서버에 의존하는 여러 다른 마이크로 서비스를 구현했습니다. 인증 서버에 대한 왕복 이동 횟수가 너무 많아 성능 문제가 발생했을 때 마이크로 서비스의 수가 늘어남에 따라 인증 서버에 대한 확장 성 문제도있었습니다. 너무 많은 왕복을 피하기 위해 아키텍처를 조금 변경했습니다.

인증 서버는 자격 증명과 한 번만 연결되며 개인 키를 기반으로 토큰을 생성합니다. 해당 공개 키는 외부의 인증 된 인증 서버를 사용하여 인증 키의 유효성을 검증 할 수있는 각 클라이언트 (마이크로 서비스 서버)에 설치됩니다. 키는 생성 된 시간을 포함하며 마이크로 서비스에 설치된 클라이언트 유틸리티는 유효합니다. 표준 구현이 아니었지만, 특히 모든 마이크로 서비스가 내부적으로 호스팅 될 때이 모델을 통해 꽤 성공적으로 성공했습니다.

출처

2014-12-04 04:53:28 kamoor

당신이 묘사하고있는 것은 Chris에 의해 이미 완성되었다고 생각합니다.> 세션에서 저장되었으므로 사용자 세션의 후속 호출이 추가 호출을 할 필요가 없었습니다. * 내가 틀렸을 수도 있습니다. –

세션 저장은 확장 가능하지 않거나 엔드 포인트의 무국적 특성으로 인해 권장되지 않을 수 있습니다. 내 접근 방식에서는 아무 것도 저장할 수 없으며 공개 키 암호화를 사용하여 인증 서버로의 왕복을 피할 수 있습니다. – kamoor

> * 표준 구현이 아니어도 *. 표준 구현이란 무엇입니까? –

마이크로 서비스 아키텍처의 싱글 사인온

답변

관련 문제