Azure Active Directory B2C로 Trusona 인증 클라우드 구성

이 샘플 자습서에서는 Azure AD B2C 인증을 Trusona 인증 클라우드와 통합하는 방법을 알아봅니다. 사용자가 어떤 종류의 모바일 인증 앱 없이도 탭하여 이동(tap-and-go) 환경으로 인증할 수 있는 클라우드 기반 서비스입니다.

Azure AD B2C와 Trusona 인증 클라우드 통합의 이점은 다음과 같습니다.

• 더 나은 사용자 환경으로 강력한 인증 제공

  • 온라인에서 더 많은 시간을 보낼 수 있음
  • 감소 및 중단 감소, 수익 증가
  • 더 높은 보존, LTV(수명 값)

• 비즈니스 운영 비용 절감

  • 계정 탈취 및 계정 공유 감소
  • 사기 감소 및 수동 사기 분석 작업 감소
  • 수동 검토 아웃소싱 비용 절감

• 암호 제거

  • 더 이상 암호 재설정 없음
  • 콜 센터 불만 감소
  • 암호를 사용한 빠르고 간단하며 원활한 로그인

필수 조건

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

• Trusona 인증 클라우드 평가판 계정. 계정을 요청하려면 Trusona에 문의하세요.
• Azure 구독 구독이 없는 경우 무료 계정을 얻을 수 있습니다.
• Azure 구독에 연결된 Azure AD B2C 테넌트.

• Azure AD B2C에서 사용자 지정 정책 시작 문서의 단계를 완료합니다.

시나리오 설명

웹 인증 표준 - WebAuthn은 최신 운영 체제 및 브라우저를 구현하여 지문, Windows hello 또는 USB, Bluetooth 및 OTP와 같은 외부 FIDO 디바이스를 통한 인증을 지원합니다.

이 시나리오에서 Trusona는 Azure AD B2C의 IdP(ID 공급자) 역할을 하여 암호 없는 인증을 사용하도록 설정합니다. 솔루션의 구성 요소는 다음과 같습니다.

• 로그인 및 등록 정책이 결합된 Azure AD B2C.
• Trusona 인증 클라우드가 Azure AD B2C에 IdP로 추가되었습니다.

단계	설명
1.	사용자가 브라우저를 통해 웹 애플리케이션에 로그인을 시도합니다.
2.	웹 애플리케이션은 Azure AD B2C 등록 및 로그인 정책으로 리디렉션됩니다.
3.	Azure AD B2C는 인증을 위해 사용자를 Trusona 인증 OIDC(Cloud OpenID Connect) IdP로 리디렉션합니다.
4.	사용자 이름(일반적으로 이메일 주소)을 묻는 로그인 웹 페이지가 사용자에게 표시됩니다.
5.	사용자는 이메일 주소를 입력하고 계속 단추를 선택합니다. Trusona 인증 클라우드에서 사용자 계정을 찾을 수 없는 경우 디바이스에서 WebAuthn 등록 프로세스를 시작하는 브라우저로 응답이 전송됩니다. 그렇지 않으면 WebAuthn 인증 프로세스를 시작하는 브라우저로 응답이 전송됩니다.
6.	사용자에게 사용할 자격 증명을 선택하라는 메시지가 표시됩니다. 암호 키는 웹 애플리케이션의 도메인 또는 하드웨어 보안 키와 연결됩니다. 사용자가 자격 증명을 선택하면 OS는 사용자에게 생체 인식, 암호 또는 PIN을 사용하여 ID를 확인하도록 요청합니다. 이렇게 하면 선택한 자격 증명과 연결된 프라이빗 키로 서명된 인증 어설션을 생성하는 보안 Enclave/신뢰할 수 있는 실행 환경이 잠금 해제됩니다.
7.	인증 어설션은 확인을 위해 Trusona 클라우드 서비스로 반환됩니다.
8.	확인되면 Trusona 인증 클라우드(IdP)는 OIDC ID 토큰을 만든 다음 Azure AD B2C(서비스 공급자)에 전달합니다. Azure AD B2C는 Trusona의 OpenID 검색 문서의 값에 대해 토큰 및 발급자의 서명의 유효성을 검사합니다. 이러한 세부 정보는 IdP 설정 중에 구성되었습니다. 일단 확인되면 Azure AD B2C는 OIDC id_token(범위에 따라 다름)을 발급하고 토큰을 사용하여 사용자를 시작 애플리케이션으로 다시 리디렉션합니다.
9.	웹 애플리케이션(또는 인증을 구현하는 데 사용하는 개발자 라이브러리)은 토큰을 검색하고 Azure AD B2C 토큰의 신뢰성을 확인합니다. 이 경우 클레임을 추출하여 사용할 웹 애플리케이션에 전달합니다.
10.	확인 시 사용자에게 액세스 권한이 허용/거부됩니다.

1단계: Trusona 인증 클라우드로 온보딩

1. Trusona 포털에 로그인합니다.

2. 왼쪽 탐색 패널에서 설정을 선택합니다.

3. 설정 메뉴에서 슬라이더를 선택하여 OIDC 사용을 선택합니다.

4. 적절한 입력을 선택하고 리디렉션 URLhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp를 제공합니다.

5. Azure AD B2C 설정에서 사용할 비밀 키를 생성하고 키를 복사합니다.

   참고 항목

   1. Trusona 포털은 셀프 서비스 등록을 지원합니다. 등록하면 읽기 전용 권한이 있는 Trusona 계정에 할당됩니다. 그 후 Trusona는 사용자에게 올바른 계정을 할당하고 포털 사용자에 대한 조직의 액세스 제어 정책에 따라 읽기-쓰기 권한을 높입니다.
   2. Microsoft Entra ID의 초기 도메인 이름이 클라이언트 리디렉션 호스트로 사용됩니다.

   

2단계: Azure AD B2C에서 웹 애플리케이션 등록

애플리케이션이 Azure AD B2C와 상호 작용하려면 먼저 고객 테넌트에 등록해야 합니다. 이 자습서에서는 Azure Portal을 사용하여 웹 애플리케이션을 등록하는 방법을 보여줍니다. 이 자습서와 같은 테스트 목적으로 토큰의 디코딩된 콘텐츠를 표시하는 Microsoft 소유의 웹 애플리케이션인 https://jwt.ms를 등록합니다(토큰의 콘텐츠는 브라우저를 떠나지 않음). Azure AD B2C 테넌트에 웹 애플리케이션을 등록하려면 새로운 통합 앱 등록 환경을 사용합니다.

1. Azure Portal에 로그인합니다.

2. 여러 테넌트에 액세스할 수 있는 경우 상단 메뉴의 설정 아이콘을 선택하여 디렉터리 + 구독 메뉴에서 Azure AD B2C 테넌트로 전환합니다.

3. Azure Portal에서 Azure AD B2C를 검색하고 선택합니다.

4. 앱 등록을 선택한 다음, 새 등록을 선택합니다.

5. 애플리케이션의 이름을 입력합니다. 예: jwt ms.

6. 지원되는 계정 유형 아래에서 모든 ID 공급자 또는 조직 디렉터리의 계정(사용자 흐름에서 사용자를 인증하는 용도) 을 선택합니다.

7. 리디렉션 URI에서 웹을 선택한 다음 URL 텍스트 상자에 https://jwt.ms를 입력합니다.

   리디렉션 URI는 권한 부여 서버(이 경우 Azure AD B2C)가 사용자를 보내는 엔드포인트입니다. 사용자와의 상호 작용을 완료한 후 권한 부여에 성공하면 액세스 토큰 또는 인증 코드가 전송됩니다. 프로덕션 애플리케이션에서는 일반적으로 https://contoso.com/auth-response와 같이 앱이 실행되는 공개적으로 액세스할 수 있는 엔드포인트입니다. 이 자습서와 같은 테스트 목적으로 토큰을 디코딩된 토큰 콘텐츠를 표시하는 Microsoft 소유의 웹 애플리케이션 https://jwt.ms로 설정할 수 있습니다(토큰의 콘텐츠가 브라우저에서 벗어나면 안 됨). 앱을 개발하는 동안 애플리케이션이 로컬에서 수신 대기하는 엔드포인트(예: https://localhost:5000)를 추가할 수 있습니다. 언제든지 등록된 애플리케이션에서 리디렉션 URI를 추가하고 수정할 수 있습니다.

   리디렉션 URI에는 다음 제한 사항이 적용됩니다.

   • localhost 리디렉션 URL을 사용하지 않는 한 응답 URL은 https 체계로 시작해야 합니다.
   • 회신 URL은 대/소문자를 구분합니다. 해당 사례는 실행 중인 애플리케이션의 URL 경로에 대한 대/소문자와 일치해야 합니다. 예를 들어 애플리케이션의 경로 .../abc/response-oidc의 일부로 포함하는 경우 회신 URL에 .../ABC/response-oidc를 지정하지 마세요. 웹 브라우저는 경로를 대/소문자 구분하여 처리하므로 .../abc/response-oidc와 연결된 쿠키는 대/소문자가 일치하지 않는 .../ABC/response-oidc URL로 리디렉션되는 경우 제외될 수 있습니다.
   • 응답 URL은 애플리케이션에서 예상하는 대로 후행 슬래시를 포함하거나 제외해야 합니다. 예를 들어, https://contoso.com/auth-response 및 https://contoso.com/auth-response/는 애플리케이션에서 일치하지 않는 URL로 처리될 수 있습니다.

8. 사용 권한 아래에서 openid 및 offline_access 권한에 대한 관리자 동의 허용 확인란을 선택합니다.

9. 등록을 선택합니다.

ID 토큰 암시적 허용 사용

이 앱을 등록하고 사용자 흐름 또는 사용자 지정 정책을 테스트하기 위해 https://jwt.ms/ 앱으로 구성하는 경우 앱 등록에서 암시적 허용 흐름을 사용하도록 설정해야 합니다.

1. 왼쪽 메뉴의 관리 아래에서 인증을 선택합니다.

2. 암시적 허용 및 하이브리드 흐름에서 ID 토큰(암시적 및 하이브리드 흐름에 사용됨) 확인란을 선택합니다.

3. 저장을 선택합니다.

3단계: Azure AD B2C에서 Trusona 인증 클라우드를 IdP로 구성

1. Azure AD B2C 테넌트의 전역 관리자로 Azure Portal에 로그인합니다.

2. 여러 테넌트에 액세스할 수 있는 경우 상단 메뉴의 설정 아이콘을 선택하여 디렉터리 + 구독 메뉴에서 Azure AD B2C 테넌트로 전환합니다.

3. Azure Portal의 왼쪽 상단 모서리에서 모든 서비스를 선택하고 Azure AD B2C를 검색하여 선택합니다.

4. 대시보드>Azure Active Directory B2C>ID 공급자로 이동합니다.

5. ID 공급자를 선택합니다.

6. 추가를 선택합니다.

IdP 구성

1. ID 공급자 유형>OpenID Connect(미리 보기)를 선택합니다.

2. 양식을 작성하여 IdP를 설정합니다.

   속성	값
   메타데이터 URL	https://authcloud.trusona.net/.well-known/openid-configuration
   Client ID	Trusona 인증 클라우드 포털에서 사용 가능
   클라이언트 암호	Trusona 인증 클라우드 포털에서 사용 가능
   범위	OpenID 프로필 이메일
   응답 형식	코드
   응답 모드	form_post

3. 확인을 선택합니다.

4. 이 ID 공급자의 클레임 매핑을 선택합니다.

5. 양식을 작성하여 IdP를 매핑합니다.

   속성	값
   UserID	하위
   표시 이름	nickname
   이름	given_name
   Surname	family_name
   응답 모드	이메일

6. 확인을 선택하여 새 OIDC IdP 설정을 완료합니다.

4단계: 사용자 흐름 정책 만들기

이제 Trusona가 B2C IdP에 나열된 새로운 OpenID Connect ID 공급자로 표시되어야 합니다.

1. Azure AD B2C 테넌트에서, 정책 아래 사용자 흐름을 선택합니다.

2. 새 사용자 흐름을 선택합니다.

3. 등록 및 로그인을 선택하고, 버전을 선택한 다음, 만들기를 선택합니다.

4. 정책의 이름을 입력합니다.

5. ID 공급자 섹션에서 새로 만든 Trusona 인증 클라우드-ID 공급자를 선택합니다.

   참고 항목

   Trusona는 본질적으로 다단계이므로 다단계 인증을 사용하지 않도록 설정하는 것이 좋습니다(Trusona는 다단계가 기본값).

6. 만들기를 실행합니다.

7. 사용자 특성 및 클레임에서 자세히 표시를 선택합니다. 양식에서 이전 섹션에서 ID 공급자를 설정하는 동안 지정한 특성을 하나 이상 선택합니다.

8. 확인을 선택합니다.

5단계: 사용자 흐름 테스트

1. 만든 정책을 선택합니다.

2. 사용자 흐름 실행을 선택하고 설정을 선택합니다.

   a. 애플리케이션: 등록된 앱을 선택합니다(예: jwt ms).

   b. 회신 URL: 리디렉션 URL을 선택합니다(예: https://jwt.ms).

3. 사용자 흐름 실행을 선택합니다. Trusona 인증 클라우드로 리디렉션되어야 합니다. 사용자 이름(일반적으로 이메일 주소)을 묻는 로그인 웹 페이지가 사용자에게 표시됩니다. Trusona 인증 클라우드에서 사용자 계정을 찾을 수 없는 경우 디바이스에서 WebAuthn 등록 프로세스를 시작하는 브라우저로 응답이 전송됩니다. 그렇지 않으면 WebAuthn 인증 프로세스를 시작하는 브라우저로 응답이 전송됩니다. 사용자에게 사용할 자격 증명을 선택하라는 메시지가 표시됩니다. 암호 키는 웹 애플리케이션의 도메인 또는 하드웨어 보안 키와 연결됩니다. 사용자가 자격 증명을 선택하면 OS는 사용자에게 생체 인식, 암호 또는 PIN을 사용하여 ID를 확인하도록 요청합니다. 이렇게 하면 선택한 자격 증명과 연결된 프라이빗 키로 서명된 인증 어설션을 생성하는 보안 Enclave/신뢰할 수 있는 실행 환경이 잠금 해제됩니다. Azure AD B2C는 Trusona 인증 응답의 유효성을 검사하고 OIDC 토큰을 발급합니다. 사용자를 시작 애플리케이션(예: https://jwt.ms)으로 다시 리디렉션하여 Azure AD B2C에서 반환한 토큰의 콘텐츠를 표시합니다.

3단계: Trusona 인증 클라우드 정책 키 만들기

이전에 1단계에서 생성한 클라이언트 암호를 Azure AD B2C 테넌트에 저장합니다.

1. Azure Portal에 로그인합니다.

2. 여러 테넌트에 액세스할 수 있는 경우 상단 메뉴의 설정 아이콘을 선택하여 디렉터리 + 구독 메뉴에서 Azure AD B2C 테넌트로 전환합니다.

3. Azure Portal의 왼쪽 상단 모서리에서 모든 서비스를 선택하고 Azure AD B2C를 검색하여 선택합니다.

4. 개요 페이지에서 ID 경험 프레임워크를 선택합니다.

5. 정책 키, 추가를 차례로 선택합니다.

6. 옵션에서 수동을 선택합니다.

7. 정책 키의 이름을 입력합니다. 예: TrusonaTacClientSecret. B2C_1A_ 접두사가 키의 이름에 자동으로 추가됩니다.

8. 이전에 기록해 두었던 클라이언트 비밀을 비밀에 입력합니다.

9. 키 사용에서 Signature를 선택합니다.

10. 만들기를 실행합니다.

4단계: Trusona 인증 클라우드를 IdP로 구성

팁

이 시점에서 Azure AD B2C 정책을 구성해야 합니다. 그렇지 않은 경우 Azure AD B2C 테넌트를 설정하고 정책을 구성하는 방법에 대한 지침을 따르세요.

사용자가 Trusona 인증 클라우드를 사용하여 로그인할 수 있도록 하려면 Trusona를 Azure AD B2C가 엔드포인트를 통해 통신할 수 있는 클레임 공급자로 정의해야 합니다. 엔드포인트는 Azure AD B2C에서 특정 사용자가 디바이스에서 사용할 수 있는 암호 또는 하드웨어 보안 키를 사용하여 인증했는지 확인하는 데 사용되는 클레임 집합을 제공하여 사용자 ID를 증명합니다.

Trusona를 클레임 공급자로 추가하려면 다음 단계를 따릅니다.

1. GitHub에서 사용자 지정 정책 스타터 팩을 가져온 다음, Azure AD B2C 테넌트 이름을 사용하여 LocalAccounts 스타터 팩의 XML 파일을 업데이트합니다.

   1. .zip 파일을 다운로드하거나 리포지토리를 복제합니다.

          git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
      

   2. LocalAccounts 디렉터리의 모든 파일에서 문자열 yourtenant를 Azure AD B2C 테넌트의 이름으로 바꿉니다. 예를 들어 B2C 테넌트의 이름이 contoso이면 yourtenant.onmicrosoft.com의 모든 인스턴스는 contoso.onmicrosoft.com이 됩니다.

2. LocalAccounts/TrustFrameworkExtensions.xml 파일을 엽니다.

3. ClaimsProviders 요소를 찾습니다. 없는 경우 이 요소를 TrustFrameworkPolicy 루트 요소 아래에 추가합니다.

4. 다음과 같이 새 ClaimsProvider를 추가합니다.

<ClaimsProvider>
  <Domain>TrusonaTAC</Domain>
  <DisplayName>Trusona TAC</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="TrusonaTAC-OpenIdConnect">
      <DisplayName>TrusonaTAC</DisplayName>
      <Description>Login with your Trusona TAC  account</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="METADATA">https://authcloud.trusona.net/.well-known/openid-configuration</Item>
        <Item Key="scope">openid profile email</Item>
         <!-- Update the Client ID to the Trusona Authentication Cloud Application ID -->
         <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
        <Item Key="response_types">code</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</Item>
        <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
        <!-- trying to add additional claim-->
        <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111-->
        <Item Key="11111111-1111-1111-1111-111111111111"></Item>
        <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->
        <Item Key="11111111-1111-1111-1111-111111111111"></Item>
        <!-- The key allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs for each tenant. -->
        <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/187f16e9-81ab-4516-8db7-1c8ef94ffeca,https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->
        <!-- The commented key specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to sign in. -->
        <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>

      </Metadata>
      <CryptographicKeys>
       <!-- Update the Client Secret to the Trusona Authentication Cloud Client Secret Name -->
        <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacSecret" />
      </CryptographicKeys>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authcloud.trusona.net/" />
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="email" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

1. 이전에 1단계에서 기록한 Trusona 인증 클라우드 애플리케이션 ID로 client_id를 설정합니다.

2. client_secret 섹션을 3단계에서 만든 정책 키의 이름으로 업데이트합니다. 예: B2C_1A_TrusonaTacClientSecret

   <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
   

3. 변경 내용을 저장합니다.

5단계: 사용자 경험 추가

이 시점에서 IdP를 설정했지만 아직 로그인 페이지에서 사용할 수 없습니다. 사용자 고유의 사용자 지정 사용자 경험이 있는 경우 6단계를 계속 진행하고, 그렇지 않은 경우 다음과 같이 기존 템플릿 사용자 경험의 복제본을 만듭니다.

1. 시작 팩에서 LocalAccounts/TrustFrameworkBase.xml 파일을 엽니다.

2. Id=SignUpOrSignIn이 포함된 UserJourney 요소를 찾아서 전체 콘텐츠를 복사합니다.

3. LocalAccounts/TrustFrameworkExtensions.xml을 열고 UserJourneys 요소를 찾습니다. 요소가 존재하지 않는 경우 추가합니다.

4. 이전 단계에서 복사한 UserJourney 요소의 전체 콘텐츠를 UserJourneys 요소의 자식으로 붙여넣습니다.

5. 사용자 경험의 Id 이름을 바꿉니다. 예: Id=TrusonaTacSUSI.

6단계: 사용자 경험에 IdP 추가

이제 사용자 경험이 있으므로 사용자 경험에 새 IdP를 추가합니다.

1. 사용자 경험의 Type=CombinedSignInAndSignUp 또는 Type=ClaimsProviderSelection을 포함하는 오케스트레이션 단계 요소를 찾습니다. 일반적으로 첫 번째 오케스트레이션 단계입니다. ClaimsProviderSelections 요소에는 사용자가 로그인 할 수 있는 IdP의 목록이 포함되어 있습니다. 요소의 순서는 사용자에게 표시되는 로그인 단추의 순서를 제어합니다. ClaimsProviderSelection XML 요소를 추가합니다. TargetClaimsExchangeId 값을 식별 이름으로 설정합니다(예: TrusonaTacExchange).

2. 다음 오케스트레이션 단계에서 ClaimsExchange 요소를 추가합니다. Id를 대상 클레임 교환 ID 값으로 설정합니다. 클레임 공급자(예: TrusonaTAC-OpenIdConnect)를 추가하는 동안 TechnicalProfileReferenceId 값을 이전에 만든 기술 프로필의 ID로 업데이트합니다.

다음 XML은 ID 공급자를 사용하는 사용자 경험의 오케스트레이션 단계를 보여줍니다.

    <UserJourney Id="TrusonaTacSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="TrusonaTacExchange" />
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Check if the user has selected to sign in using one of the social providers -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="TrusonaTacExchange" TechnicalProfileReferenceId="TrusonaTAC-OpenIdConnect" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Show self-asserted page only if the directory does not have the user account already (we do not have an objectId). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent in the token. -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>socialIdpAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect from the user. So, in that case, create the user in the directory if one does not already exist (verified using objectId which would be set from the last step if account was created in the directory. -->
        <OrchestrationStep Order="6" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

사용자 경험에 대해 자세히 알아보세요.

7단계: 신뢰 당사자 정책 구성

신뢰 당사자 정책(예: SignUpSignIn.xml)은 Azure AD B2C에서 실행할 사용자 경험을 지정합니다. 신뢰 당사자 내에서 DefaultUserJourney 요소를 찾습니다. ID 공급자를 추가한 사용자 경험 ID와 일치하도록 ReferenceId를 업데이트합니다.

다음 예제에서는 Trusona Authentication Cloud 사용자 경험에 대해 ReferenceId가 TrusonaTacSUSI으로 설정됩니다.

   <RelyingParty>
        <DefaultUserJourney ReferenceId="TrusonaTacSUSI" />
        <TechnicalProfile Id="PolicyProfile">
          <DisplayName>PolicyProfile</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
            <OutputClaim ClaimTypeReferenceId="givenName" />
            <OutputClaim ClaimTypeReferenceId="surname" />
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
            <OutputClaim ClaimTypeReferenceId="identityProvider" />
            <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
            <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

8단계: 사용자 지정 정책 업로드

1. Azure Portal에 로그인합니다.

2. 여러 테넌트에 액세스할 수 있는 경우 상단 메뉴의 설정 아이콘을 선택하여 디렉터리 + 구독 메뉴에서 Azure AD B2C 테넌트로 전환합니다.

3. Azure Portal에서 Azure AD B2C를 검색하고 선택합니다.

4. 정책에서 Identity Experience Framework를 선택합니다.

5. 사용자 지정 정책 업로드를 선택한 다음, 변경한 두 정책 파일을 확장 정책(예: TrustFrameworkExtensions.xml), 신뢰 당사자 정책(예: SignUpOrSignin.xml) 순으로 업로드합니다.

9단계: 사용자 지정 정책 테스트

1. Azure AD B2C 테넌트의 정책에서 Identity Experience Framework를 선택합니다.

2. 사용자 지정 정책에서 TrusonaTacSUSI를 선택합니다.

3. 애플리케이션에서 이전에 이 문서의 필수 조건의 일부로 등록한 웹 애플리케이션을 선택합니다. 예를 들어, jwt ms입니다. 회신 URL에는 https://jwt.ms가 표시되어야 합니다.

4. 지금 실행을 선택합니다. 브라우저가 Trusona 인증 클라우드 로그인 페이지로 리디렉션되어야 합니다.

5. 로그인 화면이 표시됩니다. 하단에 Trusona 인증 클라우드 인증을 사용하는 단추가 있어야 합니다.

6. Trusona 인증 클라우드로 리디렉션되어야 합니다. 사용자 이름(일반적으로 이메일 주소)을 묻는 로그인 웹 페이지가 사용자에게 표시됩니다. Trusona 인증 클라우드에서 사용자 계정을 찾을 수 없는 경우 디바이스에서 WebAuthn 등록 프로세스를 시작하는 브라우저로 응답이 전송됩니다. 그렇지 않으면 WebAuthn 인증 프로세스를 시작하는 브라우저로 응답이 전송됩니다. 사용자에게 사용할 자격 증명을 선택하라는 메시지가 표시됩니다. 암호 키는 웹 애플리케이션의 도메인 또는 하드웨어 보안 키와 연결됩니다. 사용자가 자격 증명을 선택하면 OS는 사용자에게 생체 인식, 암호 또는 PIN을 사용하여 ID를 확인하도록 요청합니다. 이렇게 하면 선택한 자격 증명과 연결된 프라이빗 키로 서명된 인증 어설션을 생성하는 보안 Enclave/신뢰할 수 있는 실행 환경이 잠금 해제됩니다.

7. 로그인 프로세스가 성공하면 브라우저가 Azure AD B2C에서 반환된 토큰의 내용을 표시하는 https://jwt.ms로 리디렉션됩니다.

다음 단계

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

• Azure AD B2C 문서

• Stackoverflow에서 질문하기

• Azure AD B2C 샘플

• Azure AD B2C YouTube 교육 재생 목록

• Azure AD B2C의 사용자 지정 정책

• Azure AD B2C의 사용자 지정 정책 시작하기