كيفية: الترحيل من 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:

  1. انتقل إلى معرض PowerShell وقم بتنزيل Acs.Namespaces.

  2. تثبيت الوحدة النمطية عن طريق تشغيل

    Install-Module -Name Acs.Namespaces
    
  3. الحصول على قائمة بجميع الأوامر الممكنة:

    Get-Command -Module Acs.Namespaces
    

    للحصول على تعليمات حول أمر معين، عليك تشغيل ما يلي:

     Get-Help [Command-Name] -Full
    

    نظرًا إلى أن[Command-Name] يمثل اسم الأمر ACS.

رتب ACS namespace

  1. توصيل Azure Access Control Service باستخدام cmdlet وتعيين الاتصال-AcsAccount.

    قد تحتاج إلى تشغيل Set-ExecutionPolicy -ExecutionPolicy Bypass قبل أن تتمكن من تنفيذ الأوامر ويكون المسؤول عن تلك الاشتراكات من أجل تنفيذ الأوامر.

  2. سرد اشتراكات Azure المتوفرة واشتراك باستخدام Get-AcsSubscription. cmdlet.

  3. اسرد مساحات أسماء ACS باستخدام Get-AcsNamespace. cmdlet

التحقق من التطبيقات التي ستتأثر

  1. استخدم مساحة الاسم من الخطوة السابقة ثم انتقل إلى https://<namespace>.accesscontrol.windows.net

    على سبيل المثال، إذا كان أحد namespaces هو contoso-test، فانتقل إلى https://contoso-test.accesscontrol.windows.net

  2. ضمن علاقات الثقة، حدد تطبيقات جهة الاعتماد للاطلاع على قائمة التطبيقات التي ستتأثر بإيقاف ACS.

  3. كرر الخطوات 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 ترحيل إلى Cognitive Services APIs
خدمات 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 على تطبيق محلي.
مصادقة التطبيق & مصادقة من خادم إلى خادم في 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، بما في ذلك:
    • تمر من خلال المطالبات من مقدمي الهوية.
    • إضافة مطالبات مخصصة إضافية.
    • منطق إذا كان بسيطًا لإصدار المطالبات في ظل ظروف معينة.

لسوء الحظ، لا توجد خدمة واحدة توفر كل هذه القدرات المكافئة. يجب تقييم قدرات Access Control التي تحتاجها، ثم الاختيار بين استخدام Azure Active Directory، Azure Active Directory B2C (Azure AD B2C) أو خدمة مصادقة سحابية أخرى.

ترحيل إلى Azure Active Directory

وهناك مسار يجب مراعاته هو دمج التطبيقات والخدمات مباشرة مع Azure AD. Azure AD هو موفر هوية سحابية المستندة إلى حسابات العمل أو المدرسة في Microsoft. Azure AD هو موفر الهوية Microsoft 365 وAzure وغير ذلك الكثير. ويوفر قدرات مصادقة مماثلة لعنصر Access Control، ولكنه لا يدعم جميع ميزات Access Control.

المثال الأساسي هو الاتحاد مع مقدمي الهوية الاجتماعية، مثل Facebook وGoogle وYahoo. إذا كان المستخدمون يسجلون الدخول باستخدام هذه الأنواع من بيانات الاعتماد، إذن Azure AD ليس الحل بالنسبة إليك.

لا يدعم Azure AD أيضًا بالضرورة بروتوكولات المصادقة نفسها تمامًا مثل Access Control. على سبيل المثال، على الرغم من أن كلا من Access Control وAzure AD يدعمان OAuth، فإن هناك اختلافات دقيقة بين كل تطبيق. تتطلب تطبيقات مختلفة تعديل التعليمات البرمجية كجزء من الترحيل.

ومع ذلك، يوفر Azure AD العديد من المزايا المحتملة لعملاء Access Control. وهو يدعم في الأصل حسابات العمل أو المدرسة من Microsoft المستضافة في السحابة، والتي يستخدمها عادة عملاء Access Control.

يمكن أيضًا أن يتم تحالف مستأجر Azure AD مع مثيل واحد أو أكثر من Active Directory المحلي عبر AD FS. بهذه الطريقة، يمكن للتطبيق مصادقة المستخدمين والمستخدمين السحابيين الذين تتم استضافتهم محليًا. كما يدعم بروتوكول WS-Federation، ما يجعل من السهل نسبيًا الاندماج مع تطبيق ويب باستخدام WIF.

يقارن الجدول التالي ميزات التحكم في الوصول ذات الصلة بتطبيقات الويب مع الميزات المتوفرة في Azure AD.

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

الإمكانية دعم Access Control دعم Azure AD
أنواع الحسابات
بيانات حساب العمل أو المدرسة من Microsoft مدعوم مدعوم
حسابات من Windows Server Active Directory and وAD FS - مدعومة عبر الاتحاد مع مستأجر Azure AD
- مدعومة عن طريق الاتحاد المباشر مع AD FS
معتمد فقط عبر الاتحاد مع مستأجر Azure AD
حسابات من أنظمة إدارة الهوية المؤسسية الأخرى - مدعومة عبر الاتحاد مع مستأجر Azure AD
- مدعومة عن طريق الاتحاد المباشر مع AD FS
\- مدعومة عبر الاتحاد مع مستأجر Azure AD
حسابات Microsoft للاستخدام الشخصي مدعوم معتمد عبر بروتوكول OAuth Azure AD 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 شهادات توقيع الرمز المميز المخصصة مدعوم مدعوم
تخصيص المطالبات في الرموز المميزة - تمر من خلال المطالبات من مقدمي الهوية.
- الحصول على رمز الوصول من موفر الهوية كمطالبة
- إصدار مطالبات الناتج استنادًا إلى قيم مطالبات المدخلات
- إصدار مطالبات الإخراج بقيم ثابتة
- لا يمكن أن تمر من خلال مطالبات من مقدمي الهوية الاتحادية
- الحصول على رمز الوصول من موفر الهوية ك مطالبة
- لا يمكن إصدار مطالبات الإخراج على أساس قيم مطالبات المدخلات
- إصدار مطالبات الإخراج بقيم ثابتة
- يمكن إصدار مطالبات الإخراج على أساس خصائص المستخدمين مزامن إلى Azure AD
Automation
أتمتة مهام التكوين والإدارة مدعومة عبر Access Control Management Service باستخدام واجهة برمجة تطبيقات Microsoft Graph

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

لاستخدام WS-Federation أو WIF للتكامل مع Azure AD، نوصي باتباع النهج الموضح في تكوين تسجيل الدخول الموحد لتطبيق غير معرض تشير المقالة إلى تكوين Azure AD لتسجيل الدخول الأحادي المستند إلى SAML، ولكنها تعمل أيضًا لتكوين WS-Federation. يتطلب اتباع هذا النهج ترخيص Azure AD Premium ولهذه المقاربة ميزتان:

  • يمكنك الحصول على المرونة الكاملة لتخصيص الرمز المميز لـ Azure AD. يمكنك تخصيص المطالبات التي يتم إصدارها بواسطة Azure AD لمطابقة المطالبات التي يتم إصدارها بواسطة Access Control. وهذا يشمل بشكل خاص user ID أو Name Identifier. لمتابعة تلقي IDentifiers للمستخدمين الخاصين بك بعد تغيير التقنيات تأكد من أن معرفات المستخدم الصادرة عن Azure AD تطابق تلك الصادرة عن التحكم في الوصول.
  • يمكنك تكوين شهادة توقيع رمز مميز خاصة بالتطبيق الخاص بك، ومع العمر الذي تتحكم فيه.

ملاحظة

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

نهج بديل هو اتباع نموذج التعليمات البرمجية هذا ، والذي يعطي إرشادات مختلفة قليلاً لإعداد WS-Federation. نموذج التعليمات البرمجية هذا لا يستخدم WIF، ولكن بدلاً من ذلك، ASP.NET 4.5 OWIN الوسيطة. ومع ذلك، فإن إرشادات تسجيل التطبيق صالحة للتطبيقات التي تستخدم WIF، ولا تتطلب ترخيصًا Premium Azure AD.

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

إذا كنت تستطيع الاندماج مع Azure AD عبر بروتوكولات OpenID الاتصال أو OAuth، فإننا نوصي بذلك. لدينا وثائق وإرشادات شاملة حول كيفية دمج Azure AD في تطبيق الويب الخاص بك المتوفر في دليل مطوري Azure AD

ترحيل إلى 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

في بعض الحالات، قد تجد أن Azure AD وAzure AD B2C غير كافيين لاستبدال Access Control في تطبيقات الويب دون إجراء تغييرات رئيسية في التعليمات البرمجية. قد تتضمن بعض الأمثلة الشائعة ما يلي:

  • تطبيقات الويب التي تستخدم WIF أو WS-Federation لتسجيل الدخول مع موفري الهوية الاجتماعية مثل Google أو Facebook.
  • تطبيقات ويب التي تقوم بإجراء اتحاد مباشر إلى موفر هوية المؤسسة عبر بروتوكول WS-Federation.
  • تطبيقات الويب التي تتطلب رمز الوصول الصادر عن موفر الهوية الاجتماعية (مثل Google أو Facebook) كـمطالبة في الرموز المميزة الصادرة عن التحكم في الوصول.
  • تطبيقات الويب مع قواعد تحويل الرمز المميز المعقدة التي لا يمكن إعادة إنتاج Azure AD أو Azure AD B2C.
  • تطبيقات الويب متعددة المستأجرين التي تستخدم ACS لإدارة الاتحاد مركزيًا للعديد من موفري الهوية المختلفين

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

تظهر هذه الصورة شعار Auth0

Auth0 هي خدمة هوية سحابية مرنة أنشأت إرشادات ترحيل عالية المستوى لعملاء Access Control، وتدعم تقريبًا كل ميزة تقوم بها ACS.

تظهر هذه الصورة شعار Ping Identity

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.
  • قواعد تحويل رمزية بسيطة.

عادة ما يتم استخدام هويات الخدمة في "التحكم في الوصول" لتطبيق مصادقة الملقم إلى الخادم.

ترحيل إلى Azure Active Directory

توصيتنا لهذا النوع من تدفق المصادقة هو ترحيل إلى Azure Active Directory Azure AD هو موفر هوية سحابية المستندة إلى حسابات العمل أو المدرسة في Microsoft. Azure AD هو موفر الهوية Microsoft 365 وAzure وغير ذلك الكثير.

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

الإمكانية دعم Access Control دعم Azure AD
كيفية تسجيل خدمة ويب إنشاء جهة معتمدة في مدخل إدارة Access Control إنشاء تطبيق Azure AD على الويب في بوابة Azure
كيفية تسجيل عميل إنشاء هوية خدمة في بوابة إدارة Access Control إنشاء تطبيق Azure AD على الويب في بوابة 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 راجع الموارد التالية:

ترحيل إلى Ping الهوية أو Auth0

في بعض الحالات، قد تجد أن بيانات اعتماد العميل Azure AD وتطبيق منحة OAuth غير كافية لاستبدال Access Control في البنية الخاصة بك دون تغييرات كبيرة في التعليمات البرمجية. قد تتضمن بعض الأمثلة الشائعة ما يلي:

  • مصادقة من خادم إلى خادم باستخدام تنسيقات الرمز المميز غير JWTs.
  • مصادقة من Server-to-server باستخدام رمز إدخال موفر هوية خارجي.
  • مصادقة من Server-to-server مع قواعد تحويل الرمز المميز التي لا يمكن لـ Azure AD من إعادة إنتاجها.

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

تظهر هذه الصورة شعار Auth0

Auth0 هي خدمة هوية سحابية مرنة أنشأت إرشادات ترحيل عالية المستوى لعملاء Access Control، وتدعم تقريبًا كل ميزة تقوم بها ACS.

تعرض هذه الصورة شعار Ping IdentityPing Identity يقدم حلين مشابهين لـ ACS. PingOne هي خدمة هوية سحابية تدعم العديد من الميزات نفسها مثل ACS، وPingFederate هو منتج هوية مماثل في أماكن العمل يوفر المزيد من المرونة. راجع إرشادات إيقاف ACS لـ Ping للحصول على مزيد من التفاصيل حول استخدام هذه المنتجات.

هدفنا في العمل مع Ping Identity وAuth0 هو التأكد من أن جميع عملاء Access Control لديهم مسار ترحيل لتطبيقاتهم وخدماتهم يقلل من حجم العمل المطلوب للانتقال من Access Control.

مصادقة Passthrough

للمصادقة عبر التمرير مع تحويل الرمز المميز إجباريًا، لا توجد تقنية من Microsoft مكافئة إلى ACS. إذا كان هذا هو ما يحتاجه عملاؤك، فقد يكون Auth0 هو الذي يوفر أقرب حل تقريبي.

الأسئلة والمخاوف والتعليقات

نحن ندرك أن العديد من عملاء Access Control لن يجدوا مسار ترحيل واضحًا بعد قراءة هذه المقالة. قد تحتاج إلى بعض المساعدة أو التوجيه في تحديد الخطة الصحيحة. إذا كنت ترغب في مناقشة سيناريوهات وأسئلة الترحيل، يرجى ترك تعليق على هذه الصفحة.