태그 보관물: api

api

SOA / 마이크로 서비스 : 서비스 간 통신에서 인증을 처리하는 방법은 무엇입니까? 3 기반)를 설정했습니다. 중앙 집중식

전경

우리는 단일 플랫폼에서보다 서비스 지향 아키텍처로 이동하고 있습니다. 우리는 매우 기본적인 DDD 원칙을 적용하고 우리의 영역을 서로 다른 범위의 컨텍스트로 나누고 있습니다. 각 도메인은 웹 API (REST)를 통해 분산되어 서비스를 제공합니다.

비즈니스의 특성상 예약 , 서비스 , 고객 , 제품 등과 같은 서비스가 있습니다 .

또한 주요 역할이 다음과 같은 Identity Server (Thinktecture Identity Server 3 기반)를 설정했습니다.

  • 중앙 집중식 인증 (토큰을 발급 한 자격 증명 제공)
  • 다음과 같은 토큰에 클레임을 추가하십시오. 클라이언트의 범위 (클라이언트 당 요청을하는 응용 프로그램을 의미 함), 고객 식별자 (고객 당 응용 프로그램을 사용하는 사람을 의미 함)

또한 서비스에 대한 외부 액세스를 중앙 집중화 하는 API 게이트웨이 의 역할을 소개했습니다 . API Gateway는 다음과 같은 내부 도메인에 대한 깊은 지식이 필요하지 않은 기능을 제공합니다.

  • 리버스 프록시 : 들어오는 요청을 적절한 내부 서비스로 라우팅
  • 버전 관리 : API Gateway 버전이 다른 버전의 내부 서비스에 매핑됩니다.
  • 인증 : 클라이언트 요청에는 Identity Server에서 발급 한 토큰이 포함되며 API Gateway는 토큰의 유효성을 검사합니다 (사용자가 자신이 누구인지 확인)
  • 제한 : 클라이언트 당 요청 수 제한

권한 부여

권한 부여와 관련하여 이는 API 게이트웨이가 아니라 내부 서비스 자체에서 관리됩니다. 현재 2 가지 주요 인증 유형을 수행하고 있습니다.

  • 클라이언트 범위에 따른 권한. 예 : 클라이언트 (우리의 API를 소비하는 외부 애플리케이션)는 Bookings 서비스 API 엔드 포인트에 액세스하기 위해 “bookings”범위가 필요 합니다.
  • 고객에 따른 권한. 예 : 고객 (애플리케이션을 사용하는 실제 사람)이 예약의 참가자 인 경우에만 예약 서비스 에서 엔드 포인트 GET / 예약에 액세스 할 수 있습니다.

내부 서비스에서 권한 부여를 처리 할 수 ​​있도록 API Gateway는 단순히 클라이언트 (요청을 수행하는 애플리케이션) 및 고객 (클레임)에 대한 정보를 포함하는 토큰 (요청을 내부 서비스로 라우팅 할 때)을 전달합니다. 개인이 클라이언트 응용 프로그램에 로그인 한 경우).

문제 설명

지금까지 서비스 간 통신을 도입 할 때까지는 좋았습니다 (일부 서비스는 다른 서비스와 통신하여 일부 데이터를 얻을 수 있음).

질문

서비스 간 통신에서 인증에 어떻게 접근해야합니까?

고려 된 옵션

다른 옵션을 논의하기 위해 다음 샘플 시나리오를 사용합니다.

  • 예약 흐름을 구축하기 위해 API에 액세스하는 ExternalApp 이라는 외부 응용 프로그램이 있습니다 ( ExternalApp 은 클라이언트 로 볼 수 있음 )
  • ExternalApp 은 Bookings 서비스에 액세스해야 하므로 ExternalApp 에 “bookings”범위를 부여합니다.
  • 내부적으로 (이것은 ExternalApp에 대해 완전히 투명한 것입니다 ) Bookings 서비스 는 항공편, 보험 또는 렌터카와 같은 예약의 기본 서비스를 얻기 위해 서비스 서비스를 필요로합니다.

이 문제를 내부적으로 논의 할 때 몇 가지 옵션이 나타 났지만 어떤 옵션이 가장 적합한 지 잘 모르겠습니다.

  1. 때 예약이 와 통신 서비스 , 단순히 앞으로 그가 API 게이트웨이에서받은 토큰 원래해야한다 (클라이언트가 있음을 나타내는 ExternalApp )
    • 시사점 : 허용 되지 않아야 하는 범위를 ExternalApp 에 부여해야 할 수 있습니다 . 예 : ExternalApp 에는 “bookings”및 “services”범위가 있어야하지만 “bookings”범위 만 있으면 충분합니다.
  2. Bookings 가 Services 와 통신 할 때 클라이언트가 이제 ExternalApp 대신 Bookings 가되었음을 나타내는 토큰을 전달하고 Bookings 가 원래 클라이언트 ExternalApp을 가장하고 있음을 나타내는 클레임을 추가합니다.
    • 또한 원래의 클라이언트가 있다는 정보를 포함하여 ExternalApp 서비스 서비스는 또한 원래의 호출에 따라 일부 서비스를 필터링으로 논리를 할 수있는 (예 : 내부 애플리케이션을 위해 우리는 일부 외부 애플 리케이션을위한 모든 싸움을 반환해야합니다)
  3. 서비스는 서로 통신해서는 안됩니다 (따라서 우리는이 질문에 직면하지 않아야합니다)

입력 해 주셔서 감사합니다.

답변

마이크로 서비스 사이에 내부 통신 채널이 있어야합니다 .

예를 들어, RabbitMQ와 같은 일부 메시지 브로커를 내부적으로 사용 하여 마이크로 서비스간에 메시지 를 보내 거나 받거나 발행 / 구독 할 수 있습니다.

그런 다음 “예약 서비스”의 첫 번째 최종 사용자 서비스는 토큰의 유효성을 검사하고 고객이 IdentityServer와 통신하여이 특정 작업을 수행 할 수있는 권한을 부여합니다.

그런 다음 메시지 브로커를 통해 서비스 서비스와 통신하며이 경우 토큰을 다시 확인할 필요가 없습니다.

이 모델은 더 단순하고 더 나은 성능을 제공 할 것입니다.

답변