как включить TOTP с миграцией пользователей в AD B2C

Я использую это руководство для своевременной миграции пользователя с устаревшего 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/policy/custom-mfa-totp. У меня есть отдельная служба для генерации QR-кода, которая предоставляется пользователю при регистрации.

Однако я не уверен, как включить миграцию пользователей, описанную выше, с TOTP. Когда пользователь, существующий в устаревшем IdP, пытается войти в систему, и если он прошел проверку и их учетная запись создана в AD, я бы хотел, чтобы они были перенаправлены на страницу с QR-кодом в соответствии с приведенной выше политикой, где они должны подписать свой новый перенесенная учетная запись с приложением microsoft auth. В частности, мне бы хотелось получить некоторые рекомендации по настройке описанных выше пользовательских политик для достижения этой цели.


person Riz    schedule 17.02.2021    source источник


Ответы (1)


  1. Наследуйте функции в единой политике: объедините свои файлы в цепочку, настроив элемент basePolicy. Base ‹- Extensions‹ - Extensions_TOTP ‹- Extensions_Migration‹ - SignInSignUp
  2. Удалите или переименуйте все UserJourneys
  3. Создайте новый UserJourney, который создает логику, которую вы хотите вызвать для определенной функциональности (технических профилей), которую вы хотите, с предварительными условиями для вызова только технических профилей TOTP на основе определенных значений утверждений. По сути, вы можете пройти путь пользователя JIT-миграции и внести определенные шаги из пути пользователя TOTP, чтобы предоставить функциональность TOTP.
  4. Обновите идентификатор defaultUserJourney в файле SignInSignUp.

Ваше путешествие должно выглядеть так

      <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-миграцией. Вы можете использовать атрибуты расширения, чтобы указать, является ли это мигрированным пользователем. Эти утверждения затем можно использовать для управления логикой этих шагов по вашему желанию.

person Jas Suri - MSFT    schedule 19.02.2021
comment
Большое спасибо, что нашли время написать это. Я глубоко копался в технической документации AD B2C и вижу, что вы внесли немалый вклад в проекты github, расширение vs code, документацию и т. Д. Спасибо за ваш вклад. - person Riz; 20.02.2021