Пользовательская политика Azure AD B2C с именем пользователя для входа - PullRequest
0 голосов
/ 09 октября 2018

Мы создали настраиваемую политику IEF в Azure AD B2C, чтобы разрешить вход и вход с использованием локальных учетных записей, определенных по имени пользователя, следуя инструкциям, приведенным в Настраиваемая политика B2C для локальных учетных записей на основе имени пользователя ответ,При попытке запустить политику SignUpOrSignIn из IEF в интерфейсе входа в систему отображается следующее исключение.

AADB2C: Возникла исключительная ситуация.

После включения ведения журнала Application Insightsмы зафиксировали следующее фатальное исключение:

Шаг оркестрации '1' в политике 'B2C_1A_signup_signin арендатора' xxxxxxxxxx.onmicrosoft.com 'указывает более одного включенного обмена утверждениями проверки

Шаги оркестровки настроены следующим образом:

<UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
            <ClaimsProviderSelections>
                <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninUsernameExchange" />
            </ClaimsProviderSelections>
            <ClaimsExchanges>
                <ClaimsExchange Id="LocalAccountSigninUsernameExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Username" />
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="SignUpWithLogonUsernameExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonName" />
            </ClaimsExchanges>
        </OrchestrationStep>
        <!-- This step reads any user attributes that we may not have received when in the token. -->
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="4" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    </OrchestrationSteps>
    <ClientDefinition ReferenceId="DefaultWeb" />
</UserJourney>

Ссылочный технический профиль имеет следующий вид:

<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Username">
    <DisplayName>Local Account Signin</DisplayName>
    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    <Metadata>
        <Item Key="SignUpTarget">SignUpWithLogonUsernameExchange</Item>
        <Item Key="setting.operatingMode">Username</Item>
        <Item Key="ContentDefinitionReferenceId">api.selfasserted</Item>
    </Metadata>
    <IncludeInSso>false</IncludeInSso>
    <InputClaims>
        <InputClaim ClaimTypeReferenceId="signInName" />
    </InputClaims>
    <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="signInName" Required="true" />
        <OutputClaim ClaimTypeReferenceId="password" Required="true" />
        <OutputClaim ClaimTypeReferenceId="objectId" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" />
    </OutputClaims>
    <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="login-NonInteractive" />
    </ValidationTechnicalProfiles>
    <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

Мы не можем найти никаких ссылок на эту ошибку в Google или SO, иНе можете понять, где может быть несколько включенных обменов утверждениями проверки?Наилучшее, что мы можем понять, это какая-то часть базовой конфигурации, которая не была должным образом переопределена конфигурацией расширения, и поэтому она видит дубликаты?

1 Ответ

0 голосов
/ 28 ноября 2018

Вы правы, базовая конфигурация не переопределяется.Чтобы исправить это, мы сделали следующее.

В TrustFrameworkExtensions.xml

измените идентификатор на другое

<UserJouney id="SignUpOrSignInUsername">
  ...OrchestrationSteps
</UserJourney>

, затем перейдите в SignUpOrSignIn.xml

измените referenceid на то, что вы положили в extenstions.xml

<DefaultUserJourney ReferenceId="SignUpOrSignInUsername" />
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...