BLOG

애플리케이션 로드 밸런서 기본 인증을 통해 로그인 간소화하기
작성일: 2018-06-18

오늘 ALB(애플리케이션 로드 밸런서)에 내장된 인증 지원을 발표하게 되어 기쁩니다. ALB는 이제 애플리케이션 액세스 시 사용자를 안전하게 인증할 수 있으므로 개발자가 인증을 지원하기 위해 작성해야 하는 코드를 제거하고 백엔드에서의 인증 책임감을 덜어줍니다. 팀은 사용자가 인증 기능을 사용해 볼 수 있는 훌륭한 실시간 예를 만들었습니다.

 

오늘날의 애플리케이션에서는 ID 기반 보안이 중요한 요소이며, 고객이 운영에 필수적인 애플리케이션을 클라우드로 계속 이동함에 따라 개발자들은 동일한 인증 코드를 계속 작성해야 합니다. 기업은 사내 ID를 클라우드 애플리케이션에 사용하기를 원합니다. 웹 개발자는 소셜 네트워크의 연합된 ID를 사용하여 사용자의 로그인을 허용하려고 합니다. ALB의 새 인증은 Amazon Cognito을 사용해 구글, 페이스북, 아마존 등의 소셜 ID 제공자(IdP)를 통해 인증합니다. 또한 기본적으로 모든 OpenID Connect 프로토콜 규정을 준수하는 IdP와 통합되어 애플리케이션 전반에 걸쳐 보안 인증과 단일 로그인 환경을 제공합니다.

 

 

ALB인증은 어떻게 작동합니까?

 

인증은 복잡한 주제이며 독자들의 전문 지식 수준이 다를 수 있습니다. 저희가 모두 같은 페이지에 있다는 것을 확실히 하기 위해 몇 가지 핵심 개념을 다루고 싶습니다. 이미 인증 전문가인 가운데 ALB 인증이 어떻게 작동하는지 보려면 다음 섹션으로 건너뛰십시오!

 

  • 인증은 ID를 확인합니다.
  • 인증은 사용 권한을 확인하며, ID가 허용하는 작업입니다.
  • OIDC(OpenID Connect)는 OAuth 2.0 프로토콜 위에 구축된 간단한 ID 또는 인증, 계층입니다. OIDC 규격 문서는 꽤 잘 작성되어 있고, 가벼운 읽을 만한 가치가 있습니다.
  • IdPs (ID 공급자)는 ID 정보를 관리하고 인증 서비스를 제공합니다. ALB는 OIDC를 준수하는 IdP를 지원하며 Amazon Cognito 또는 Auth0과 같은 서비스를 사용하여 Active Directory, LDAP, Google, Facebook, Amazon 또는 AWS 혹은 사내에 배포된 다른 다양한 IdPs에서의 각기 다른 정체성을 종합합니다.

 

용어에서 잠시 벗어나면, 이 모든 것이 사용자가 누구인지, 무엇을 할 수 있는지에 대한 것으로 요약됩니다. 이것을 안전하고 효율적으로 하는 것은 어렵습니다. 전통적으로 기업은 IdPs가 있는 SAML이라는 프로토콜을 사용하여 내부 사용자에게 SSO(Single Sign-On)환경을 제공해 왔습니다. SAML은 XML 가중치이며 최신 애플리케이션에서는 JSON 메커니즘이 있는 OIDC를 사용하여 클레임을 공유하기 시작했습니다. 개발자는 Amazon Cognito의 SAML 지원에 ALB의 SAML을 사용할 수 있습니다. 웹 앱이나 모바일 개발자들은 일반적으로 Facebook, Amazon 또는 Google과 같은 Amazon Cognito가 지원하는 소셜 IdPs를 통해 연합된 ID를 사용합니다.

 

ALB 인증은 수신기 규칙에서 인증 작업을 정의하는 방식으로 작동합니다. ALB의 인증 작업은 수신 요청에 세션 쿠키가 있는지 확인한 다음 유효한지 확인합니다. 세션 쿠키가 설정되어 있고 유효한 경우 ALB는 요청을 X-AMZN-OIDC-* 헤더가 설정된 대상 그룹으로 라우팅합니다. 헤더에는 백엔드가 사용자를 식별하는 데 사용할 수 있는 JSON 웹 토큰(JWT)형식의 ID 정보가 포함되어 있습니다. 세션 쿠키가 설정되지 않았거나 잘못된 경우 ALB는 OIDC 프로토콜을 따르고 ID 공급자에게 HTTP302 리디렉션을 발행합니다. 이 프로토콜은 포장을 풀기에 너무 많고 호기심이 많은 사람들을 위해 문서에 더 철저하게 적용되어 있습니다.

 

ALB 인증 방법

 

Amazon ECS 클러스터에 있는 간단한 Python 플라스크 앱을 AWS Fargate 컨테이너에서 실행하고 있습니다. 컨테이너는 ALB에 의해 라우팅되는 대상 그룹에 있습니다. 응용 프로그램의 인증된 부분에 액세스하기 전에 응용 프로그램 사용자가 로그되었는지 확인하려고 합니다. 먼저, 콘솔의 ALB로 이동하여 규칙을 편집하겠습니다.

 

 

/account* 엔드포인트에 대한 모든 액세스 권한이 인증되었는지 확인하고 싶습니다. 따라서 해당 엔드포인트와 일치하는 조건으로 새 규칙을 추가하겠습니다.

 

 

이제 새 규칙을 추가하고 해당 규칙에 인증 작업을 만듭니다.

 

 

구성 세부 정보를 제공하여 ALB에서 새 Amazon Cognito 사용자 풀을 생성하도록 하겠습니다.

 

 

 

Amazon Cognito 풀을 만든 후에는 고급 설정에서 몇 가지 추가 구성을 만들 수 있습니다.

 

기본 쿠키 이름을 변경하고, 제한 시간을 조정하고, 범위를 조정하며, 인증되지 않은 요청에 대한 작업을 선택할 수 있습니다.

 

인증되지 않은 모든 요청에 대해 거부를 선택하여 401 서비스를 제공하거나 인증되지 않은 경우 응용 프로그램으로 전달되는 허용을 선택할 수 있습니다. 이 기능은 단일 페이지 응용 프로그램(SPAs)에 유용합니다. 먼저 인증을 선택하겠습니다. 이 경우 Amazon Cognito를 통해 IdP가 표시됩니다. 사용자를 인증하고 기존 페이지를 다시 로드합니다.

 

이제 대상 그룹에 대한 전달 작업을 추가하고 규칙을 저장하겠습니다.

 

 

Facebook 쪽에서 화이트 리스트에 있는 OAuth 리디렉션 URL에 Amazon Cognito 사용자 풀 도메인을 추가하기만 하면 됩니다.

 

 

다른 인증 공급자에 대해서도 비슷한 단계를 수행합니다.

 

이제 인증된 페이지로 이동하면 Fargate 컨테이너가 ALB에서 설정한 X-Amzn-Oidc-* 헤더를 사용하여 최초 요청을 받습니다. 이러한 헤더의 정보(클레임 데이터, ID, 액세스 토큰)를 사용하여 응용 프로그램에서 권한 부여를 구현할 수 있습니다.

 

이 모든 것이 각각의 IdPs를 처리하기 위해 코드 한 줄을 쓸 필요 없이 가능했습니다. 그러나, 애플리케이션을 구현하는 것은 요청이 변조되지 않았는지 확인하기 위해, JWT 헤더에 대한 서명을 확인하는 것이 여전히 중요합니다.

 

추가 리소스

 

물론 오늘 살펴본 모든 것은 API와 AWS Command Line Interface (CLI)에서도 사용할 수 있습니다. 설명서에서 기능에 대한 추가 정보를 찾을 수 있습니다. 이 기능은 추가 비용 없이 제공됩니다.

 

실제 예제도 확인해야 합니다.

 

인증 기능이 ALB에 내장되어 있으므로 개발자는 ALB의 규모, 가용성 및 신뢰성을 유지하면서 모든 애플리케이션에 대한 인증을 재구축하는 대신 애플리케이션 구축에 집중할 수 있습니다.

 

원문 URL: https://aws.amazon.com/ko/blogs/aws/built-in-authentication-in-alb/

** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.