Регистрация в Azure AD B2C без входа пользователя

Я настроил Azure AD B2C, чтобы разрешить аутентификацию пользователей из "обычного" каталога AAD с использованием настраиваемых политик, как описано здесь https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-aad-custom. В одном из сценариев я хочу, чтобы пользователь выполнил регистрацию (аутентифицировался с использованием своих кредитов AAD, создал соответствующий объект в каталоге AAD B2C и передал объектный идентификатор в качестве утверждения моему приложению) без предоставления какой-либо дополнительной информации. Исходя из примеров, я не могу понять, как полностью пропустить этап самоутверждения. Я пробовал два подхода:

1) удаление SelfAsserted-Social ClaimsExchange и 2) изменение (фактически, копирование в TrustFrameworkExtensions, переименование и редактирование) SelfAsserted-Social и AAD-UserReadUsingObjectId ClaimsExchanges, так что единственными записями OutputClaim являются те, которые не требуют запроса пользователя.

В обоих подходах с точки зрения пользовательского интерфейса регистрация работает, но объект пользователя не создается в каталоге B2C. При использовании App Insights в обоих подходах AAD-UserReadUsingObjectId, похоже, генерирует Microsoft.Cpim.Common.PolicyException.

Полный путь пользователя

<UserJourney Id="SignUpAAD">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="KDEWEbAppTestExchange"   />
          </ClaimsProviderSelections>
        </OrchestrationStep>

        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="KDEWebAppTestExchange" TechnicalProfileReferenceId="KDEWebAppTestProfile" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="3" Type="ClaimsExchange">
           <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>

         <!-- prepare ground for searching for user -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Social-Silent" TechnicalProfileReferenceId="SelfAsserted-Social-Silent" />
          </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">
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectIdLimited" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- 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">
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />

      </OrchestrationSteps> 
    </UserJourney>

Любые идеи?

Благодарность

Мартин


azure-ad-b2c identity-experience-framework
person M Herbener    schedule 16.01.2018    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Вы должны заменить шаг 4 оркестровки следующим шагом оркестровки:

<OrchestrationStep Order="4" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="AAD-UserWriteUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
  </ClaimsExchanges>
</OrchestrationStep>

На этом этапе оркестрации создается пользовательский объект, если пользовательский объект не был получен на этапе оркестрации 3 (т. Е. Утверждение «objectId» не существует).

person Chris Padgett    schedule 16.01.2018
comment
Если я это сделаю, оставлю ли я также Шаг 5 (AADUserReadWithObjectId) и Шаг 6 (повторяющийся AAD-UserWriteUsingAlternativeSecurityId)? - person M Herbener; 17.01.2018
comment
Хорошо, я заменил свой шаг 4 оркестровки упрощенной версией того, что вы рекомендовали (исключив предварительные условия, потому что я готов предположить в этом пользовательском путешествии, что объект еще не существует), удалил мои шаги 5 и 6 и пометил шаг 7 к шагу 5, и все сработало так, как хотелось. Я думал, что пробовал это раньше, но, видимо, нет. Благодарность! - person M Herbener; 17.01.2018
comment
Фактически, в моем сценарии я даже могу пропустить шаг 3 оркестровки (AADUserReadUsingAlternativeSecurityId), потому что я готов предположить, что пользовательский объект еще не существует. - person M Herbener; 17.01.2018
comment
Если вы согласны с этим, то да, вы можете удалить шаг 3 и предварительные условия для шага 4. - person Chris Padgett; 17.01.2018