重要
2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。 詳細については、FAQ を参照してください。
同じアプリの異なるユーザーは、カスタム ポリシー内のデータの値に応じて、異なるユーザー体験に従うことができます。 Azure Active Directory B2C (Azure AD B2C) カスタム ポリシーを使用すると、技術プロファイルを条件付きで有効または無効にして、この機能を実現できます。 たとえば、 Azure AD B2C カスタム ポリシーを使用したユーザー入力の検証では、 Precondition を使用して 、accountType 要求の値に基づいて検証技術プロファイルを実行する必要があるかどうかを判断しました。
技術プロファイルには EnabledForUserJourneys 要素も用意されています。これにより、技術プロファイルを実行するかどうかを指定できます。
EnabledForUserJourneys要素には、OnClaimsExistence を含む 5 つの値のいずれかが含まれています。この値を使用して、技術プロファイルで指定された特定のクレームが存在する場合にのみ技術プロファイルを実行するように指定します。 技術プロファイルの EnabledForUserJourneys 要素の詳細を確認します。
シナリオの概要
Azure AD B2C カスタム ポリシーを使用したユーザー入力の検証に関する記事では、ユーザーは 1 つの画面で詳細を入力します。 この記事では、ユーザーはまず、自分のアカウントの種類である Contoso Employee Account または Personal Account を選択する必要があります。 Contoso 従業員アカウントを選択したユーザーは、続行して詳細を指定できます。 ただし、 個人アカウント を選択したユーザーは、詳細を提供する前に、有効な招待アクセス コードを指定する必要があります。 そのため、 個人用アカウント の 種類を使用するユーザーには、体験を完了するための追加のユーザー インターフェイスが表示されます。
この記事では、技術プロファイル内 EnabledForUserJourneys 要素を使用して、要求値に基づいて異なるユーザー エクスペリエンスを作成する方法について説明します。
[前提条件]
まだお持ちでない場合は、Azure サブスクリプションにリンクされている Azure AD B2C テナントを作成 します。
コンピューターに Visual Studio Code (VS Code) がインストールされている必要があります。
「Azure AD B2C カスタム ポリシーを使用してユーザー入力を検証する」の手順を完了します。 この記事は、独自の カスタム ポリシーの作成と実行のハウツー ガイド シリーズの一部です。
注
この記事は、 Azure Active Directory B2C での独自のカスタム ポリシーの作成と実行に関するハウツー ガイド シリーズの一部です。 最初の記事からこのシリーズを開始することをお勧めします。
手順 1 - 要求を宣言する
個人用アカウントを選択したユーザーは、有効なアクセス コードを指定する必要があります。 そのため、この値を保持するための要求が必要です。
VS Code で、
ContosoCustomPolicy.XMLファイルを開きます。ClaimsSchemaセクションで、次のコードを使用して accessCode 要求と isValidAccessCode 要求を宣言します。<ClaimType Id="accessCode"> <DisplayName>Access Code</DisplayName> <DataType>string</DataType> <UserHelpText>Enter your invitation access code.</UserHelpText> <UserInputType>Password</UserInputType> <Restriction> <Pattern RegularExpression="[0-9][0-9][0-9][0-9][0-9]" HelpText="Please enter your invitation access code. It's a 5-digit number, something like 95765"/> </Restriction> </ClaimType> <ClaimType Id="isValidAccessCode"> <DataType>boolean</DataType> </ClaimType>
手順 2 - 要求変換を定義する
ClaimsTransformations要素を見つけて、次の要求変換を追加します。
<!---<ClaimsTransformations>-->
<ClaimsTransformation Id="CheckIfIsValidAccessCode" TransformationMethod="CompareClaimToValue">
<InputClaims>
<InputClaim ClaimTypeReferenceId="accessCode" TransformationClaimType="inputClaim1"/>
</InputClaims>
<InputParameters>
<InputParameter Id="compareTo" DataType="string" Value="88888"/>
<InputParameter Id="operator" DataType="string" Value="equal"/>
<InputParameter Id="ignoreCase" DataType="string" Value="true"/>
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="isValidAccessCode" TransformationClaimType="outputClaim"/>
</OutputClaims>
</ClaimsTransformation>
<ClaimsTransformation Id="ThrowIfIsNotValidAccessCode" TransformationMethod="AssertBooleanClaimIsEqualToValue">
<InputClaims>
<InputClaim ClaimTypeReferenceId="isValidAccessCode" TransformationClaimType="inputClaim"/>
</InputClaims>
<InputParameters>
<InputParameter Id="valueToCompareTo" DataType="boolean" Value="true"/>
</InputParameters>
</ClaimsTransformation>
<!---</ClaimsTransformations>-->
CheckIfIsValidAccessCode と ThrowIfIsNotValidAccessCode という 2 つのクレームの変換を定義しました。
CheckIfIsValidAccessCode では 、CompareClaimToValue 変換メソッドを使用して、ユーザーが入力したアクセス コードを静的な値 88888 と比較し (この値をテストに使用してみましょう)、 true または false を isValidAccessCode 要求に割り当てます。
ThrowIfIsNotValidAccessCode は、2 つのクレームの 2 つのブール値が等しいかどうかを確認し、そうではない場合は例外をスローします。
手順 3 - 技術プロファイルを構成または更新する
これで、2 つの新しいセルフアサート技術プロファイルが必要になります。1 つはアカウントの種類を収集し、もう 1 つはユーザーからアクセス コードを収集します。 手順 2 で定義した要求変換を実行してユーザーのアクセス コードを検証するには、新しい要求変換の種類の技術プロファイルも必要 です。 別のセルフアサート技術プロファイルでアカウントの種類を収集したので、 UserInformationCollector セルフアサート技術プロファイルを更新して、アカウントの種類を収集しないようにする必要があります。
ClaimsProviders要素を見つけて、次のコードを使用して新しいクレーム プロバイダーを追加します。<!--<ClaimsProviders>--> <ClaimsProvider> <DisplayName>Technical Profiles to collect user's access code</DisplayName> <TechnicalProfiles> <TechnicalProfile Id="AccessCodeInputCollector"> <DisplayName>Collect Access Code Input from user Technical Profile</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/> <Metadata> <Item Key="ContentDefinitionReferenceId">SelfAssertedContentDefinition</Item> <Item Key="UserMessageIfClaimsTransformationBooleanValueIsNotEqual">The access code is invalid.</Item> <Item Key="ClaimTypeOnWhichToEnable">accountType</Item> <Item Key="ClaimValueOnWhichToEnable">personal</Item> </Metadata> <DisplayClaims> <DisplayClaim ClaimTypeReferenceId="accessCode" Required="true"/> </DisplayClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="accessCode"/> </OutputClaims> <ValidationTechnicalProfiles> <ValidationTechnicalProfile ReferenceId="CheckAccessCodeViaClaimsTransformationChecker"/> </ValidationTechnicalProfiles> <EnabledForUserJourneys>OnClaimsExistence</EnabledForUserJourneys> </TechnicalProfile> <TechnicalProfile Id="CheckAccessCodeViaClaimsTransformationChecker"> <DisplayName>A Claims Transformations to check user's access code validity</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/> <OutputClaims> <OutputClaim ClaimTypeReferenceId="isValidAccessCode"/> </OutputClaims> <OutputClaimsTransformations> <OutputClaimsTransformation ReferenceId="CheckIfIsValidAccessCode"/> <OutputClaimsTransformation ReferenceId="ThrowIfIsNotValidAccessCode"/> </OutputClaimsTransformations> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider> <!--</ClaimsProviders>-->AccessCodeInputCollector と CheckAccessCodeViaClaimsTransformationChecker という 2 つの技術プロファイルを構成しました。 AccessCodeInputCollector 技術プロファイル内から、CheckAccessCodeViaClaimsTransformationChecker 技術プロファイルを検証技術プロファイルとして呼び出します。 CheckAccessCodeViaClaimsTransformationChecker 自体は、要求変換技術プロファイルの種類であり、手順 2 で定義した要求変換を実行します。
AccessCodeInputCollector は、ユーザーからアクセス コードを収集するために使用される Self-Asserted 技術プロファイルです。
EnabledForUserJourneysに設定要素が含まれます。 そのMetadata要素には、要求 (accountType) と、この技術プロファイルをアクティブにする値 (個人用) が含まれます。ClaimsProviders要素を見つけて、次のコードを使用して新しいクレーム プロバイダーを追加します。<!--<ClaimsProviders>--> <ClaimsProvider> <DisplayName>Technical Profile to collect user's accountType</DisplayName> <TechnicalProfiles> <TechnicalProfile Id="AccountTypeInputCollector"> <DisplayName>Collect User Input Technical Profile</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/> <Metadata> <Item Key="ContentDefinitionReferenceId">SelfAssertedContentDefinition</Item> </Metadata> <DisplayClaims> <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/> </DisplayClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="accountType"/> </OutputClaims> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider> <!--</ClaimsProviders>-->ユーザーのアカウントの種類を収集するセルフアサート技術プロファイル (
AccountTypeInputCollector) を構成しました。 これは、AccessCodeInputCollectorセルフアサート技術プロファイルをアクティブ化するかどうかを決定するアカウントの種類の値です。UserInformationCollectorセルフアサート技術プロファイルがアカウントの種類を収集しないようにするには、UserInformationCollectorセルフアサート技術プロファイルを見つけて、次の手順を実行します。accountTypeコレクションから<DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/>、DisplayClaims表示要求を削除します。accountTypeコレクションから<OutputClaim ClaimTypeReferenceId="accountType"/>出力要求 (OutputClaims) を削除します。
手順 4 - ユーザー体験オーケストレーションの手順を更新する
技術プロファイルを設定したので、ユーザー体験オーケストレーションの手順を更新する必要があります。
HelloWorldJourneyユーザー体験を検索して、すべてのオーケストレーション手順を次のコードに置換します。<!--<OrchestrationSteps>--> <OrchestrationStep Order="1" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="2" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="3" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="GetUserInformationClaimsExchange" TechnicalProfileReferenceId="UserInformationCollector"/> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="4" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="ClaimGenerator"/> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="5" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/> <!--</OrchestrationSteps>-->オーケストレーションステップは、オーケストレーションステップの
Order属性で示されている順序で技術プロファイルを呼び出していることを示しています。 ただし、AccessCodeInputCollector技術プロファイルは、ユーザーが [個人アカウント] アカウント の種類を選択した場合にアクティブになります。
手順 5 - カスタム ポリシー ファイルをアップロードする
「 カスタム ポリシー ファイルをアップロード する」の手順に従って、ポリシー ファイルをアップロードします。 ポータルに既に存在するファイルと同じ名前のファイルをアップロードする場合は、[ カスタム ポリシーが既に存在する場合は上書きする] を選択してください。
手順 6 - カスタム ポリシーをテストする
カスタム ポリシーをテストしてカスタム ポリシーをテストする手順に従います。
- 最初の画面で、[ アカウントの種類] で [ 個人アカウント] を選択します。
- [アクセス コード] に「88888」と入力し、[続行] を選択します。
- 必要に応じて残りの詳細を入力し、[ 続行] を選択します。 ポリシーの実行が完了すると、
https://jwt.msにリダイレクトされ、デコードされた JWT が表示されます。 - 手順 5 を繰り返しますが、今回は [アカウントの種類] を選択し、[ Contoso 従業員アカウント] を選択し、プロンプトに従います。
関連コンテンツ
手順 3 では、EnabledForUserJourneys要素を使用して技術プロファイルを有効または無効にします。 または、このシリーズの後半で説明するように、ユーザー体験オーケストレーションステップ内の 前提条件 を使用してオーケストレーション手順を実行またはスキップすることもできます。
次に、次の情報を確認します。