다음을 통해 공유


자습서: 보안 하이브리드 액세스를 위해 Azure Active Directory B2C를 사용하여 Ping ID 구성하기

중요합니다

2025년 5월 1일부터 새 고객을 위해 Azure AD B2C를 더 이상 구매할 수 없습니다. FAQ에서 자세히 알아보세요.

이 자습서에서는 PingAccessPingFederate를 사용하여 Azure AD B2C(Azure Active Directory B2C)의 기능을 확장하는 방법을 알아봅니다. PingAccess는 애플리케이션 및 API에 대한 액세스와 승인된 사용자 액세스를 위한 정책 엔진을 제공합니다. PingFederate는 고객, 직원 및 파트너가 디바이스에서 애플리케이션에 액세스할 수 있도록 허용하는 권한인 사용자 인증 및 Single Sign-On을 위한 엔터프라이즈 페더레이션 서버입니다. 이를 함께 SHA(보안 하이브리드 액세스)를 사용하도록 설정합니다.

인터넷에 노출된 많은 전자 상거래 사이트와 웹 애플리케이션은 프록시 시스템 또는 역방향 프록시 시스템 뒤에 배포됩니다. 이러한 프록시 시스템은 트래픽을 미리 인증하고, 정책을 적용하고, 트래픽을 라우팅합니다. 일반적인 시나리오에는 인바운드 웹 트래픽으로부터 웹 애플리케이션을 보호하고 분산 서버 배포에서 일관된 세션 관리를 제공하는 작업이 포함됩니다.

일반적으로 구성에는 대부분 웹 애플리케이션으로부터 인증을 표면화하는 인증 이 번역 레이어가 포함됩니다. 역방향 프록시는 일반 또는 다이제스트 형식의 헤더 값과 같은 인증된 사용자 컨텍스트를 웹 애플리케이션에 제공합니다. 애플리케이션은 SAML(Security Assertion Markup Language), OAuth 또는 OIDC(OpenID Connect)와 같은 업계 표준 토큰을 사용하지 않습니다. 대신 프록시는 인증 컨텍스트를 제공하고 브라우저 또는 네이티브 애플리케이션과 같은 최종 사용자 에이전트와 세션을 유지 관리합니다. 중간 단위로 실행되는 서비스인 프록시는 중요한 세션 컨트롤을 제공합니다. 프록시 서비스는 효율적이고 확장 가능하며 프록시 서비스 뒤의 애플리케이션에 병목 현상이 발생하지 않습니다. 다이어그램은 역방향 프록시 구현 및 통신 흐름입니다.

역방향 프록시 구현의 다이어그램.

현대화

이러한 구성에서 ID 플랫폼을 현대화하려는 경우 다음과 같은 고객 문제가 있을 수 있습니다.

  • 애플리케이션 현대화 작업과 ID 플랫폼 현대화 작업 분리
  • 현대화된 ID 서비스 제공자에서 사용하는 최신 및 레거시 인증 환경
    • 최종 사용자 경험 일관성 향상
    • 애플리케이션 간에 단일 로그인 환경 제공

이러한 문제에 대한 답변으로 이 자습서의 접근 방식은 Azure AD B2C, PingAccessPingFederate 통합입니다.

공유 환경

기술적으로 실행 가능하고 비용 효율적인 솔루션은 현대화된 ID 시스템을 사용하여 인증을 위임하도록 역방향 프록시 시스템을 구성하는 것입니다.
프록시는 최신 인증 프로토콜을 지원하고 사용자를 새 ID 공급자(IdP)에게 보내는 리디렉션 기반(수동) 인증을 사용합니다.

ID 공급자로서의 Azure AD B2C

Azure AD B2C에서 사용자 환경 및 동작(사용자 경험이라고도 함)을 유도하는 정책을 정의합니다. 이러한 각 정책은 인증을 IdP로 수행할 수 있는 프로토콜 엔드포인트를 노출합니다. 애플리케이션 쪽에서는 특정 정책에 대해 특별한 처리가 필요하지 않습니다. 애플리케이션은 정책에 의해 노출된 프로토콜별 인증 엔드포인트에 표준 인증 요청을 합니다.
정책 간에 동일한 발급자를 공유하거나 각 정책에 대해 고유한 발급자를 공유하도록 Azure AD B2C를 구성할 수 있습니다. 각 애플리케이션은 프로토콜 네이티브 인증 요청을 만들어 정책을 가리킬 수 있으며, 이는 로그인, 로그인 및 프로필 편집과 같은 사용자 동작을 유도합니다. 다이어그램에서 OIDC와 SAML 애플리케이션 워크플로를 확인할 수 있습니다.

OIDC 및 SAML 애플리케이션 워크플로의 다이어그램

이 시나리오는 레거시 애플리케이션이 사용자를 정확하게 리디렉션하는 데 어려울 수 있습니다. 애플리케이션에 대한 액세스 요청에는 사용자 환경 컨텍스트가 포함되지 않을 수 있습니다. 대부분의 경우 프록시 계층 또는 웹 애플리케이션의 통합 에이전트가 액세스 요청을 가로챕니다.

PingAccess 역방향 프록시

PingAccess를 역방향 프록시로 배포할 수 있습니다. PingAccess는 중간자(man-in-the-middle)가 되거나 웹 애플리케이션 서버에서 실행되는 에이전트에서 제공되는 리디렉션으로 직접 요청을 가로챌 수 있습니다.

업스트림 인증 공급자를 통한 인증을 위해 OIDC, OAuth2 또는 SAML로 PingAccess를 구성합니다. PingAccess 서버에서 이 용도로 업스트림 IdP를 구성할 수 있습니다. 다음 다이어그램을 참조하세요.

PingAccess 서버의 업스트림 IDP 다이어그램.

IdP를 노출하는 정책을 사용하는 일반적인 Azure AD B2C 배포에는 문제가 있습니다. PingAccess는 하나의 업스트림 IdP로 구성됩니다.

PingFederate 페더레이션 프록시

PingFederate를 업스트림 IdP에 대한 인증 공급자 또는 프록시로 구성할 수 있습니다. 다음 다이어그램을 참조하세요.

업스트림 IDP에 대해 인증 공급자 또는 프록시를 구성한 PingFederate의 다이어그램

이 함수를 사용하여 인바운드 요청을 컨텍스트에 따라, 동적으로 또는 선언적으로 Azure AD B2C 정책으로 전환합니다. 프로토콜 시퀀스 흐름의 다음 다이어그램을 참조하세요.

PingAccess, PingFederate, Azure AD B2C 및 애플리케이션에 대한 프로토콜 시퀀스 흐름의 다이어그램

필수 조건

시작하려면 다음이 필요합니다.

  • Azure 구독
  • Azure 구독에 연결된 Azure AD B2C 테넌트
  • Docker 컨테이너 또는 Azure VM(가상 머신)에서 배포된 PingAccess 및 PingFederate

연결 및 통신

다음 연결 및 통신을 확인합니다.

  • PingAccess 서버 – PingFederate 서버, 클라이언트 브라우저, OIDC, 잘 알려진 OAuth, 그리고 Azure AD B2C 서비스 및 PingFederate 서버에서 게시한 키 검색과 통신합니다.
  • PingFederate 서버 – PingAccess 서버, 클라이언트 브라우저, OIDC, 잘 알려진 OAuth, 그리고 Azure AD B2C 서비스에서 게시한 키 검색과 통신합니다.
  • 레거시 또는 헤더 기반 AuthN 애플리케이션 – PingAccess 서버와 통신
  • SAML 신뢰 당사자 애플리케이션 – 클라이언트로부터 브라우저 트래픽을 수신합니다. Azure AD B2C 서비스에서 게시한 SAML 페더레이션 메타데이터에 액세스합니다.
  • 최신 애플리케이션 – 클라이언트에서 브라우저 트래픽에 도달합니다. OIDC, 잘 알려진 OAuth, 그리고 Azure AD B2C 서비스에서 게시한 키 검색에 액세스합니다.
  • REST API – 네이티브 또는 웹 클라이언트의 트래픽에 도달합니다. OIDC, 잘 알려진 OAuth, 그리고 Azure AD B2C 서비스에서 게시한 키 검색에 액세스합니다.

Azure AD B2C 구성하기

기본 사용자 흐름 또는 고급 IEF(Identity Enterprise Framework) 정책을 사용할 수 있습니다. PingAccess는 검색 규칙에 WebFinger 프로토콜을 사용하여 발급자 값에 따라 메타데이터 엔드포인트를 생성합니다. 이 규칙을 따르려면 사용자 흐름 정책 속성을 사용하여 Azure AD B2C 발급자를 업데이트합니다.

토큰 호환성 대화 상자에서 주체 하위 클레임 URL의 스크린샷

고급 정책에서 구성에는 JWT 발급자 기술 프로필의 AuthorityWithTfp 값에 대한 IssuanceClaimPattern 메타데이터 요소가 포함됩니다.

PingAccess 및 PingFederate 구성

다음 섹션의 지침을 사용하여 PingAccess 및 PingFederate를 구성합니다. 전체 통합 사용자 흐름에 대한 다음 다이어그램을 참조하세요.

PingAccess 및 PingFederate 통합 사용자 흐름 다이어그램

토큰 공급자로서 PingFederate 구성하기

PingFederate를 PingAccess에 대한 토큰 공급자로 구성하려면 PingFederate에서 PingAccess로의 연결을 확인합니다. PingAccess에서 PingFederate로의 연결을 확인합니다.

헤더 기반 인증에 대한 PingAccess 애플리케이션 구성

다음 지침을 사용하여 헤더 기반 인증을 위해 대상 웹 애플리케이션에 대한 PingAccess 애플리케이션을 만듭니다.

가상 호스트 만들기

중요합니다

모든 애플리케이션에 대한 가상 호스트를 만듭니다.

가상 호스트를 만들려면 다음을 수행합니다.

  1. 설정>액세스>가상 호스트로 이동합니다.
  2. 가상 호스트 추가를 선택합니다.
  3. 호스트의 경우 애플리케이션 URL의 FQDN 부분을 입력합니다.
  4. 포트의 경우 443을 입력합니다.
  5. 저장을 선택합니다.

웹 세션을 만듭니다.

웹 세션을 만들려면 다음을 수행합니다.

  1. 설정>액세스>웹 세션으로 이동합니다.
  2. 웹 세션 추가를 선택합니다.
  3. 웹 세션의 이름을 입력합니다.
  4. 쿠키 유형( 서명된 JWT 또는 암호화된 JWT)을 선택합니다.
  5. 대상 그룹에 대한 고유 값을 입력 합니다.
  6. 클라이언트 ID의 경우 Microsoft Entra 애플리케이션 ID를 입력합니다.
  7. 클라이언트 암호의 경우 애플리케이션에 대해 생성한 키를 Microsoft Entra ID에 입력합니다.
  8. (선택 사항) Microsoft Graph API를 사용하여 사용자 지정 클레임 만들기 및 사용: 고급을 선택합니다. 요청 프로필을 선택 취소하고 사용자 특성을 새로 고칩니다. 사용자 지정 클레임에 대해 자세히 알아보세요. Microsoft Entra 애플리케이션 프록시를 사용하는 온-프레미스 앱에 대한 헤더 기반 Single Sign-On.
  9. 저장 선택

ID 매핑 만들기

비고

헤더에 동일한 데이터가 필요한 경우 둘 이상의 애플리케이션에서 ID 매핑을 사용할 수 있습니다.

ID 매핑을 만들려면 다음을 수행합니다.

  1. 설정>액세스>ID 매핑으로 이동합니다.
  2. ID 매핑 추가를 선택합니다.
  3. *이름을 지정합니다.
  4. 헤더 ID 매핑의 ID 매핑 유형을 선택합니다.
  5. 특성 매핑 테이블에서 필요한 매핑을 지정합니다. 예를 들면 다음과 같습니다.
속성 이름 헤더 이름
'upn' x-userprincipalname
이메일 x-이메일
'oid' x-oid
'scp' x-scope
암르 x-amr
  1. 저장 선택

사이트 만들기

비고

일부 구성에서는 사이트에 여러 애플리케이션이 포함될 수 있습니다. 적절한 경우 둘 이상의 애플리케이션이 있는 사이트를 사용할 수 있습니다.

사이트를 만들려면 다음을 수행합니다.

  1. 기본>사이트로 이동합니다.
  2. 사이트 추가를 선택합니다.
  3. 사이트 이름을 입력 합니다.
  4. 사이트 Target에 접속하세요. 대상은 애플리케이션을 호스트하는 서버에 대한 hostname:port 쌍입니다. 이 필드에 애플리케이션 경로를 입력하지 마세요. 예를 들어 https://mysite:9999/AppName에 있는 애플리케이션의 대상 값은 mysite:9999입니다.
  5. 대상이 보안 연결을 필요한지 여부를 나타냅니다.
  6. 대상에 보안 연결이 예상되는 경우 신뢰할 수 있는 인증서 그룹을 트러스트 Any로 설정합니다.
  7. 저장을 선택합니다.

애플리케이션 만들기

보호하려는 Azure의 각 애플리케이션에 대해 PingAccess에서 애플리케이션을 만들려면 다음을 수행합니다.

  1. 기본>애플리케이션으로 이동

  2. 애플리케이션 추가 선택

  3. 애플리케이션의 이름 지정

  4. 필요에 따라 애플리케이션에 대한 설명을 입력합니다.

  5. 애플리케이션에 대한 컨텍스트 루트 를 지정합니다. 예를 들어 https://mysite:9999/AppName의 애플리케이션은 /AppName.을 컨텍스트 루트로 가집니다. 컨텍스트 루트는 슬래시(/)로 시작해야 하고, 슬래시(/)로 끝나지 않아야 하며, 계층이 둘 이상일 수 있습니다(예: /Apps/MyApp).

  6. 만든 가상 호스트 선택

    비고

    가상 호스트와 컨텍스트 루트의 조합은 PingAccess에서 고유해야 합니다.

  7. 만든 웹 세션 선택

  8. 애플리케이션이 포함된 만든 사이트를 선택합니다.

  9. 생성한 ID 매핑을 선택하세요

  10. 저장할 때 사이트를 활성화하려면 사용을 선택하십시오.

  11. 저장 선택

PingFederate 인증 정책 구성하기

PingFederate 인증 정책을 구성하여 Azure AD B2C 테넌트에서 제공하는 여러 IdP에 페더레이션합니다.

  1. IdP와 SP 간에 특성을 연결하는 계약을 만듭니다. SP가 각 IdP에서 다른 특성 집합을 요구하지 않는 한 하나의 계약만 필요합니다. 자세한 내용은 Ping ID 설명서의 페더레이션 허브 및 인증 정책 계약을 참조하세요.

  2. 각 IdP에 대해 IdP와 페더레이션 허브(SP) PingFederate 간에 IdP 연결을 만듭니다.

  3. 대상 세션 매핑 창에서 해당 인증 정책 계약을 IdP 연결에 추가합니다.

  4. 선택기 창에서 인증 선택기를 구성합니다. 예를 들어 인증 정책에서 각 IdP를 해당 IdP 연결에 매핑하는 식별자 첫 번째 어댑터 의 인스턴스를 참조하세요.

  5. 페더레이션 허브(IdP) PingFederate와 SP 간에 SP 연결을 만듭니다.

  6. 인증 원본 매핑 창의 SP 연결에 해당 인증 정책 계약을 추가합니다.

  7. 각 IdP를 사용하여 페더레이션 허브(SP) PingFederate에 연결합니다.

  8. SP를 사용하여 페더레이션 허브(IdP) PingFederate에 연결합니다.

다음 단계

자세한 내용은 다음 문서를 참조하세요.