إنشاء حساب مستخدم وقراءته باستخدام نهج Azure Active Directory B2C المخصص

مقالة
01/11/2024

تم إنشاء Azure Active Directory B2C (Azure AD B2C) على معرف Microsoft Entra، وبالتالي فإنه يستخدم تخزين معرف Microsoft Entra لتخزين حسابات المستخدمين. يأتي ملف تعريف مستخدم دليل Azure AD B2C مع مجموعة مضمنة من السمات، مثل الاسم المحدد واللقب والمدينة والرمز البريدي ورقم الهاتف، ولكن يمكنك توسيع ملف تعريف المستخدم باستخدام السمات المخصصة الخاصة بك دون الحاجة إلى مخزن بيانات خارجي.

يمكن لنهجك المخصص الاتصال بتخزين معرف Microsoft Entra باستخدام ملف التعريف الفني لمعرف Microsoft Entra لتخزين معلومات المستخدم أو تحديثها أو حذفها. في هذه المقالة، ستتعلم كيفية تكوين مجموعة من ملفات التعريف الفنية لمعرف Microsoft Entra لتخزين حساب مستخدم وقراءته قبل إرجاع رمز JWT المميز.

نظرة عامة على السيناريو

في مقالة النهج المخصص لاستدعاء واجهة برمجة تطبيقات REST باستخدام نهج Azure Active Directory B2C، نقوم بتجميع معلومات من المستخدم، والتحقق من صحة البيانات، وتسمى واجهة برمجة تطبيقات REST، وأخيرا إرجاع JWT دون تخزين حساب مستخدم. يجب علينا تخزين معلومات المستخدم حتى لا نفقد المعلومات بمجرد انتهاء تنفيذ النهج. هذه المرة، بمجرد جمع معلومات المستخدم والتحقق من صحتها، نحتاج إلى تخزين معلومات المستخدم في تخزين Azure AD B2C، ثم القراءة قبل إرجاع رمز JWT المميز. تظهر العملية الكاملة في الرسم التخطيطي التالي.

A flowchart of creating a user account in Azure AD.

المتطلبات الأساسية

إذا لم يكن لديك واحد بالفعل ، فأنشئ مستأجر Azure AD B2C مرتبطًا باشتراك Azure الخاص بك.
تسجيل تطبيق ويب، وتمكين تفعيل المنحة الضمنية لرمز المعرّف. بالنسبة إلى عنوان URI لإعادة التوجيه، استخدم https://jwt.ms.
يجب أن يكون لديك Visual Studio Code (VS Code) مثبتا على الكمبيوتر الخاص بك.
أكمل الخطوات في استدعاء واجهة برمجة تطبيقات REST باستخدام نهج Azure Active Directory B2C المخصص. هذه المقالة هي جزء من إنشاء سلسلة إرشاد إرشادية خاصة بالنهج المخصصة وتشغيلها.

إشعار

هذه المقالة هي جزء من سلسلة دليل كيفية إنشاء وتشغيل النهج المخصصة الخاصة بك في Azure Active Directory B2C. نوصي ببدء تشغيل هذه السلسلة من المقالة الأولى.

الخطوة 1 - الإعلان عن المطالبات

تحتاج إلى الإعلان عن مطالبتين إضافيتين، 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

تحتاج إلى تكوين ملفي تعريف تقنيين لمعرف Microsoft Entra. يكتب ملف تعريف تقني واحد تفاصيل المستخدم في تخزين معرف Microsoft Entra، والآخر يقرأ حساب مستخدم من تخزين معرف Microsoft Entra.

في ContosoCustomPolicy.XML الملف، حدد موقع عنصر ClaimsProviders ، وأضف موفر مطالبات جديدا باستخدام التعليمات البرمجية أدناه. يحتفظ موفر المطالبات هذا بملفات التعريف الفنية لمعرف Microsoft Entra:
```
    <ClaimsProvider>
        <DisplayName>Azure AD Technical Profiles</DisplayName>
        <TechnicalProfiles>
            
        </TechnicalProfiles>
    </ClaimsProvider>
```

في موفر المطالبات الذي أنشأته للتو، أضف ملف تعريف تقني لمعرف Microsoft Entra باستخدام التعليمات البرمجية التالية:

    <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، AAD-UserWrite. تحتاج إلى تدوين الأجزاء المهمة التالية من ملف التعريف التقني:

العملية: تحدد العملية الإجراء الذي سيتم تنفيذه، في هذه الحالة، كتابة. تعرف على المزيد حول العمليات الأخرى في موفر تقني لمعرف Microsoft Entra.
المطالبات المستمرة: يحتوي عنصر PersistedClaims على كافة القيم التي يجب تخزينها في تخزين معرف Microsoft Entra.
InputClaims: يحتوي عنصر InputClaims على مطالبة، والتي تستخدم للبحث عن حساب في الدليل، أو إنشاء حساب جديد. يجب أن يكون هناك عنصر مطالبة إدخال واحد بالضبط في مجموعة مطالبات الإدخال لجميع ملفات التعريف الفنية لمعرف Microsoft Entra. يستخدم ملف التعريف الفني هذا مطالبة البريد الإلكتروني ، كمعرف مفتاح لحساب المستخدم. تعرف على المزيد حول المعرفات الرئيسية الأخرى التي يمكنك استخدامها لتعريف حساب مستخدم بشكل فريد.

في 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، AAD-UserRead. لقد قمنا بتكوين ملف التعريف الفني هذا لتنفيذ عملية قراءة، وإرجاع objectIduserPrincipalNamegivenNamesurname مطالبات و و displayName إذا تم العثور على حساب مستخدم مع email في InputClaim القسم .

الخطوة 3 - استخدام ملف التعريف الفني لمعرف Microsoft Entra

بعد أن نجمع تفاصيل المستخدم باستخدام UserInformationCollector ملف التعريف الفني المؤكد ذاتيا، نحتاج إلى كتابة حساب مستخدم في تخزين معرف Microsoft Entra باستخدام AAD-UserWrite ملف التعريف الفني. للقيام بذلك، استخدم AAD-UserWrite ملف التعريف الفني كملف تعريف تقني للتحقق من الصحة في UserInformationCollector ملف التعريف الفني المؤكد ذاتيا.

في ContosoCustomPolicy.XML الملف، حدد موقع UserInformationCollector ملف التعريف الفني، ثم أضف AAD-UserWrite ملف التعريف الفني كملف تعريف تقني للتحقق من الصحة في ValidationTechnicalProfiles المجموعة. تحتاج إلى إضافة هذا بعد CheckCompanyDomain ملف التعريف الفني للتحقق من الصحة.

سنستخدم AAD-UserRead ملف التعريف الفني في خطوات تنسيق رحلة المستخدم لقراءة تفاصيل المستخدم قبل إصدار رمز JWT المميز.

الخطوة 4 - تحديث ملف التعريف الفني ل ClaimGenerator

نستخدم ملف التعريف الفني لتنفيذ ثلاثة تحويلات للمطالبات، GenerateRandomObjectIdTransformation وCreateDisplayNameTransformation وCreateMessageTransformation.ClaimGenerator

في 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>

لقد قمنا بتقسيم الملف الفني إلى ملفي تعريف تقنيين منفصلين. ينشئ ملف التعريف الفني UserInputMessageClaimGenerator الرسالة المرسلة كمطالبة في رمز JWT المميز. ينشئ ملف التعريف الفني UserInputDisplayNameGenerator المطالبةdisplayName. displayName يجب أن تكون قيمة المطالبة متوفرة قبل AAD-UserWrite أن يكتب ملف التعريف الفني سجل المستخدم في تخزين معرف Microsoft Entra. في التعليمات البرمجية الجديدة، نقوم بإزالة GenerateRandomObjectIdTransformation حيث objectId يتم إنشاء وإرجاع بواسطة معرف Microsoft Entra بعد إنشاء حساب، لذلك لا نحتاج إلى إنشائه بأنفسنا ضمن النهج.

في 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 حيث displayName يجب أن تكون قيمة المطالبة متوفرة قبل AAD-UserWrite أن يكتب ملف التعريف الفني سجل المستخدم في تخزين معرف Microsoft Entra.

الخطوة 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 لإنشاء المطالبة message للتضمين على رمز JWT المميز.

الخطوة 6 - نهج التحميل

اتبع الخطوات الواردة في تحميل ملف نهج مخصص لتحميل ملف النهج الخاص بك. إذا كنت تقوم بتحميل ملف بنفس اسم الملف الموجود بالفعل في المدخل، فتأكد من تحديد الكتابة فوق النهج المخصص إذا كان موجودا بالفعل.

الخطوة 7 - اختبار النهج

اتبع الخطوات الواردة في اختبار النهج المخصص لاختبار النهج المخصص.

بعد انتهاء تنفيذ النهج، وتلقي الرمز المميز للمعرف، تحقق من إنشاء سجل المستخدم:

سجّل الدخول إلى مدخل Azure باستخدام أذونات المسؤول العام أو مسؤول الدور المتميز.
إذا كان لديك حق الوصول إلى عدة مستأجرين، فحدد رمز الإعدادات في القائمة العلوية للتبديل إلى مستأجر Azure AD B2C من قائمة Directories + subscriptions.
من خدمات Azure، حدد Azure AD B2C. أو استخدم مربع البحث للبحث عن Azure AD B2Cوتحديده.
ضمن "Manage"، حدد "Users".
حدد موقع حساب المستخدم الذي أنشأته للتو، وحدده. يبدو ملف تعريف الحساب مشابها للقطة الشاشة أدناه:

AAD-UserWrite في ملف التعريف الفني لمعرف Microsoft Entra، نحدد أنه إذا كان المستخدم موجودا بالفعل، فإننا نرفع رسالة خطأ.

اختبر النهج المخصص مرة أخرى باستخدام عنوان البريد الإلكتروني نفسه. بدلا من تنفيذ النهج حتى الاكتمال لإصدار رمز مميز للمعرف، يجب أن تشاهد رسالة خطأ مشابهة للقطة الشاشة أدناه.

A screenshot of error as account already exists.

إشعار

قيمة المطالبة بكلمة المرور هي جزء مهم جدا من المعلومات، لذا كن حذرا جدا في كيفية التعامل معها في نهجك المخصص. لسبب مماثل، يعامل Azure AD B2C قيمة مطالبة كلمة المرور كقيمة خاصة. عند جمع قيمة المطالبة بكلمة المرور في ملف التعريف الفني المؤكد ذاتيا، تتوفر هذه القيمة فقط داخل نفس ملف التعريف الفني أو ضمن ملفات تعريف فنية للتحقق من الصحة المشار إليها بواسطة نفس ملف التعريف الفني المؤكد ذاتيا. بمجرد اكتمال تنفيذ ملف التعريف الفني المؤكد ذاتيا، والانتقال إلى ملف تعريف تقني آخر، يتم فقدان القيمة.

التحقق من عنوان البريد الإلكتروني للمستخدم

نوصي بالتحقق من البريد الإلكتروني للمستخدم قبل استخدامه لإنشاء حساب مستخدم. عند التحقق من عناوين البريد الإلكتروني، تأكد من إنشاء الحسابات من قبل مستخدمين حقيقيين. يمكنك أيضا مساعدة المستخدمين على التأكد من أنهم يستخدمون عناوين بريدهم الإلكتروني الصحيحة لإنشاء حساب.

يوفر نهج Azure AD B2C المخصص طريقة للتحقق من عنوان البريد الإلكتروني باستخدام التحكم في عرض التحقق. يمكنك إرسال رمز تحقق إلى البريد الإلكتروني. بعد إرسال التعليمات البرمجية، يقرأ المستخدم الرسالة، ويدخل رمز التحقق في عنصر التحكم الذي يوفره عنصر تحكم العرض، ويحدد زر التحقق من التعليمات البرمجية .

التحكم في العرض هو عنصر واجهة مستخدم له وظائف خاصة ويتفاعل مع خدمة Microsoft Azure Active Directory 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>

لقد قمنا بتكوين ملفي تعريف تقنيين 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 ملف التعريف الفني المؤكد ذاتيا واستبدل مطالبة عرض البريد الإلكتروني لعرض emailVerificationControl عنصر التحكم:

من:
```
    <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
```
إلى:
```
    <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
```
استخدم الإجراء في الخطوة 6 والخطوة 7 لتحميل ملف النهج واختباره. هذه المرة، يجب التحقق من عنوان بريدك الإلكتروني قبل إنشاء حساب مستخدم.

تحديث حساب المستخدم باستخدام ملف التعريف الفني لمعرف Microsoft Entra

يمكنك تكوين ملف تعريف تقني لمعرف Microsoft Entra لتحديث حساب مستخدم بدلا من محاولة إنشاء حساب جديد. للقيام بذلك، قم بتعيين ملف التعريف الفني لمعرف Microsoft Entra لطرح خطأ إذا لم يكن حساب المستخدم المحدد موجودا بالفعل في Metadata المجموعة باستخدام التعليمات البرمجية التالية. يجب تعيين العملية إلى كتابة:

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

استخدام السمات المخصصة

في هذه المقالة، تعلمت كيفية تخزين تفاصيل المستخدم باستخدام سمات ملف تعريف المستخدم المضمنة. ومع ذلك، غالبا ما تحتاج إلى إنشاء سمات مخصصة خاصة بك لإدارة السيناريو الخاص بك. للقيام بذلك، اتبع الإرشادات الواردة في مقالة تعريف السمات المخصصة في Azure Active Directory B2C .

الخطوات التالية

تعرف على كيفية إعداد تدفق الاشتراك وتسجيل الدخول لحساب محلي باستخدام نهج Azure Active Directory B2C المخصص.
تعرف على كيفية تعريف السمات المخصصة في نهجك المخصص.
تعرف على كيفية إضافة انتهاء صلاحية كلمة المرور إلى النهج المخصص.
تعرف على المزيد حول ملف التعريف الفني لمعرف Microsoft Entra.

مشاركة عبر