كيفية: الترحيل من Access Control Service
تحذير
يخص هذا المحتوى نقطة النهاية الأقدم لإصدار Microsoft Azure Active Directory v1.0. استخدم النظام الأساسي للهويات في Microsoft للمشاريع الجديدة.
Microsoft Azure Access Control Service (ACS)، هي خدمة من Azure Active Directory (Azure AD)، سيتم إيقافها اعتبارًا من 7 نوفمبر، 2018 يجب ترحيل التطبيقات والخدمات التي تستخدم Access Control حاليًا بشكل كامل إلى آلية مصادقة مختلفة بحلول ذلك الوقت. توضح هذه المقالة توصيات للعملاء الحاليين، كما تخطط إلى إيقاف استخدامك لعنصر Access Control. إن كنت حاليًا لا تستخدم Access Control، فلن تحتاج أن تقوم بأي فعل.
نظرة عامة
Access Control هي خدمة مصادقة سحابية توفر طريقة سهلة للمصادقة على المستخدمين وتصرح لهم بالوصول إلى تطبيقات الويب والخدمات الخاصة بك. هي تسمح بميزات عديدة من المصادقة والتصريح لتؤخذ في الاعتبار وذلك من التعليمات البرمجية الخاصة بك. يتم استخدام Access Control في المقام الأول من قبل المطورين والمهندسين المعماريين من عملاء Microsoft.NET وASP.NET وتطبيقات الويب، وخدمات الويب الخاصة بـ Windows Communication Foundation (WCF) .
يمكن تقسيم حالات الاستخدام لـ Access Control إلى ثلاث فئات رئيسية:
- المصادقة على خدمات سحابية معينة من Microsoft، بما في ذلك Azure Service Bus وDynamics CRM. تحصل تطبيقات العميل على رموز مميزة من Access Control للمصادقة على هذه الخدمات لتنفيذ إجراءات مختلفة.
- إضافة المصادقة إلى تطبيقات الويب، سواء المخصصة والمعبئة مسبقًا (مثل SharePoint). باستخدام مصادقة "خاملة" لـ Access Control، يمكن لتطبيقات الويب دعم تسجيل الدخول باستخدام حساب Microsoft (Live ID سابقا)، ومع حسابات من Google وFacebook وYahoo وAzure AD وخدمات Active Directory Federation Services (AD FS).
- تأمين خدمات ويب مخصصة باستخدام الرموز المميزة الصادرة عن Access Control. باستخدام المصادقة "النشطة"، يمكن لخدمات الويب التأكد من السماح بالوصول فقط إلى العملاء المعروفين الذين قاموا بالمصادقة باستخدام Access Control.
كلٌ من أولئك يستخدم حالات واستراتيجيات الترحيل الموصى بها في الأقسام التالية.
تحذير
في معظم الحالات، يلزم إجراء تغييرات كبيرة في التعليمات البرمجية لترحيل التطبيقات والخدمات الموجودة إلى التقنيات الأحدث. نوصيك بالبدء فورًا في تخطيط الترحيل وتنفيذه لتجنب أي انقطاع محتمل أو توقف.
يحتوي Access Control على المكونات التالية:
- خدمة الرمز المميز الآمن (STS)، والتي تتلقى طلبات المصادقة وتصدر رموز الأمان في المقابل.
- بوابة Azure الكلاسيكية، حيث تقوم بإنشاء namespaces Access Control وتمكينها وتعطيلها.
- بوابة إدارة Access Control منفصل، حيث تقوم بتخصيص Access Control namespaces وتكوينها.
- خدمة إدارة، والتي يمكنك استخدامها لأتمتة وظائف البوابات.
- مشغل قاعدة تحويل الرمز المميز، والذي يمكنك استخدامه لتعريف منطق معقد لمعالجة تنسيق إخراج الرموز المميزة التي تسبب مشكلات في التحكم في الوصول.
لاستخدام هذه المكونات، يجب إنشاء عنصر أو اكثر من Access Control إلى namespaces. احد namespace هو نموذج مخصص لعنصر Access Control تتصل به التطبيقات والخدمات. يتم عزل namespace من كافة عملاء Access Control الآخرين. يستخدم عملاء التحكم في الوصول الآخرين الـ namespaces الخاصة بهم. يحتوي الـ namespace في Access Control على محدد موقع معلومات مخصص يبدو كما يلي:
https://<mynamespace>.accesscontrol.windows.net
تتم جميع الاتصالات مع الـ STS وعمليات الإدارة في عنوان URL هذا. يمكنك استخدام مسارات مختلفة لأغراض مختلفة. لتحديد ما إذا كانت التطبيقات أو الخدمات الخاصة بك تستخدم Access Control، مراقبة أي حركة مرور https://< namespace> sscontrol.windows.net. تتم معالجة أي حركة مرور إلى عنوان URL هذا بواسطة Access Control، ويجب إيقافها.
الاستثناء من هذا هو أي حركة مرور إلى https://accounts.accesscontrol.windows.net. تتم معالجة حركة المرور إلى عنوان URL هذا من قبل خدمة مختلفة ولا تتأثر بتوقف Access Control.
لمزيد من المعلومات حول Access Control، راجع قسم Access Control Service 2.0 (مؤرشفة) .
تعرف على التطبيقات التي ستتأثر
اتبع الخطوات الواردة في هذا القسم لمعرفة أي من تطبيقاتك ستتأثر بإيقاف ACS.
تنزيل وتركيب ACS PowerShell:
انتقل إلى معرض PowerShell وقم بتنزيل Acs.Namespaces.
تثبيت الوحدة النمطية عن طريق تشغيل
Install-Module -Name Acs.Namespacesالحصول على قائمة بجميع الأوامر الممكنة:
Get-Command -Module Acs.Namespacesللحصول على تعليمات حول أمر معين، عليك تشغيل ما يلي:
Get-Help [Command-Name] -Fullنظرًا إلى أن
[Command-Name]يمثل اسم الأمر ACS.
رتب ACS namespace
توصيل Azure Access Control Service باستخدام cmdlet وتعيين الاتصال-AcsAccount.
قد تحتاج إلى تشغيل
Set-ExecutionPolicy -ExecutionPolicy Bypassقبل أن تتمكن من تنفيذ الأوامر ويكون المسؤول عن تلك الاشتراكات من أجل تنفيذ الأوامر.سرد اشتراكات Azure المتوفرة واشتراك باستخدام Get-AcsSubscription. cmdlet.
اسرد مساحات أسماء ACS باستخدام Get-AcsNamespace. cmdlet
التحقق من التطبيقات التي ستتأثر
استخدم مساحة الاسم من الخطوة السابقة ثم انتقل إلى
https://<namespace>.accesscontrol.windows.netعلى سبيل المثال، إذا كان أحد namespaces هو contoso-test، فانتقل إلى
https://contoso-test.accesscontrol.windows.netضمن علاقات الثقة، حدد تطبيقات جهة الاعتماد للاطلاع على قائمة التطبيقات التي ستتأثر بإيقاف ACS.
كرر الخطوات 1-2 لأي مساحة namespace(s) ACS أخرى لديك.
جدول الإيقاف
اعتبارًا من نوفمبر 2017، يتم دعم جميع مكونات Access Control وتشغيلها بالكامل. القيد الوحيد هو أنه لا يمكنك إنشاء namespaces جديدة لـ Access Control عبر البوابة الكلاسيكية لـ Azure.
فيما يلي جدولة إيقاف مكونات التحكم في الوصول:
- نوفمبر2017 تجربة مسؤول بوابة Azure AD الكلاسيكية تم إيقافها. عند هذه النقطة، إدارة namespace لـ Access Control متوفرة في URL مخصص جديدة:
https://manage.windowsazure.com?restoreClassic=true. استخدم URL هذا لعرض namespaces الموجودة لديك وتمكين مساحات الأسماء وتعطيلها وحذف namespaces إذا اخترت ذلك. - 2 أبريل 2018 : تم سحب البوابة الكلاسيكية Azure تمامًا، ما يعني أن إدارة namespace الخاصة بـ Access Control لم تعد متوفرة عبر أي URL. عند هذه النقطة، لا يمكنك تعطيل أو تمكين أو حذف أو تعداد namespaces. ومع ذلك، فإن بوابة إدارة الـAccess Control ستكون تعمل بكامل طاقتها وتقع في
https://<namespace>.accesscontrol.windows.net. تستمر كافة مكونات Access Control الأخرى في العمل بشكل طبيعي. - 7 نوفمبر 2018 تم إيقاف تشغيل كافة مكونات Access Control بشكل دائم. يتضمن هذا بوابة إدارة Access Control وخدمة الإدارة وSTS ومحرك قاعدة تحويل الرمز المميز. عند هذه النقطة، تفشل أي طلبات أرسلت إلى Access Control (الموجود
<namespace>.accesscontrol.windows.netفي). كان يجب ترحيل جميع التطبيقات والخدمات الموجودة إلى تقنيات أخرى قبل هذا الوقت بوقت كبير.
ملاحظة
تقوم السياسة بتعطيل namespaces التي لم تطلب رمزًا مميزًا لفترة من الوقت. اعتبارًا من أوائل سبتمبر 2018، تبلغ هذه الفترة الزمنية حاليًا 14 يومًا من عدم النشاط، ولكن سيتم تقصيرها إلى 7 أيام من الخمول في الأسابيع المقبلة. إذا كانت لديك مساحات أسماء التحكم في الوصول معطلة حاليًا، يمكنك تنزيل وتثبيت ACS PowerShell لإعادة تمكين namespace(s).
استراتيجيات الترحيل
تصف المقاطع التالية توصيات عالية المستوى الترحيل من Acces Control إلى تقنيات Microsoft الأخرى.
عملاء خدمات Microsoft السحابية
كل خدمة سحابية من Microsoft التي تقبل الرموز المميزة التي يتم إصدارها بواسطة Access Control الآن يعتمد نموذج بديل واحد على الأقل من المصادقة. تختلف آلية المصادقة الصحيحة لكل خدمة عن الأخرى. نوصي بأن تقوم بالإشارة إلى الوثائق المحددة لكل خدمة للحصول على إرشادات رسمية. للتيسير، يتم توفير كل مجموعة من الوثائق هنا:
| الخدمة | الإرشاد |
|---|---|
| ناقل خدمة Azure | الترحيل إلى توقيعات الوصول المشتركة |
| Azure Service Bus Relay | ترحيل إلى توقيعات وصول مشتركة |
| Azure Managed Cache | ترحيل إلى Azure Cache لـ Redis |
| Azure DataMarket | الترحيل إلى واجهات برمجة تطبيقات خدمات الذكاء الاصطناعي Azure |
| خدمات Biztalk | تعرف على المزيد بشأن ميزة Logic Apps في Azure App Service. |
| خدمات الوسائط Azure | الترحيل إلى مصادقة Azure AD |
| Azure Backup | قم بتثبيت عامل Azure Backup |
عملاء SharePoint
SharePoint 2013 و2016 SharePoint استخدم عملاء SharePoint Online منذ فترة طويلة ACS لأغراض المصادقة في السحابة والأماكن والسيناريوهات المهجنة. ستتأثر بعض ميزات SharePoint وحالات الاستخدام بإيقاف ACS، في حين لن يتأثر البعض الآخر. يلخص الجدول أدناه إرشادات الترحيل لبعض من أكثر ميزات SharePoint شيوعًا التي تستفيد من ACS:
| الميزة | الإرشاد |
|---|---|
| مصادقة المستخدمين من Azure AD | في السابق، لم يكن Azure AD يدعم رموز SAML 1.1 المميزة المطلوبة من قبل SharePoint للمصادقة، وتم استخدام ACS كوسيط جعل SharePoint تتوافق مع تنسيقات الرمز المميز لـAzure AD. الآن، يمكنك توصيل SharePoint مباشرة إلى Azure AD باستخدام Azure AD App Gallery SharePoint على تطبيق محلي. |
| مصادقة التطبيق & مصادقة من server-to-server في SharePoint في أماكن العمل | لا تتأثر بإيقاف ACS; لا تغييرات ضرورية. |
| التصريح بثقة مخفضة لـSharePoint add-ins (مستضافة عند الموفر ومستضافة عند SharePoint) | لا تتأثر بإيقاف ACS; لا تغييرات ضرورية. |
| البحث السحابي المهجن عند SharePoint | لا تتأثر بإيقاف ACS; لا تغييرات ضرورية. |
تطبيقات ويب التي تستخدم المصادقة الخاملة
بالنسبة إلى تطبيقات الويب التي تستخدم Access Control لمصادقة المستخدم، يوفر Access Control الميزات والقدرات التالية لمطوري تطبيقات الويب والمهندسين المعماريين:
- التكامل العميق مع Windows Identity Foundation (WIF).
- الاتحاد مع حسابات Google وFacebook وYahoo وAzure Active Directory، والحسابات AD FS، وحسابات Microsoft.
- دعم بروتوكولات المصادقة التالية: OAuth 2.0 Draft 13 WS-Trust واتحاد خدمات ويب (WS-Federation).
- دعم تنسيقات الرمز المميز التالية: رمز ويب JSON (JWT) وSAML 1.1 وSAML 2.0 وSimple Web Token (SWT).
- تجربة اكتشاف عالم المنزل، المدمجة في WIF، التي تسمح للمستخدمين باختيار نوع الحساب الذي يستخدمونه لتسجيل الدخول. تتم استضافة هذه التجربة من قبل تطبيق الويب وهي قابلة للتخصيص بالكامل.
- تحويل الرمز المميز الذي يسمح بتخصيص غني للمطالبات التي تلقاها تطبيق الويب من Access Control، بما في ذلك:
- تمر من خلال المطالبات من مقدمي الهوية.
- إضافة مطالبات مخصصة إضافية.
- منطق إذا كان بسيطًا لإصدار المطالبات في ظل ظروف معينة.
لسوء الحظ، لا توجد خدمة واحدة توفر كل هذه القدرات المكافئة. يجب تقييم إمكانات التحكم في الوصول التي تحتاجها، ثم الاختيار بين استخدام معرف Microsoft Entra أو Azure Active Directory B2C (Azure AD B2C) أو خدمة مصادقة سحابية أخرى.
الترحيل إلى معرف Microsoft Entra
المسار الذي يجب مراعاته هو دمج تطبيقاتك وخدماتك مباشرة مع معرف Microsoft Entra. معرف Microsoft Entra هو موفر الهوية المستند إلى السحابة لحسابات العمل أو المؤسسة التعليمية من Microsoft. معرف Microsoft Entra هو موفر الهوية ل Microsoft 365 وAzure وأكثر من ذلك بكثير. ويوفر قدرات مصادقة مماثلة لعنصر Access Control، ولكنه لا يدعم جميع ميزات Access Control.
المثال الأساسي هو الاتحاد مع مقدمي الهوية الاجتماعية، مثل Facebook وGoogle وYahoo. إذا سجل المستخدمون الدخول باستخدام هذه الأنواع من بيانات الاعتماد، Microsoft Entra المعرف ليس الحل لك.
لا يدعم معرف Microsoft Entra أيضا بالضرورة نفس بروتوكولات المصادقة تماما مثل التحكم في الوصول. على سبيل المثال، على الرغم من أن كل من التحكم في الوصول ومعرف Microsoft Entra يدعمان OAuth، إلا أن هناك اختلافات دقيقة بين كل تنفيذ. تتطلب تطبيقات مختلفة تعديل التعليمات البرمجية كجزء من الترحيل.
ومع ذلك، يوفر معرف Microsoft Entra العديد من المزايا المحتملة لعملاء التحكم في الوصول. وهو يدعم في الأصل حسابات العمل أو المدرسة من Microsoft المستضافة في السحابة، والتي يستخدمها عادة عملاء Access Control.
يمكن أيضا توحيد مستأجر Microsoft Entra إلى مثيل واحد أو أكثر من Active Directory محلي عبر AD FS. بهذه الطريقة، يمكن للتطبيق مصادقة المستخدمين والمستخدمين السحابيين الذين تتم استضافتهم محليًا. كما يدعم بروتوكول WS-Federation، ما يجعل من السهل نسبيًا الاندماج مع تطبيق ويب باستخدام WIF.
يقارن الجدول التالي ميزات التحكم في الوصول ذات الصلة بتطبيقات الويب بتلك الميزات المتوفرة في معرف Microsoft Entra.
على مستوى عال، من المحتمل أن يكون معرف Microsoft Entra هو الخيار الأفضل للترحيل إذا سمحت للمستخدمين بتسجيل الدخول فقط باستخدام حسابات العمل أو المؤسسة التعليمية في Microsoft.
| الإمكانية | دعم Access Control | دعم معرف Microsoft Entra |
|---|---|---|
| أنواع الحسابات | ||
| بيانات حساب العمل أو المدرسة من Microsoft | مدعوم | مدعوم |
| حسابات من Windows Server Active Directory and وAD FS | - مدعوم عبر الاتحاد مع مستأجر Microsoft Entra - مدعومة عن طريق الاتحاد المباشر مع AD FS |
مدعوم فقط عبر الاتحاد مع مستأجر Microsoft Entra |
| حسابات من أنظمة إدارة الهوية المؤسسية الأخرى | - ممكن عبر الاتحاد مع مستأجر Microsoft Entra - مدعومة عن طريق الاتحاد المباشر مع AD FS |
ممكن عبر الاتحاد مع مستأجر Microsoft Entra |
| حسابات Microsoft للاستخدام الشخصي | مدعوم | مدعوم عبر بروتوكول OAuth Microsoft Entra v2.0، ولكن ليس عبر أي بروتوكولات أخرى |
| حسابات Facebook وGoogle وYahoo | مدعوم | غير معتمد على الإطلاق |
| البروتوكولات وتوافق SDK | ||
| WIF | مدعوم | تتوفر إرشادات مدعومة، ولكن محدودة |
| WS-Federation | مدعوم | مدعوم |
| OAuth 2.0 | دعم Draft 13 | دعم RFC 6749، أحدث المواصفات |
| WS-Trust | مدعوم | غير مدعوم |
| تنسيقات الرمز المميز | ||
| JWT | مدعم كنسخة تجريبية | مدعوم |
| SAML 1.1 | مدعوم | معاينة |
| SAML 2.0 | مدعوم | مدعوم |
| SWT | مدعوم | غير مدعوم |
| التخصيصات | ||
| اكتشاف عالم المنزل القابل للتخصيص / واجهة مستخدم account-picking | رمز قابل للتنزيل يمكن دمجه في التطبيقات | غير مدعوم |
| Upload شهادات توقيع الرمز المميز المخصصة | مدعوم | مدعوم |
| تخصيص المطالبات في الرموز المميزة | - تمر من خلال المطالبات من مقدمي الهوية. - الحصول على رمز الوصول من موفر الهوية كمطالبة - إصدار مطالبات الناتج استنادًا إلى قيم مطالبات المدخلات - إصدار مطالبات الإخراج بقيم ثابتة |
- لا يمكن أن تمر من خلال مطالبات من مقدمي الهوية الاتحادية - الحصول على رمز الوصول من موفر الهوية ك مطالبة - لا يمكن إصدار مطالبات الإخراج على أساس قيم مطالبات المدخلات - إصدار مطالبات الإخراج بقيم ثابتة - يمكن إصدار مطالبات الإخراج استنادا إلى خصائص المستخدمين الذين تمت مزامنتهم مع معرف Microsoft Entra |
| Automation | ||
| أتمتة مهام التكوين والإدارة | مدعومة عبر Access Control Management Service | باستخدام واجهة برمجة تطبيقات Microsoft Graph |
إذا قررت أن معرف Microsoft Entra هو أفضل مسار ترحيل لتطبيقاتك وخدماتك، فيجب أن تكون على دراية بطريقتين لدمج تطبيقك مع معرف Microsoft Entra.
لاستخدام WS-Federation أو WIF للتكامل مع معرف Microsoft Entra، نوصي باتباع النهج الموضح في تكوين تسجيل الدخول الأحادي الموحد لتطبيق غير معرض. تشير المقالة إلى تكوين معرف Microsoft Entra لتسجيل الدخول الأحادي المستند إلى SAML، ولكنها تعمل أيضا على تكوين WS-Federation. يتطلب اتباع هذا الأسلوب ترخيص معرف Microsoft Entra P1 أو P2. ولهذه المقاربة ميزتان:
- يمكنك الحصول على المرونة الكاملة لتخصيص الرمز المميز Microsoft Entra. يمكنك تخصيص المطالبات التي يتم إصدارها بواسطة معرف Microsoft Entra لمطابقة المطالبات الصادرة عن Access Control. وهذا يشمل بشكل خاص user ID أو Name Identifier. للاستمرار في تلقي معرفات مستخدم متسقة للمستخدمين بعد تغيير التقنيات، تأكد من أن معرفات المستخدم الصادرة عن معرف Microsoft Entra تتطابق مع تلك الصادرة عن Access Control.
- يمكنك تكوين شهادة توقيع رمز مميز خاصة بالتطبيق الخاص بك، ومع العمر الذي تتحكم فيه.
ملاحظة
يتطلب هذا الأسلوب ترخيص معرف Microsoft Entra P1 أو P2. إذا كنت من عملاء Access Control وكنت بحاجة إلى ترخيص مميز لإعداد تسجيل دخول واحد لتطبيق ما، فاتصل بنا. سنكون سعداء لتوفير تراخيص المطور لاستخدامها.
نهج بديل هو اتباع نموذج التعليمات البرمجية هذا ، والذي يعطي إرشادات مختلفة قليلاً لإعداد WS-Federation. نموذج التعليمات البرمجية هذا لا يستخدم WIF، ولكن بدلاً من ذلك، ASP.NET 4.5 OWIN الوسيطة. ومع ذلك، فإن إرشادات تسجيل التطبيق صالحة للتطبيقات التي تستخدم WIF، ولا تتطلب ترخيص معرف Microsoft Entra P1 أو P2.
إذا اخترت هذا الأسلوب، فستحتاج إلى فهم تمرير مفتاح التوقيع في معرف Microsoft Entra. يستخدم هذا الأسلوب مفتاح التوقيع العمومي Microsoft Entra لإصدار الرموز المميزة. بشكل افتراضي، لا يقوم WIF تلقائيًا بتحديث مفاتيح التوقيع. عندما يقوم Microsoft Entra ID بتدوير مفاتيح التوقيع العمومية الخاصة به، يجب أن يكون تنفيذ WIF جاهزا لقبول التغييرات. لمزيد من المعلومات، راجع معلومات مهمة حول توقيع تمرير المفتاح في معرف Microsoft Entra.
إذا كان بإمكانك التكامل مع معرف Microsoft Entra عبر بروتوكولات OpenID Connect أو OAuth، نوصي بالقيام بذلك. لدينا وثائق وإرشادات شاملة حول كيفية دمج معرف Microsoft Entra في تطبيق الويب الخاص بك المتوفر في دليل مطوري Microsoft Entra لدينا.
ترحيل إلى Azure Active Directory B2C
مسار الترحيل الآخر للاعتبار هو Azure AD B2C. Azure AD B2C هي خدمة مصادقة سحابية تسمح للمطورين، مثل Access Control، بالاستعانة بمصادر خارجية لمنطق المصادقة وإدارة الهوية لخدمة سحابية. إنها خدمة مدفوعة الأجر (مع مستويات مجانية وممتازة) مصممة للتطبيقات التي تواجه المستهلك التي قد تحتوي على ما يصل إلى الملايين من المستخدمين النشطين
مثل Access Control، واحدة من أكثر الميزات جاذبية من Azure AD B2C هو أنه يدعم العديد من أنها أنواع مختلفة من الحسابات. باستخدام Azure AD B2C، يمكنك تسجيل دخول المستخدمين باستخدام حساب Microsoft الخاص بهم، أو حسابات فيسبوك أو Google أو LinkedIn أو GitHub أو Yahoo وغيرها. يدعم Azure AD B2C أيضًا "الحسابات المحلية" أو username وكلمات المرور التي يقوم المستخدمون بإنشائها خصيصًا للتطبيق الخاص بك. يوفر Azure AD B2C أيضًا قابلية غنية يمكنك استخدامها لتخصيص تدفقات تسجيل الدخول.
ومع ذلك، لا يدعم Azure AD B2C اتساع بروتوكولات المصادقة وتنسيقات الرمز المميز التي قد يحتاجها عملاء Access Control. لا يمكنك أيضًا استخدام Azure AD B2C للحصول على رموز مميزة والاستعلام للحصول على معلومات إضافية حول المستخدم من موفر الهوية أو Microsoft أو غير ذلك.
يقارن الجدول التالي ميزات التحكم في الوصول ذات الصلة بتطبيقات الويب مع الميزات المتوفرة في Azure AD. على مستوى عال، من المحتمل أن يكون Azure AD B2C هو الخيار الصحيح لترحيلك إذا كان التطبيق الخاص بك يواجه المستهلك، أو إذا كان يدعم العديد من أنواع الحسابات المختلفة.
| الإمكانية | دعم Access Control | دعم Azure AD B2C |
|---|---|---|
| أنواع الحسابات | ||
| بيانات حساب العمل أو المدرسة من Microsoft | مدعوم | مدعومة من خلال سياسات مخصصة |
| حسابات من Windows Server Active Directory and وAD FS | \- مدعومة عن طريق الاتحاد المباشر مع AD FS | معتمدة عبر اتحاد SAML باستخدام نهج مخصصة |
| حسابات من أنظمة إدارة الهوية المؤسسية الأخرى | مدعومة عن طريق الاتحاد المباشر من خلال WS-Federation | معتمدة عبر اتحاد SAML باستخدام نهج مخصصة |
| حسابات Microsoft للاستخدام الشخصي | مدعوم | مدعوم |
| حسابات Facebook وGoogle وYahoo | مدعوم | الـ Facebook وGoogle بدعم أصلاً، Yahoo بدعم عبر OpenID الاتصال الاتحاد باستخدام سياسات مخصصة |
| البروتوكولات وتوافق SDK | ||
| Windows مؤسسة الهوية (WIF) | مدعوم | غير مدعوم |
| WS-Federation | مدعوم | غير مدعوم |
| OAuth 2.0 | دعم Draft 13 | دعم RFC 6749، أحدث المواصفات |
| WS-Trust | مدعوم | غير مدعوم |
| تنسيقات الرمز المميز | ||
| JWT | مدعم كنسخة تجريبية | مدعوم |
| SAML 1.1 | مدعوم | غير مدعوم |
| SAML 2.0 | مدعوم | غير مدعوم |
| SWT | مدعوم | غير مدعوم |
| التخصيصات | ||
| اكتشاف عالم المنزل القابل للتخصيص / واجهة مستخدم account-picking | رمز قابل للتنزيل يمكن دمجه في التطبيقات | واجهة مستخدم قابلة للتخصيص بالكامل عبر CSS مخصصة |
| Upload شهادات توقيع الرمز المميز المخصصة | مدعوم | مفاتيح توقيع مخصصة، وليست شهادات، مدعومة عبر نهج مخصصة |
| تخصيص المطالبات في الرموز المميزة | - تمر من خلال المطالبات من مقدمي الهوية. - الحصول على رمز الوصول من موفر الهوية كمطالبة - إصدار مطالبات الناتج استنادًا إلى قيم مطالبات المدخلات - إصدار مطالبات الإخراج بقيم ثابتة |
- يمكن أن تمر من خلال المطالبات من مقدمي الهوية ؛ سياسات مخصصة مطلوبة لبعض المطالبات - لا يمكن الحصول على رمز الوصول من موفر الهوية كـ مطالبة - يمكن إصدار مطالبات الإخراج على أساس قيم مطالبات الإدخال عن طريق سياسات متخصصة - يمكن إصدار مطالبات الإخراج مع القيم الثابتة عن طريق سياسات متخصصة |
| Automation | ||
| أتمتة مهام التكوين والإدارة | مدعومة عبر Access Control Management Service | - إنشاء المستخدمين المسموح باستخدام Microsoft Graph API - لا يمكن إنشاء مستأجرين B2C أو تطبيقات، أو سياسات برمجيًا |
إذا قررت أن Azure AD B2C هو أفضل مسار ترحيل للتطبيقات والخدمات، فابدأ بالموارد التالية:
ترحيل إلى Ping الهوية أو Auth0
في بعض الحالات، قد تجد أن معرف Microsoft Entra Azure AD B2C غير كافيين لاستبدال التحكم بالوصول في تطبيقات الويب الخاصة بك دون إجراء تغييرات كبيرة في التعليمات البرمجية. قد تتضمن بعض الأمثلة الشائعة ما يلي:
- تطبيقات الويب التي تستخدم WIF أو WS-Federation لتسجيل الدخول مع موفري الهوية الاجتماعية مثل Google أو Facebook.
- تطبيقات ويب التي تقوم بإجراء اتحاد مباشر إلى موفر هوية المؤسسة عبر بروتوكول WS-Federation.
- تطبيقات الويب التي تتطلب رمز الوصول الصادر عن موفر الهوية الاجتماعية (مثل Google أو Facebook) كـمطالبة في الرموز المميزة الصادرة عن التحكم في الوصول.
- لا يمكن إعادة إنتاج تطبيقات الويب ذات قواعد تحويل الرمز المميز المعقدة التي Microsoft Entra المعرف أو Azure AD B2C.
- تطبيقات الويب متعددة المستأجرين التي تستخدم ACS لإدارة الاتحاد مركزيًا للعديد من موفري الهوية المختلفين
في هذه الحالات، قد تحتاج إلى النظر في ترحيل تطبيق الويب الخاص بك إلى خدمة مصادقة سحابية أخرى. نوصي باستكشاف الخيارات التالية. كل من الخيارات التالية توفر قدرات مشابهة لعنصر Access Control:
Auth0 هي خدمة هوية سحابية مرنة أنشأت إرشادات ترحيل عالية المستوى لعملاء Access Control، وتدعم تقريبًا كل ميزة تقوم بها ACS.
Ping Identity يقدم حلين مشابهين لـ ACS. PingOne هي خدمة هوية سحابية تدعم العديد من الميزات نفسها مثل ACS، وPingFederate هو منتج هوية مماثل في أماكن العمل يوفر المزيد من المرونة. راجع إرشادات إيقاف ACS لـ Ping للحصول على مزيد من التفاصيل حول استخدام هذه المنتجات.
هدفنا في العمل مع Ping Identity وAuth0 هو التأكد من أن جميع عملاء Access Control لديهم مسار ترحيل لتطبيقاتهم وخدماتهم يقلل من حجم العمل المطلوب للانتقال من Access Control.
خدمات ويب التي تستخدم المصادقة النشطة
لخدمات الويب التي يتم تأمينها باستخدام الرموز المميزة الصادرة عن Access Control، يوفر Access Control الميزات والقدرات التالية:
- القدرة على تسجيل هوية خدمة واحدة أو أكثر في مساحة الاسم Access Control namespace. يمكن استخدام هويات الخدمة لطلب الرموز المميزة.
- دعم لبروتوكولي OAuth WRAP وOAuth 2.0 Draft 13 لطلب الرموز المميزة، باستخدام الأنواع التالية من بيانات الاعتماد:
- كلمة مرور بسيطة تم إنشاؤها لهوية الخدمة
- SWT موقعة باستخدام مفتاح متماثل أو شهادة X509
- رمز SAML الذي تم إصداره من قبل موفر هوية موثوق به (عادة، مثيل AD FS)
- دعم لتنسيقات الرمز المميز التالية: JWT وSAML 1.1 وSAML 2.0 وSWT.
- قواعد تحويل رمزية بسيطة.
عادة ما يتم استخدام هويات الخدمة في "التحكم في الوصول" لتطبيق مصادقة الملقم إلى الخادم.
الترحيل إلى معرف Microsoft Entra
توصيتنا لهذا النوع من تدفق المصادقة هي الترحيل إلى معرف Microsoft Entra. Microsoft Entra المعرف هو موفر الهوية المستند إلى السحابة لحسابات العمل أو المؤسسة التعليمية من Microsoft. معرف Microsoft Entra هو موفر الهوية ل Microsoft 365 وAzure وأكثر من ذلك بكثير.
يمكنك أيضا استخدام معرف Microsoft Entra للمصادقة من خادم إلى خادم باستخدام Microsoft Entra تنفيذ منحة بيانات اعتماد عميل OAuth. يقارن الجدول التالي قدرات التحكم في الوصول في المصادقة من خادم إلى خادم مع تلك المتوفرة في معرف Microsoft Entra.
| الإمكانية | دعم Access Control | دعم معرف Microsoft Entra |
|---|---|---|
| كيفية تسجيل خدمة ويب | إنشاء جهة معتمدة في مدخل إدارة Access Control | إنشاء تطبيق ويب Microsoft Entra في مدخل Microsoft Azure |
| كيفية تسجيل عميل | إنشاء هوية خدمة في بوابة إدارة Access Control | إنشاء تطبيق ويب Microsoft Entra آخر في مدخل Microsoft Azure |
| البروتوكول المستخدم | - بروتوكول OAuth WRAP منح بيانات اعتماد عميل OAuth 2.0 Draft 13 |
منح بيانات اعتماد عميل OAuth 2.0 |
| تحديث أساليب المصادقة | - كلمة مرور بسيطة - SWT موقعة - رمز SAML من موفر هوية المتحدة |
- كلمة مرور بسيطة - JWT موقعة |
| تنسيقات الرمز المميز | معيار JWT SAML 1.1 SAML 2.0 SWT |
JWT فقط |
| وحدة التحويل | المطالبات المخصصة. - بسيطة إذا ثم المطالبة منطق الإصدار |
المطالبات المتخصصة. |
| أتمتة مهام التكوين والإدارة | مدعومة عبر Access Control Management Service | باستخدام واجهة برمجة تطبيقات Microsoft Graph |
للحصول على إرشادات حول تطبيق سيناريوهات server-to-server راجع الموارد التالية:
- قسم الخدمة إلى الخدمة في دليل مطور Microsoft Entra
- نموذج التعليمات البرمجية Daemon باستخدام بيانات اعتماد عميل كلمة المرور البسيطة
- نموذج التعليمات البرمجية Daemon باستخدام بيانات اعتماد عميل الشهادة
ترحيل إلى Ping الهوية أو Auth0
في بعض الحالات، قد تجد أن بيانات اعتماد العميل Microsoft Entra وتنفيذ منح OAuth غير كافية لاستبدال التحكم في الوصول في البنية الخاصة بك دون تغييرات التعليمات البرمجية الرئيسية. قد تتضمن بعض الأمثلة الشائعة ما يلي:
- مصادقة من خادم إلى خادم باستخدام تنسيقات الرمز المميز غير JWTs.
- مصادقة من Server-to-server باستخدام رمز إدخال موفر هوية خارجي.
- المصادقة من خادم إلى خادم مع قواعد تحويل الرمز المميز التي لا يمكن إعادة إنتاج Microsoft Entra ID.
في هذه الحالات، قد تحتاج إلى النظر في ترحيل تطبيق الويب الخاص بك إلى خدمة مصادقة سحابية أخرى. نوصي باستكشاف الخيارات التالية. كل من الخيارات التالية توفر قدرات مشابهة لعنصر Access Control:
Auth0 هي خدمة هوية سحابية مرنة أنشأت إرشادات ترحيل عالية المستوى لعملاء Access Control، وتدعم تقريبًا كل ميزة تقوم بها ACS.
Ping Identity يقدم حلين مشابهين لـ ACS. PingOne هي خدمة هوية سحابية تدعم العديد من الميزات نفسها مثل ACS، وPingFederate هو منتج هوية مماثل في أماكن العمل يوفر المزيد من المرونة. راجع إرشادات إيقاف ACS لـ Ping للحصول على مزيد من التفاصيل حول استخدام هذه المنتجات.
هدفنا في العمل مع Ping Identity وAuth0 هو التأكد من أن جميع عملاء Access Control لديهم مسار ترحيل لتطبيقاتهم وخدماتهم يقلل من حجم العمل المطلوب للانتقال من Access Control.
مصادقة Passthrough
للمصادقة عبر التمرير مع تحويل الرمز المميز إجباريًا، لا توجد تقنية من Microsoft مكافئة إلى ACS. إذا كان هذا هو ما يحتاجه عملاؤك، فقد يكون Auth0 هو الذي يوفر أقرب حل تقريبي.
الأسئلة والمخاوف والتعليقات
نحن ندرك أن العديد من عملاء Access Control لن يجدوا مسار ترحيل واضحًا بعد قراءة هذه المقالة. قد تحتاج إلى بعض المساعدة أو التوجيه في تحديد الخطة الصحيحة. إذا كنت ترغب في مناقشة سيناريوهات وأسئلة الترحيل، يرجى ترك تعليق على هذه الصفحة.