Azure Active Directory B2C カスタムポリシーを使用してユーザーアカウントを作成して読み取る

[アーティクル]
01/11/2024

Azure Active Directory B2C (Azure AD B2C) は Microsoft Entra ID 上に構築されているため、Microsoft Entra ID ストレージを使用してユーザーアカウントを格納します。 Azure AD B2C ディレクトリのユーザープロファイルには、名、姓、市区町村、郵便番号、電話番号などの組み込みの属性セットが付属していますが、外部データストアを必要とすることなく、独自のカスタム属性を使用してユーザープロファイルを拡張できます。

カスタムポリシーは、ユーザー情報を格納、更新、または削除する Microsoft Entra ID 技術プロファイルを使用して、Microsoft Entra ID ストレージに接続できます。この記事では、JWT トークンが返される前にユーザーアカウントを格納して読み取る一連の Microsoft Entra ID 技術プロファイルを構成する方法について説明します。

シナリオの概要

「Azure Active Directory B2C カスタムポリシーを使用して REST API を呼び出す」の記事では、ユーザーから情報を収集し、データを検証し、REST API を呼び出し、最後にユーザーアカウントを格納せずに JWT を返しました。ポリシーの実行が完了した後に情報が失われないように、ユーザー情報を格納する必要があります。今回は、ユーザー情報を収集して検証したら、JWT トークンを返す前にユーザー情報を Azure AD B2C ストレージに格納してから、読み取る必要があります。次の図はそのプロセス全体を示したものです。

A flowchart of creating a user account in Azure AD.

前提条件

まだ持っていない場合は、お使いの Azure サブスクリプションにリンクされている Azure AD B2C テナントを作成します。
Web アプリケーションを登録し、ID トークンの暗黙的な許可を有効にします。リダイレクト URI には https://jwt.ms を使用します。
お使いのコンピューターに Visual Studio Code (VS Code) がインストールされている必要があります。
「Azure Active Directory B2C カスタムポリシーを使用して REST API を呼び出す」の手順を実行します。この記事は、独自のカスタムポリシーの作成と実行に関するハウツーガイドシリーズの一部です。

Note

この記事は、Azure Active Directory B2C での独自のカスタムポリシーの作成と実行に関するハウツーガイドシリーズの一部です。このシリーズは、最初の記事から読み始めることをお勧めします。

手順 1 - 要求を宣言する

さらに 2 つの要求 (userPrincipalName と passwordPolicies) を宣言する必要があります。

ContosoCustomPolicy.XML ファイルで ClaimsSchema 要素を見つけ、次のコードを使用して userPrincipalName と passwordPolicies 要求を宣言します。

    <ClaimType Id="userPrincipalName">
        <DisplayName>UserPrincipalName</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Your user name as stored in the Azure Active Directory.</UserHelpText>
    </ClaimType>
    <ClaimType Id="passwordPolicies">
        <DisplayName>Password Policies</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Password policies used by Azure AD to determine password strength, expiry etc.</UserHelpText>
    </ClaimType>

userPrincipalName と passwordPolicies 要求の使用方法の詳細については、「ユーザープロファイルの属性」の記事を参照してください。

手順 2 ‐ Microsoft Entra ID 技術プロファイルを作成する

2 つの Microsoft Entra ID 技術プロファイルを構成する必要があります。一方の技術プロファイルでは Microsoft Entra ID ストレージにユーザーの詳細を書き込み、もう一方では Microsoft Entra ID ストレージからユーザーアカウントを読み取ります。

ContosoCustomPolicy.XML ファイルで ClaimsProviders 要素を見つけ、次のコードを使用して新しい要求プロバイダーを追加します。この要求プロバイダーは、Microsoft Entra ID 技術プロファイルを保持します:
```
    <ClaimsProvider>
        <DisplayName>Azure AD Technical Profiles</DisplayName>
        <TechnicalProfiles>
            
        </TechnicalProfiles>
    </ClaimsProvider>
```

作成したばかりの要求プロバイダーで、次のコードを使用して Microsoft Entra ID 技術プロファイルを追加します:

    <TechnicalProfile Id="AAD-UserWrite">
        <DisplayName>Write user information to AAD</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Write</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
            <Item Key="UserMessageIfClaimsPrincipalAlreadyExists">The account already exists. Try to create another account</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <PersistedClaims>
            <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />        
            <PersistedClaim ClaimTypeReferenceId="displayName" />
            <PersistedClaim ClaimTypeReferenceId="givenName" />
            <PersistedClaim ClaimTypeReferenceId="surname" />
            <PersistedClaim ClaimTypeReferenceId="password"/>
            <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration,DisableStrongPassword" />
        </PersistedClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
        </OutputClaims>
    </TechnicalProfile>

新しい Microsoft Entra ID 技術プロファイル AAD-UserWrite を追加しました。この技術プロファイルの次の重要な部分に注目する必要があります。

Operation: 操作は、実行するアクション (この場合は Write) を指定します。 Microsoft Entra ID 技術プロバイダーのその他の操作の詳細を確認してください。
Persisted claims: PersistedClaims 要素には、Microsoft Entra ID ストレージに格納する必要があるすべての値が含まれています。
InputClaims: InputClaims 要素には、ディレクトリ内のアカウントを検索したり、新しいものを作成したりするために使用される要求が含まれています。すべての Microsoft Entra ID 技術プロファイルには、入力要求要素が入力要求コレクションに 1 つだけ存在する必要があります。この技術プロファイルでは、ユーザーアカウントのキー識別子として email 要求が使用されます。ユーザーアカウントを一意に識別するために使用できるその他のキー識別子の詳細について確認してください。

ContosoCustomPolicy.XML ファイルで AAD-UserWrite 技術プロファイルを見つけ、次のコードを使用してその後に新しい技術プロファイルを追加します。

    <TechnicalProfile Id="AAD-UserRead">
        <DisplayName>Read user from Azure AD storage</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Read</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">false</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="givenName"/>
            <OutputClaim ClaimTypeReferenceId="surname"/>
            <OutputClaim ClaimTypeReferenceId="displayName"/>
        </OutputClaims>
    </TechnicalProfile>

新しい Microsoft Entra ID 技術プロファイル AAD-UserRead を追加しました。この技術プロファイルは、読み取り操作を実行し、InputClaim セクションに email を持つユーザーアカウントが見つかった場合に objectId、userPrincipalName、givenName、surname および displayName 要求を返すように構成されました。

手順 3 ‐ Microsoft Entra ID 技術プロファイルを使用する

UserInformationCollector セルフアサート技術プロファイルを使用してユーザーの詳細を収集した後、AAD-UserWrite 技術プロファイルを使用して Microsoft Entra ID ストレージにユーザーアカウントを書き込む必要があります。これを行うには、UserInformationCollector セルフアサート技術プロファイルの検証技術プロファイルとして AAD-UserWrite 技術プロファイルを使用します。

ContosoCustomPolicy.XML ファイルで UserInformationCollector 技術プロファイルを見つけ、AAD-UserWrite 技術プロファイルを検証技術プロファイルとして ValidationTechnicalProfiles コレクションに追加します。これは、CheckCompanyDomain 検証技術プロファイルの後に追加する必要があります。

ユーザー体験のオーケストレーション手順で AAD-UserRead 技術プロファイルを使用して、JWT トークンを発行する前にユーザーの詳細を読み取ります。

手順 4 - ClaimGenerator 技術プロファイルを更新する

ClaimGenerator 技術プロファイルを使用して、GenerateRandomObjectIdTransformation、CreateDisplayNameTransformation、CreateMessageTransformation の 3 つの要求変換を実行します。

ContosoCustomPolicy.XML ファイルで ClaimGenerator 技術プロファイルを見つけ、次のコードに置き換えます。

    <TechnicalProfile Id="UserInputMessageClaimGenerator">
        <DisplayName>User Message Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="message" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateMessageTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

    <TechnicalProfile Id="UserInputDisplayNameGenerator">
        <DisplayName>Display Name Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateDisplayNameTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

技術プロファイルが 2 つの別々の技術プロファイルに分割されました。 UserInputMessageClaimGenerator 技術プロファイルは、JWT トークンで要求として送信されるメッセージを生成します。 UserInputDisplayNameGenerator 技術プロファイルは、displayName 要求を生成します。 AAD-UserWrite 技術プロファイルがユーザーレコードを Microsoft Entra ID ストレージに書き込む前に、displayName 要求値が使用可能でなければなりません。新しいコードで、アカウントの作成後に objectId が作成され、Microsoft Entra ID によって返されるので GenerateRandomObjectIdTransformation を削除します。そのため、ポリシー内で自分自身で生成する必要はありません。

ContosoCustomPolicy.XML ファイルで UserInformationCollector セルフアサート技術プロファイルを見つけ、UserInputDisplayNameGenerator 技術プロファイルを検証技術プロファイルとして追加します。その後、UserInformationCollector 技術プロファイルの ValidationTechnicalProfiles コレクションは次のコードのようになります。

    <!--<TechnicalProfile Id="UserInformationCollector">-->
        <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="CheckCompanyDomain">
                <Preconditions>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
                        <Value>accountType</Value>
                        <Value>work</Value>
                        <Action>SkipThisValidationTechnicalProfile</Action>
                    </Precondition>
                </Preconditions>
            </ValidationTechnicalProfile>                        
            <ValidationTechnicalProfile ReferenceId="DisplayNameClaimGenerator"/>
            <ValidationTechnicalProfile ReferenceId="AAD-UserWrite"/>
        </ValidationTechnicalProfiles>
    <!--</TechnicalProfile>-->

AAD-UserWrite 技術プロファイルがユーザーレコードを Microsoft Entra ID ストレージに書き込む前に、displayName 要求値が使用可能でなければならないので、AAD-UserWrite の前に検証技術プロファイルを追加する必要があります。

手順 5 - ユーザー体験のオーケストレーション手順を更新する

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="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

オーケストレーション手順 4 で、AAD-UserRead 技術プロファイルを実行して、作成されたユーザーアカウントからユーザーの詳細 (JWT トークンに含まれる) を読み取ります。

message 要求を格納しないため、オーケストレーション手順 5 で UserInputMessageClaimGenerator を実行して、JWT トークンに含める message 要求を生成します。

手順 6 - ポリシーをアップロードする

「カスタムポリシーファイルをアップロードする」の手順に従って、ポリシーファイルをアップロードします。ポータルに既にあるファイルと同じ名前のファイルをアップロードする場合は、[カスタムポリシーが既に存在する場合は上書きします] を選択してください。

手順 7 - ポリシーをテストする

「カスタムポリシーをテストする」の手順に従って、カスタムポリシーをテストします。

ポリシーの実行が完了し、ID トークンを受け取ったら、ユーザーレコードが作成されていることを確認します。

グローバル管理者または特権ロール管理者のアクセス許可を使用して Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
[Azure サービス] で、 [Azure AD B2C] を選択します。または、検索ボックスを使用して検索し、 [Azure AD B2C] を選択します。
[管理] にある [ユーザー] を選択します。
作成したばかりのユーザーアカウントを見つけて選択します。アカウントプロファイルは、次のスクリーンショットのようになります。

AAD-UserWrite Microsoft Entra ID 技術プロファイルで、ユーザーが既に存在する場合は、エラーメッセージが表示されることを指定します。

同じ電子メールアドレスを使用して、カスタムポリシーをもう一度テストします。ポリシーが最後まで完了して ID トークンを発行するのではなく、次のスクリーンショットのようなエラーメッセージが表示されます。

A screenshot of error as account already exists.

Note

"パスワード" 要求の値は非常に重要な情報であるため、カスタムポリシーでの取り扱い方法には十分注意してください。同様の理由から、Azure AD B2C ではパスワード要求の値は特別な値として扱われます。セルフアサート技術プロファイルでパスワード要求の値を収集すると、その値は同じ技術プロファイル内、または同じセルフアサート技術プロファイルによって参照される検証技術プロファイル内でのみ使用できます。そのセルフアサート技術プロファイルの実行が完了し、別の技術プロファイルに移動すると、値は失われます。

ユーザーの電子メールアドレスを検証する

ユーザーアカウントの作成に使用する前に、ユーザーの電子メールを検証することをお勧めします。電子メールアドレスを検証するときは、アカウントが実際のユーザーによって作成されていることを確認します。また、正しい電子メールアドレスを使用してアカウントを作成していることを確認することもユーザーに役立ちます。

Azure AD B2C のカスタムポリシーでは、検証表示コントロールを使用して電子メールアドレスを検証できます。確認コードを電子メールに送信します。コードが送信されたら、ユーザーはメッセージを読んで、表示コントロールによって提供されたコントロールに確認コードを入力し、[コードの確認] ボタンを選択します。

表示コントロールは、特別な機能を備え、Azure Active Directory B2C (Azure AD B2C) バックエンドサービスと作用するユーザーインターフェイス要素です。これにより、ユーザーがバックエンドで検証技術プロファイルを呼び出すページで操作を実行できるようになります。ページに表示コントロールが表示され、セルフアサート技術プロファイルによって参照されます。

表示コントロールを使用して電子メールの検証を追加するには、次の手順に従います。

要求を宣言する

確認コードの保持に使用する要求を宣言する必要があります。

要求を宣言するには、ContosoCustomPolicy.XML ファイルで ClaimsSchema 要素を見つけ、次のコードを使用して verificationCode 要求を宣言します。

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="verificationCode">
            <DisplayName>Verification Code</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Enter your verification code</UserHelpText>
            <UserInputType>TextBox</UserInputType>
        </ClaimType>
    <!--</ClaimsSchema>-->

コードの送信と検証技術プロファイルを構成する

Azure AD B2C では、Microsoft Entra ID SSPR 技術プロファイルを使用して電子メールアドレスを検証します。この技術プロファイルでは、構成内容に応じて、コードを生成して電子メールアドレスに送信するか、コードを検証できます。

ContosoCustomPolicy.XML ファイルで ClaimsProviders 要素を見つけ、次のコードを使用して要求プロバイダーを追加します。

    <ClaimsProvider>
        <DisplayName>Azure AD self-service password reset (SSPR)</DisplayName>
        <TechnicalProfiles>
            <TechnicalProfile Id="AadSspr-SendCode">
            <DisplayName>Send Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">SendCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
            <TechnicalProfile Id="AadSspr-VerifyCode">
            <DisplayName>Verify Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">VerifyCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="verificationCode" />
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
        </TechnicalProfiles>
    </ClaimsProvider>

2 つの技術プロファイル AadSspr-SendCode と AadSspr-VerifyCode が構成されました。 AadSspr-SendCode は、コードを生成して、InputClaims セクションで指定された電子メールアドレスに送信します。一方、AadSspr-VerifyCode はコードを検証します。技術プロファイルのメタデータで実行するアクションを指定します。

表示コントロールを構成する

ユーザーの電子メールを検証できるように、電子メールの検証表示コントロールを構成する必要があります。構成した電子メールの検証表示コントロールは、ユーザーから電子メールを収集するために使用する電子メール表示要求に置き換わります。

表示コントロールを構成するには、次の手順に従います。

ContosoCustomPolicy.XML ファイルで BuildingBlocks セクションを見つけ、次のコードを使用して表示コントロールを子要素として追加します。

    <!--<BuildingBlocks>-->
        ....
        <DisplayControls>
            <DisplayControl Id="emailVerificationControl" UserInterfaceControlType="VerificationControl">
              <DisplayClaims>
                <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
                <DisplayClaim ClaimTypeReferenceId="verificationCode" ControlClaimType="VerificationCode" Required="true" />
              </DisplayClaims>
              <OutputClaims></OutputClaims>
              <Actions>
                <Action Id="SendCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-SendCode" />
                  </ValidationClaimsExchange>
                </Action>
                <Action Id="VerifyCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-VerifyCode" />
                  </ValidationClaimsExchange>
                </Action>
              </Actions>
            </DisplayControl>
        </DisplayControls> 
    <!--</BuildingBlocks>-->

表示コントロール emailVerificationControl が宣言されました。次の重要な部分に注目してください。

DisplayClaims - セルフアサート技術プロファイルと同様に、このセクションでは、表示コントロール内でユーザーから収集される要求のコレクションを指定します。
Actions - 表示コントロールによって実行されるアクションの順序を指定します。各アクションは、アクションの実行を担当する技術プロファイルを参照します。たとえば、SendCode は、コードを生成して電子メールアドレスに送信する AadSspr-SendCode 技術プロファイルを参照します。

ContosoCustomPolicy.XML ファイルで、UserInformationCollector セルフアサート技術プロファイルを見つけ、email 表示要求を emailVerificationControl 表示コントロールに置き換えます。

差出人:
```
    <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
```
移動先:
```
    <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
```
手順 6 と手順 7 の手順を使用して、ポリシーファイルをアップロードしてテストします。ここで、ユーザーアカウントを作成する前に、お使いの電子メールアドレスを検証する必要があります。

Microsoft Entra ID 技術プロファイルを使用してユーザーアカウントを更新する

新しいユーザーアカウントを作成するのではなく、ユーザーアカウントを更新するように Microsoft Entra ID 技術プロファイルを構成できます。これを行うには、次のコードを使用して、指定したユーザーアカウントがまだ Metadata コレクションに存在しない場合にエラーをスローするように、Microsoft Entra ID 技術プロファイルを設定します。 Operation を Write に設定する必要があります。

    <Item Key="Operation">Write</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>

カスタム属性を使用する

この記事では、組み込みのユーザープロファイル属性を使用してユーザーの詳細を格納する方法について説明しました。ただし、多くの場合、特定のシナリオを管理するために独自のカスタム属性を作成する必要があります。これを行うには、「Azure Active Directory B2C でカスタム属性を定義する」記事の手順に従います。

次のステップ

Azure Active Directory B2C カスタムポリシーを使用してローカルアカウントのサインアップおよびサインインフローを設定する方法を確認します。
カスタムポリシーでカスタム属性を定義する方法を確認します。
パスワードの有効期限をカスタムポリシーに追加する方法を確認します。
Microsoft Entra ID 技術プロファイルの詳細情報。

次の方法で共有

Azure Active Directory B2C カスタムポリシーを使用してユーザーアカウントを作成して読み取る

シナリオの概要

前提条件

手順 1 - 要求を宣言する

手順 2 ‐ Microsoft Entra ID 技術プロファイルを作成する

手順 3 ‐ Microsoft Entra ID 技術プロファイルを使用する

手順 4 - ClaimGenerator 技術プロファイルを更新する

手順 5 - ユーザー体験のオーケストレーション手順を更新する

手順 6 - ポリシーをアップロードする

手順 7 - ポリシーをテストする

ユーザーの電子メールアドレスを検証する

要求を宣言する

コードの送信と検証技術プロファイルを構成する

表示コントロールを構成する

Microsoft Entra ID 技術プロファイルを使用してユーザーアカウントを更新する

カスタム属性を使用する

次のステップ

フィードバック

フィードバック

その他のリソース

次の方法で共有

Azure Active Directory B2C カスタム ポリシーを使用してユーザー アカウントを作成して読み取る

シナリオの概要

前提条件

手順 1 - 要求を宣言する

手順 2 ‐ Microsoft Entra ID 技術プロファイルを作成する

手順 3 ‐ Microsoft Entra ID 技術プロファイルを使用する

手順 4 - ClaimGenerator 技術プロファイルを更新する

手順 5 - ユーザー体験のオーケストレーション手順を更新する

手順 6 - ポリシーをアップロードする

手順 7 - ポリシーをテストする

ユーザーの電子メール アドレスを検証する

要求を宣言する

コードの送信と検証技術プロファイルを構成する

表示コントロールを構成する

Microsoft Entra ID 技術プロファイルを使用してユーザー アカウントを更新する

カスタム属性を使用する

次のステップ

フィードバック

フィードバック

その他のリソース

Azure Active Directory B2C カスタムポリシーを使用してユーザーアカウントを作成して読み取る

ユーザーの電子メールアドレスを検証する

Microsoft Entra ID 技術プロファイルを使用してユーザーアカウントを更新する