Azure Active Directory B2C カスタム ポリシーを使用してユーザー アカウントを作成して読み取る
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 ストレージに格納してから、読み取る必要があります。 次の図はそのプロセス全体を示したものです。
前提条件
まだ持っていない場合は、お使いの 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> <!--You'll add you Azure AD Technical Profiles here--> </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 トークンを発行するのではなく、次のスクリーンショットのようなエラー メッセージが表示されます。
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 でカスタム属性を定義する」記事の手順に従います。