0

ここのガイドを使用して、従来の Idp から azure ad b2c へのユーザーのジャストインタイム移行を実行しています: https://github.com/azure-ad-b2c/user-migration/tree/master/jit -migration-v2 . これは、従来の IdP にクエリを実行し、期待されるクレームを返すために使用しているサービスで、それ自体で適切に機能しています。

また、カスタム TOTP サンプルを試してみて、このサンプルとポリシーを使用して新規ユーザー サインアップ用の QR コードを操作しました: https://github.com/azure-ad-b2c/samples/tree/master/policies/custom -mfa-totp . サインアップ時にユーザーに提示されるQRコードを生成するための別のサービスがあります。

ただし、上記のユーザー移行を TOTP に組み込む方法がわかりません。従来の IdP に存在するユーザーがサインインしようとしたときに、そのユーザーが検証され、AD でアカウントが作成された場合、上記のポリシーに従って QR コード ページに誘導され、そこで新しくサインアップする必要があります。 Microsoft 認証アプリで移行されたアカウント。より具体的には、これを実現するために上記のカスタム ポリシーを設定する方法についてのガイダンスが必要です。

4

1 に答える 1

0
  1. 機能を 1 つのポリシーに継承する: 要素を構成して、このようにファイルをチェーンしますbasePolicy。ベース<-拡張機能<- Extensions_TOTP <- Extensions_Migration <- SignInSignUp
  2. すべての UserJourneys を削除または名前変更します
  3. 特定の要求値に基づいて TOTP 技術プロファイルのみを呼び出す前提条件を使用して、必要な特定の機能 (技術プロファイル) を呼び出すロジックを作成する新しい UserJourney を作成します。基本的に、JIT 移行のユーザー ジャーニーを利用し、TOTP ユーザー ジャーニーから特定の手順を取り入れて、TOTP 機能を提供できます。
  4. SignInSignUpファイルの defaultUserJourney id を更新し ます。

あなたの旅は次のようになります

      <UserJourney Id="SignUpOrSignIn">
      <OrchestrationSteps>
      
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
            <ClaimsProviderSelection TargetClaimsExchangeId="GoogleExchange" />
           <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="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
            <ClaimsExchange Id="GoogleExchange" TechnicalProfileReferenceId="Google-OAUTH" />
           <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- For social IDP authentication, attempt to find the user account in the directory. -->
        <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 (i.e. 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>


       <!-- Demo: The following orchestration step is executed only for unregistered 
        accounts (new created account or if user cancel the sign-up process). 
        It generates a verification app secret key for the user (none interactive step). -->
        <OrchestrationStep Order="7" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>extension_StrongAuthenticationAppSecretKey</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AppFactorGenerateTotpWebHook" TechnicalProfileReferenceId="AppFactor-GenerateTotpWebHook" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- Demo: The following orchestration step is executed only for unregistered 
        accounts (new created account or if user cancel the sign-up process). 
        It registers a verification app through QR code that mobile authentication app should scan. -->
        <OrchestrationStep Order="8" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
              <Value>strongAuthenticationAppQRCodeBitmap</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>isActiveMFASession</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AppFactorRegisterExchange" TechnicalProfileReferenceId="AppFactor-Register" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- Demo: The following orchestration step is executed only for registered accounts.
        It asks the user to provide the TOTP code and verifies the provided code (using validation technical profile). -->
        <OrchestrationStep Order="9" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>strongAuthenticationAppQRCodeBitmap</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AppFactorChallengeExchange" TechnicalProfileReferenceId="AppFactor-Challenge" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- Demo: The following orchestration step is always executed.
        It updates the verification app time step matched for a given user in the Azure Active Directory.
        An error is raised if the user does not exist. -->
        <OrchestrationStep Order="10" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="AADWriteUserAppCodeByObjectId" TechnicalProfileReferenceId="AAD-WriteUserAppCodeByObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>


 
        <OrchestrationStep Order="11" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
 
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

これらの移行されたアカウントに対してのみトリガーされるように、ステップ 7/8/9 に前提条件を追加する必要があります。ステップ 1 で REST API から発行されたクレームを使用して、これが JIT 移行であるかどうかを示すことができます。拡張属性を使用して、これが移行されたユーザーかどうかを示すことができます。これらのクレームは、必要に応じてこれらのステップのロジックを駆動するために使用できます。

于 2021-02-19T10:32:00.287 に答える