Azure Active Directory와 NGINX Plus로 액세스 제어

많은 조직에서는 Microsoft Active Directory가 직원 및 신뢰하는 사용자의 신원에 대한 유일한 단일 정식 소스를 나타냅니다. 클라우드 기반 비즈니스 애플리케이션을 구축하고 배포할 때 Azure 플랫폼은 특히 Active Directory와의 내장 통합 덕분에 흥미로운 선택이 됩니다.

OpenID Connect는 애플리케이션의 Single Sign-On 및 API 클라이언트 인증에 모두 적용 가능한 기술로 등장했습니다. NGINX Plus 가 리버스 프록시나 API Gateway로 이러한 시나리오에 배치될 때, OpenID Connect 토큰의 유효성을 NGINX Plus에게 offload 할 수 있습니다. 이 접근 방식은 인증이 한 곳에서 이루어지며, 애플리케이션은 성공적으로 인증된 클라이언트만 다루게 됩니다.

Microsoft Azure는 개발자가 Active Directory에 정의된 사용자의 신원을 기반으로 인증하고 사용하며 결정을 내리는 데 도움이 되는 다양한 표준 기반의 페더레이션 신원 및 Single Sign-On 기술을 지원합니다. 그러나 애플리케이션 레벨에서 이러한 표준 기반 기술을 구현하는 것이 어려운 경우 또는 바람직하지 않은 상황도 있습니다. 예를 들어:

  • 기존 애플리케이션을 클라우드로 이전할 때는 Single Sign-On을 지원하기 위해 기존의 인증 시스템을 현대화하는 것이 어려울 수 있습니다.
  • 마이크로서비스 스타일의 애플리케이션을 구축할 때는 마이크로서비스(Microservices)마다 반복하는 대신 인증 및 액세스 제어 기능을 중앙 집중화하는 것이 바람직합니다.
Azure Active Directory NGINX Plus

이 블로그 포스트에서는 NGINX Plus를 사용하여 Azure에서 발급한 OpenID Connect 토큰을 유효성 검사하고, Azure Active Directory에서 그룹 멤버십 할당을 기반으로 미세한 액세스 제어를 적용하는 방법을 보여줍니다.

목차

1. NGINX Plus로 OpenID Connect 로그인 확인
2. NGINX Plus로 Azure JWT 유효성 검사
3. Role-Based 액세스 제어
4. Azure AD 액세스 제어 요약

1. NGINX Plus로 OpenID Connect 로그인 확인

OpenID Connect 인증 프로세스는 최종적으로 사용자/클라이언트에게 신원 토큰을 발급하며, 이는 보호된 리소스에 액세스할 때 인증 증명으로 제시될 수 있습니다. 신원 토큰은 사용자 정보를 배포하기 위해 매우 유연하고 이식 가능한 데이터 형식인 JSON Web Token (JWT) 표준을 사용합니다.

참고: JWT에 대한 소개는 JWT 및 NGINX Plus를 사용한 인증 및 콘텐츠 기반 라우팅을 참조하십시오.

웹 브라우저나 API 클라이언트가 Azure 로그인 시스템에서 성공적으로 인증되면 Azure는 이를 신원 토큰(JWT 형식)으로 발급할 수 있습니다. 아래에 샘플로 디코딩된 Azure 신원 토큰(Id_token)이 표시되어 있습니다. 이 토큰에는 사용자 정보의 여러 유용한 부분이 포함되어 있으며, 이메일 주소와 사용자의 실제 이름과 같은 정보는 애플리케이션에서 개인화된 사용자 경험을 제공하는 데 사용될 수 있습니다. 이 Azure 신원 토큰에는 JSON 배열로 그룹 멤버십 목록(line 13-17)도 포함되어 있음에 유의하십시오.

{
  "aio": "AUQAu/8GAAAAgsMuoz2rZG9FU6DgfQ6Eo+6qhp6+9AsCG71WssWeXhFmAFaWiS4X7NJg3/k6OVR2kVPGDLF0aWHniQD1qcY8sQ==",
  "amr": [
    "pwd"
  ],
  "aud": "ac6ee3d5-4a2b-4ce1-aff0-157181da2c6f",
  "nbf": 1514886571,
  "exp": 1514890471,
  "email": "xample@example.com",
  "name": "Xavier Ample",
  "family_name": "Ample",
  "given_name": "Xavier",
  "groups": [
    "22c852e1-7034-4610-8c1c-9a4b5576f240",
    "620647cc-abde-406f-b7c6-d062c9561cfb",
    "9692a7ad-fd5c-4183-8ea7-b816c06e21af"
  ],
  "iat": 1514886571,
  "idp": "live.com",
  "ipaddr": "10.0.0.1",
  "iss": "https //sts.windows.net/f96d557e-c5ae-4b75-a812-2d4106ead198/",
  "nonce": "14b09b909b959f7d4097525d91b89cc718f1d2cfd22841d4a1382391cd699641",
  "oid": "b57e3072-38eb-4332-89b8-d6038993b5e5",
  "sub": "EpFEXMqK7_SGudgq2GLFNKq7xotlHKXYmsTyMZiuO-Q",
  "tid": "f96d557e-c4ae-4b75-a912-2d4106ead198",
  "unique_name": "live.com#xample@example.com",
  "uti": "5ULp6hSi5EOY7N5CAdYJAA",
  "ver": "1.0",
  "wids": [
    "62e90394-79f5-4237-9190-052177145e10"
  ]
}

2. NGINX Plus 로 Azure JWT 유효성 검사

Azure JWT의 유효성을 검사하기 위한 기본 구성은 NGINX Plus 구성에 두 줄을 추가하는 것만으로 간단하게 수행할 수 있습니다.

auth_jwt "Closed site";
auth_jwt_key_file /etc/nginx/azure.jwk;

이 구성은 사이트 전체에 적용되거나 location 별로 구체적인 URI에 적용될 수 있습니다 auth_jwt 지시문은 클라이언트가 유효한 JWT를 제공해야 함을 지정합니다. 다음 조건이 충족될 때 JWT가 유효한 것으로 간주됩니다:

  • 서명은 auth_jwt_key_file에 있는 key로 유효성을 검사할 수 있습니다(있는 경우 kid 헤더 필드와 일치).
  • JWT는 nbf(not before) 및 exp(expire) 클레임 중 하나 또는 둘 모두에 의해 정의될 때 유효 기간 내에 표시됩니다. (위 샘플 JWT의 7~8행을 참조하세요. 시간은 UNIX epoch 시간으로 표시됩니다.)

NGINX Plus가 JWT 유효성 검사를 수행함으로써 백엔드 애플리케이션과 API에서 인증 프로세스를 offload할 수 있습니다. 이는 백엔드의 요청 처리 용량을 늘리는 데 도움이 되는 것뿐만 아니라, 백엔드로 배포되는 요청이 올바르게 인증된 요청만이 되도록 보장합니다.

Azure 신원 토큰을 유효성 검사하려면 NGINX Plus에 Microsoft의 공개 JWT 서명 key를 제공해야 합니다. 이러한 서명 key를 NGINX Plus 구성과 동일한 디렉토리에 저장하여 auth_jwt_key_file 지시문에서 지정한 대상 파일 이름과 일치하도록 해야 합니다.

$ curl -sS https://login.microsoftonline.com/common/discovery/keys > /etc/nginx/azure.jwk

Microsoft는 이미 발급된 토큰을 무효화하지 않고 key를 순환할 수 있도록 여러 서명 key를 동시에 유지 관리합니다. 따라서 cron(8) 작업으로 이 파일을 정기적으로 새로 고치는 것이 좋습니다.

3. Role-Based 액세스 제어

위의 샘플 JWT에서 보듯이, Microsoft Azure에서 OpenID Connect 신원 토큰을 사용하는 주요 장점 중 하나는 그룹 멤버십 정보를 포함할 수 있다는 것입니다. 이 정보가 신원 토큰에 포함되어 있으면 NGINX Plus를 사용하여 토큰을 유효성 검사하는 것뿐만 아니라 그룹 멤버십을 기반으로 하는 역할 기반 액세스 제어도 수행할 수 있습니다.

그룹 멤버십이 그룹 JWT 클레임에 나타나도록 하려면 “groupMembershipClaims” 값을 “SecurityGroup”로 설정하거나 Office 365 그룹도 포함하려면 “All”로 설정하여 App registtations 매니페스트에서 이 값을 설정해야 합니다.

Microsoft Azure > App registrations > NGINX Plus

데모 시나리오에서는 NGINX Plus를 사용하여 Finance 그룹만 접근할 수 있는 웹 애플리케이션을 보호하고 있습니다. 이는 Azure Active Directory에 정의된 여러 그룹 중 하나에 불과합니다.

Finance 그룹의 속성을 검사할 때 고유한 Obeject ID는 이 그룹에 할당된 사용자에 대한 그룹 클레임에 나타나는 값입니다(그림 4에 강조 표시됨).

Finance 그룹의 Object ID는 566a3987-eff4-4c6d-9df3-0b23e5f49b1e입니다. 이 값을 NGINX Plus 구성에서 사용하여 (아래의 4번째 줄) Finance 그룹의 멤버만이 백엔드 애플리케이션에 액세스할 수 있도록 보장합니다.

auth_jwt_claim_set $jwt_groups groups;

map $jwt_groups $isFinance {
    "~566a3987-eff4-4c6d-9df3-0b23e5f49b1e" 1; # Finance group object ID
    default                                 0;
}

server {
    listen 80; # For testing only, use TLS in production

    # Azure identity token presented as a cookie
    auth_jwt "Finance app" token=$cookie_auth_token;
    auth_jwt_key_file /etc/nginx/azure.jwk;

    location / {
        # Ensure the user belongs to the Finance group
        auth_jwt_require $isFinance error=403;
        
        #error_page 403 /not_in_group.html; # Nice error page when forbidden

        # Successfully authenticated users are proxied to the finance app,
        # with email address passed as HTTP header
        proxy_set_header X-JWT-Email $jwt_claim_email;
        proxy_pass http://10.0.0.1; # Testing only, use upstream in production
    }
}

1번 라인에서는 $jwt_groups라는 변수를 정의하는데, 이 변수는 JWT의 groups 클레임의 값으로 평가됩니다. NGINX Plus는 자동으로 JWT 클레임을 위한 변수를 제공하지만, 클레임이 특수 문자를 포함하거나 값이 배열이거나 중첩된 JSON 객체인 경우 auth_jwt_claim_set 지시문을 사용하여 해당 값을 액세스해야 합니다. 처리의 편의를 위해 JSON 배열은 쉼표로 구분된 목록으로 평가됩니다.

이 쉼표로 구분된 그룹 멤버십 목록을 3번 라인에서 시작하는 map으로 배포합니다. map의 결과는 $isFinance라는 새 변수로, 기본적으로 0으로 평가됩니다. 정규식을 사용하여 $jwt_groups 변수가 Finance 그룹의 Azure Object ID를 포함하는지 여부를 테스트합니다.

8번 줄에서 시작하는 server 블록은 Finance 앱에 대한 간단한 리버스 프록시를 설명합니다. 12번 줄의 auth_jwt 지시문은 전체 애플리케이션에 JWT 유효성 검사가 필요하며 JWT 자체는 auth_token이라는 이름의 쿠키로 제공되어야 함을 지정합니다.

17번 줄에서는 auth_jwt_require 지시문을 사용하여 $isFinance 변수를 평가하여 JWT에 Finance 그룹이 포함되어 있는지 테스트합니다. Finance 그룹에 속하지 않은 사용자는 HTTP 403 오류를 받게 됩니다. 이 오류에 대한 사용자 경험은 사용자 정의 오류 페이지를 생성하여 개선할 수 있습니다 (19번 줄 주석 처리).

성공적으로 유효성 검사된 JWT가 Finance 그룹을 포함하는 경우 요청은 최종적으로 백엔드 애플리케이션으로 프록시됩니다 (24번 줄). 또한, 이메일 클레임은 추가 HTTP 헤더로 백엔드로 프록시되며 (23번 줄), 애플리케이션에서 쉽게 사용할 수 있도록 소비될 수 있습니다.

4. Azure AD 액세스 제어 요약

OpenID Connect와 JWT 표준은 단일 로그온이 필요하고 신원 정보를 사용하는 애플리케이션을 구축하는 데 매우 큰 유연성을 제공합니다. 위의 예제는 NGINX Plus가 토큰 유효성 검사 및 미세한 액세스 제어를 백엔드에서 offload하는 데 사용될 수 있는 중앙 집중식 보안 서비스로 사용되는 방법을 보여줍니다. 이 같은 솔루션은 웹 애플리케이션에 대한 리버스 프록시와 로드 밸런싱, 또는 마이크로서비스 애플리케이션 아키텍처의 핵심에 위치한 API Gateway로 사용할 수 있습니다.

NGINX Plus에서 JWT를 사용하는 방법에 대한 자세한 내용은 다음을 참조하세요.

NGINX Plus의 기본 JWT 지원을 직접 살펴보려면 지금 무료 30일 평가판을 시작하거나 NGINX STORE에 문의하십시오.

NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.