كيفية: الترحيل من 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 | ترحيل إلى 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 هي خدمة هوية سحابية مرنة أنشأت إرشادات ترحيل عالية المستوى لعملاء 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.
- قواعد تحويل رمزية بسيطة.
عادة ما يتم استخدام هويات الخدمة في "التحكم في الوصول" لتطبيق مصادقة الملقم إلى الخادم.
ترحيل إلى 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 راجع الموارد التالية:
- قسم Service-to-Service في دليل مطور Azure AD
- نموذج التعليمات البرمجية Daemon باستخدام بيانات اعتماد عميل كلمة المرور البسيطة
- نموذج التعليمات البرمجية Daemon باستخدام بيانات اعتماد عميل الشهادة
ترحيل إلى Ping الهوية أو Auth0
في بعض الحالات، قد تجد أن بيانات اعتماد العميل Azure AD وتطبيق منحة OAuth غير كافية لاستبدال Access Control في البنية الخاصة بك دون تغييرات كبيرة في التعليمات البرمجية. قد تتضمن بعض الأمثلة الشائعة ما يلي:
- مصادقة من خادم إلى خادم باستخدام تنسيقات الرمز المميز غير JWTs.
- مصادقة من Server-to-server باستخدام رمز إدخال موفر هوية خارجي.
- مصادقة من Server-to-server مع قواعد تحويل الرمز المميز التي لا يمكن لـ Azure AD من إعادة إنتاجها.
في هذه الحالات، قد تحتاج إلى النظر في ترحيل تطبيق الويب الخاص بك إلى خدمة مصادقة سحابية أخرى. نوصي باستكشاف الخيارات التالية. كل من الخيارات التالية توفر قدرات مشابهة لعنصر 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 لن يجدوا مسار ترحيل واضحًا بعد قراءة هذه المقالة. قد تحتاج إلى بعض المساعدة أو التوجيه في تحديد الخطة الصحيحة. إذا كنت ترغب في مناقشة سيناريوهات وأسئلة الترحيل، يرجى ترك تعليق على هذه الصفحة.