AADB2 C Пользовательская политика - Политика регистрации локальных и социальных учетных записей с разделенной проверкой электронной почты и подпиской - PullRequest
Новая
       14

AADB2 C Пользовательская политика - Политика регистрации локальных и социальных учетных записей с разделенной проверкой электронной почты и подпиской

0 голосов
/ 01 августа 2020

Я пытаюсь создать настраиваемую политику Azure AD B2 C, которая имеет следующий путь пользователя -

  • Вход / Регистрация с локальной учетной записью и учетными записями социальных сетей, в которых Процесс регистрации должен разделить проверку электронной почты и фактическую страницу регистрации.

Для этого я начал с образца политики - https://github.com/azure-ad-b2c/samples/tree/master/policies/sign-up-with-social-and-local-account

и добавил технические профили EmailVerification и LocalAccountSignUpWithReadOnlyEmail из образца политики - https://github.com/azure-ad-b2c/samples/tree/master/policies/split-email-verification-and-signup

Чтобы запустить разделенную проверку электронной почты и поток регистрации, я установил для SignUpTarget значение EmailVerification.

Я вижу страницу входа / регистрации, и нажатие на ссылку регистрации запускает процесс проверки электронной почты. Однако я не уверен, как запустить технический профиль LocalAccountSignUpWithReadOnlyEmail после проверки электронной почты. Добавление этого как части этапа оркестрации ClaimsExchange вызывает ошибки проверки при загрузке моей настраиваемой политики.

Вот как выглядит конфигурация моего пути пользователя - 

<UserJourneys>
    <UserJourney Id="SignUpOrSignIn">
        <OrchestrationSteps>

            <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
                <ClaimsProviderSelections>
                    <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
                    <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="EmailVerification" TechnicalProfileReferenceId="EmailVerification" />
                </ClaimsExchanges>
            </OrchestrationStep>

            <OrchestrationStep Order="3" Type="ClaimsExchange">
                <ClaimsExchanges>
                    <ClaimsExchange Id="LocalAccountSignUpWithReadOnlyEmail" TechnicalProfileReferenceId="LocalAccountSignUpWithReadOnlyEmail" />
                </ClaimsExchanges>
            </OrchestrationStep>

            <!-- For social IDP authentication, attempt to find the user account in the directory. -->
            <OrchestrationStep Order="4" 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="5" 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="6" 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="7" 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="8" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />

        </OrchestrationSteps>
        <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>
</UserJourneys>

Вот как выглядят технические профили например - 

<ClaimsProviders>
    <ClaimsProvider>
        <DisplayName>Email Verification</DisplayName>
        <TechnicalProfiles>
            <!--Sample: Email verification only-->
            <TechnicalProfile Id="EmailVerification">
                <DisplayName>Initiate Email Address Verification For Local Account</DisplayName>
                <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
                <Metadata>
                    <Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
                    <Item Key="language.button_continue">Continue</Item>
                </Metadata>
                <CryptographicKeys>
                    <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
                </CryptographicKeys>
                <IncludeInSso>false</IncludeInSso>
                <InputClaims>
                    <InputClaim ClaimTypeReferenceId="email" />
                </InputClaims>
                <OutputClaims>
                    <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true" />
                </OutputClaims>
            </TechnicalProfile>

            <!-- This technical profile uses a validation technical profile to authenticate the user. -->
            <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
                <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">EmailVerification</Item>
                    <Item Key="setting.operatingMode">Email</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>
        </TechnicalProfiles>
    </ClaimsProvider>

    <ClaimsProvider>
        <DisplayName>Local Account</DisplayName>
        <TechnicalProfiles>
            <!--Sample: Sign-up self-asserted technical profile without Email verification-->
            <TechnicalProfile Id="LocalAccountSignUpWithReadOnlyEmail">
                <DisplayName>Email signup</DisplayName>
                <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
                <Metadata>
                    <Item Key="IpAddressClaimReferenceId">IpAddress</Item>
                    <Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
                    <Item Key="language.button_continue">Create</Item>
                    <!-- Sample: Remove sign-up email verification -->
                    <Item Key="EnforceEmailVerification">False</Item>
                </Metadata>
                <InputClaimsTransformations>
                    <InputClaimsTransformation ReferenceId="CreateReadonlyEmailClaim" />
                </InputClaimsTransformations>
                <InputClaims>
                    <!--Sample: Set input the ReadOnlyEmail claim type to prefilled the email address-->
                    <InputClaim ClaimTypeReferenceId="readOnlyEmail" />
                </InputClaims>
                <OutputClaims>
                    <OutputClaim ClaimTypeReferenceId="objectId" />
                    <!-- Sample: Display the ReadOnlyEmail claim type (instead of email claim type)-->
                    <OutputClaim ClaimTypeReferenceId="readOnlyEmail" Required="true" />
                    <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
                    <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
                    <OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
                    <OutputClaim ClaimTypeReferenceId="authenticationSource" />
                    <OutputClaim ClaimTypeReferenceId="newUser" />

                    <!-- Optional claims, to be collected from the user -->
                    <!--OutputClaim ClaimTypeReferenceId="displayName" /-->
                    <OutputClaim ClaimTypeReferenceId="givenName" />
                    <OutputClaim ClaimTypeReferenceId="surName" />
                </OutputClaims>
                <ValidationTechnicalProfiles>
                    <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
                </ValidationTechnicalProfiles>
                <!-- Sample: Disable session management for sign-up page -->
                <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
            </TechnicalProfile>
        </TechnicalProfiles>
    </ClaimsProvider>
</ClaimsProviders>

Вот ошибка, которую я получаю при попытке загрузить политику - 

Validation failed: 4 validation error(s) found in policy "B2C_1A_CUSTOM_SIGNUP_SIGNIN" of tenant "testtenant.onmicrosoft.com".User journey "SignUpOrSignIn" in policy "B2C_1A_custom_signup_signin" of tenant "testtenant.onmicrosoft.com" has step 3 with 2 claims exchanges. It must be preceded by a claims provider selection in order to determine which claims exchange can be used.User journey "SignUpOrSignIn" in policy "B2C_1A_custom_signup_signin" of tenant "testtenant.onmicrosoft.com" has step 4 with 2 claims exchanges. It must be preceded by a claims provider selection in order to determine which claims exchange can be used.User journey "SignUpOrSignIn" in policy "B2C_1A_custom_signup_signin" of tenant "testtenant.onmicrosoft.com" has step 5 with 2 claims exchanges. It must be preceded by a claims provider selection in order to determine which claims exchange can be used.User journey "SignUpOrSignIn" in policy "B2C_1A_custom_signup_signin" of tenant "testtenant.onmicrosoft.com" has step 6 with 2 claims exchanges. It must be preceded by a claims provider selection in order to determine which claims exchange can be used.

Ищу здесь совет ...

1 Ответ

1 голос
/ 01 августа 2020

Причина, по которой вы получаете эту ошибку, заключается в том, что вы могли написать User Journey ID SignUpOrSignIn в 2 файлах : Base / Extension и Отвечающая сторона Политика.

Если количество шагов и ClaimsExchange ID уникально, то она примет, иначе она будет рассматривать как 2 разных ClaimsExchange, и при загрузке политики RP произойдет ошибка. Убедитесь, что вы не дублируете User Journey, сохраните только одну копию User Journey Steps или, если вы хотите продлить шаги Journey, добавьте шаги. Например, : в базовой политике у вас всего 5 шагов, затем в расширении или в RP вы можете начать добавлять новый ClaimsExchange с 5-го шага, и последним шагом будет JwtIssuer / SamlIssuer.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Похожие темы

...