5

ここで説明されているように、カスタム ポリシーを使用して、「通常の」AAD ディレクトリからのユーザーによる認証を許可するように Azure AD B2C をセットアップしましたhttps://docs.microsoft.com/en-us/azure/active-directory-b2c/active-ディレクトリ-b2c-setup-aad-custom . あるシナリオでは、ユーザーにサインアップ (AAD クレデンシャルを使用して認証し、AAD B2C ディレクトリに対応するオブジェクトを作成し、objectidentifier をクレームとしてアプリケーションに渡す) を行ってもらいたいと考えています。例から始めて、自己主張のステップを完全にスキップする方法がわかりません。私が試した2つのアプローチは

1) SelfAsserted-Social ClaimsExchange を削除し、2) SelfAsserted-SocialおよびAAD-UserReadUsingObjectId ClaimsExchange を変更 (実際には、TrustFrameworkExtensions にコピー、名前変更、および編集) して、OutputClaim エントリのみがユーザー プロンプトを必要としないものになるようにします。

どちらのアプローチでも、UI の観点からはサインアップは機能しているように見えますが、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>

何か案は？

ありがとう

マーティン

4

1 に答える 1