M365Con 2027 – مؤتمر مجاني عبر الإنترنت · 11–22 Jan 2027 · 120 sessions→ m365con.net

المدونة · Mirko Peters

جزر الهوية: التنقل بين رموز ACS وAzure AD

By ·

أهلاً بعودتكم إلى المدونة! إن كنتم قد وقفتم يوماً أمام خارطة طريق المنتج تتساءلون عما إذا كان ينبغي تضمين ميزات الاتصال المخصصة مباشرةً في تطبيق الويب، أم دفع المستخدمين إلى البيئة المؤسسية لـ Microsoft Teams، فأنتم لستم وحدكم. فاختيار بنية اتصال غير مناسبة قد يؤدي إلى دَين تقني كبير، وفواتير ترخيص غير متوقعة، واحتكاك في تهيئة المستخدمين يعيق التبني بالكامل. ولمساعدتكم على فهم هذا المشهد، نتعمق في

Automatically translated with AI from the original post. Read the English original

▶ BLOGIdentity Islands:Navigating ACS Tokens……M365.FM
Titelbild: Identity Islands: Navigating ACS Tokens vs Azure AD

أهلاً بعودتكم إلى المدونة! إن كنتم قد وقفتم يوماً أمام خارطة طريق المنتج تتساءلون عما إذا كان ينبغي تضمين ميزات الاتصال المخصصة مباشرةً في تطبيق الويب، أم دفع المستخدمين إلى البيئة المؤسسية لـ Microsoft Teams، فأنتم لستم وحدكم. فاختيار بنية اتصال غير مناسبة قد يؤدي إلى دَين تقني كبير، وفواتير ترخيص غير متوقعة، واحتكاك في تهيئة المستخدمين يعيق التبني بالكامل. ولمساعدتكم على فهم هذا المشهد، نتعمق في الفروق الجوهرية بين إدارة الرموز الصادرة من التطبيق في Azure Communication Services (ACS) والاعتماد على Azure AD لمصادقة الموظفين، وكيفية ربط نظامي الهوية المنفصلين عند بناء بنى الاتصال.

يستكمل هذا المقال المعمّق حلقتنا الصوتية الأخيرة. إن أردتم شرحاً صوتياً شاملاً لهذه المقايضات الواقعية، فتفضلوا بالاطلاع على Azure Communication Services vs Teams APIs.

لمن هذا المقال

  • مدراء المنتجات الذين يطلقون محادثات العملاء والمكالمات ضمن تطبيقات الويب أو الجوال
  • مهندسو المنصات الذين يتعاملون مع Microsoft 365 وAzure AD وGraph
  • مدراء الهندسة الذين لا يرغبون في مفاجآت تتعلق بالامتثال أو التراخيص

النقاط الرئيسية

  • الهوية تحدد كل شيء. ACS مرنة للمستخدمين الخارجيين أو المجهولين، بينما تتوافق Teams APIs مع Azure AD للمستخدمين الداخليين، لكنها تضيف احتكاكاً في تهيئة الضيوف.
  • الحضور عامل فاصل. تكشف Teams APIs حالة الحضور الغنية عبر Graph، بينما لا يملك ACS حضوراً أصلياً في Teams، لذا توقعوا مزامنة مخصصة أو تنازلات.
  • التكافؤ في المحادثة مهم. تعكس Teams ميزات العميل (السلاسل، والتفاعلات، والبطاقات)، أما ACS فخفيفة وقابلة للتضمين، لكنكم ستبنون تجربة المستخدم الناقصة بأنفسكم.
  • للاستدعاء حدود. التشغيل البيني بين اجتماعات ACS وTeams ليس أصلياً، وانضمام الضيوف عبر Teams يتطلب غالباً دعوات ضيوف من Azure AD.
  • الامتثال مقابل التكلفة. ترث Teams إمكانات الامتثال في Microsoft 365 (مثل eDiscovery وDLP والحجز القانوني)، لكنها تخضع لمتطلبات E3/E5 والميزات المتقدمة وواقع التقييد، أما ACS فتعتمد على الدفع حسب الاستخدام، لكنكم تتولون التخزين والاستبقاء والتدقيق.
  • النهج الهجين قوي، لكنه مكلف تشغيلياً. توقعوا وجود طبقة وسيطة لربط الهويات، وتحويل الرسائل، ومزامنة الحضور، وفرض السياسات.

إرشادات سريعة: هل تختارون ACS أم Teams أم الهجين؟

  • اختاروا ACS إذا كنتم بحاجة إلى توسع B2C سلس، ومحادثات مجهولة أو للضيوف، وسرعة في حزم SDK للجوال والويب، وتحكماً دقيقاً في التكلفة، وكنتم مستعدين لتولي دورة حياة الرموز، والتخزين، والاستبقاء، والتدقيق.
  • اختاروا Teams APIs إذا كان مستخدموكم الأساسيون موظفين يحتاجون إلى الحضور، والمحادثات المتسلسلة، والانضمام إلى الاجتماعات، والامتثال المدمج ضمن نهج المستأجر، مع قبول أعباء التراخيص وأذونات Graph.
  • اتجهوا إلى النهج الهجين عندما يتعين عليكم عرض المحادثات الخارجية على الوكلاء الداخليين في Teams، أو دمج المحادثات والمكالمات العامة مع امتثال Teams وميزة الحضور.

مطبات واقعية (من الميدان)

  • جزيرتا هوية: رموز ACS في مواجهة كائنات Azure AD ، ما يستلزم طبقة ربط.
  • ضريبة تجربة الضيف: دعوات ضيوف AAD تبطئ تدفقات B2C السريعة.
  • عدم تطابق الحضور: لا يستطيع ACS "رؤية" أن ممثل المبيعات مشغول في اجتماع Teams.
  • معالجة المرفقات: تتوقع Teams وجود OneDrive وSharePoint، بينما يعتمد ACS غالباً على blobs والروابط.
  • حدود خفية: قد يسبب تقييد Graph ونقاط النهاية المتقدمة مشكلات عند التوسع.
  • عبء الامتثال على ACS: أنتم تتولون التشفير، والاستبقاء، وسجلات التدقيق، وضمانات المنطقة الجغرافية.

تفصيل ميزة بميزة

الهوية والوصول

  • ACS: مستخدمون ورموز صادرة من التطبيق، مناسبة جداً لزوار المواقع والمتعاقدين؛ وأنتم تتولون المصادقة متعددة العوامل، والإلغاء، والانتهاء.
  • Teams APIs: تسجيل دخول أحادي عبر Azure AD للموظفين؛ أما الضيوف فيحتاجون إلى دعوات وموافقات، ومواءمة مع نهج المستأجر.

الحضور

  • Teams APIs: حضور غني وفوري عبر Graph على مستوى المستأجر بأكمله.
  • ACS: لا يوجد حضور أصلي في Teams؛ يتطلب قياس قياسات ومزامنة مخصصة.

المحادثة والتجربة

  • Teams APIs: السلاسل، والتفاعلات، والبطاقات، والردود، والملفات المضمنة، وتكافؤ شبيه بـ Teams.
  • ACS: رسائل خفيفة؛ أضيفوا بأنفسكم السلاسل، والبحث، والرموز التعبيرية المخصصة، والتخزين الدائم.

المكالمات/الاجتماعات

  • ACS: ضمِّن الصوت والفيديو في تطبيقك؛ مناسب جدًا للوصول العام؛ وتولَّ بنفسك استكشاف أخطاء مسارات الوسائط وإصلاحها.
  • Teams APIs: سلسة للمستخدمين ضمن المستأجر؛ وغالبًا ما يعني الانضمام الخارجي تهيئة ضيف في AAD.

حزمة SDK & تجربة المطورين

  • ACS: حزم SDK موحدة لأنظمة Web وiOS وAndroid؛ وسريعة في التضمين.
  • Teams/Graph/Bot: قوية، لكن منحنى تعلمها أشد انحدارًا (الأذونات، وwebhooks، وترقيم الصفحات).

الامتثال والترخيص

  • Teams: اكتشاف البيانات الإلكتروني eDiscovery وDLP والحجز القانوني وإقامة البيانات مدمجة أصلًا؛ ويُدفع ثمنها عبر تراخيص M365 مع احتمال وجود خطط متميزة أو حدود إضافية.
  • ACS: فوترة قائمة على الاستخدام؛ وأنت تتحكم في موقع التخزين والاستبقاء وSIEM وتصدير سجلات التدقيق.

البنى المرجعية (النماذج الذهنية)

  • بوابة B2C (ACS أولًا): دردشة ACS ومكالماته > تخزينك واستبقاؤك > إعادة توجيه اختيارية إلى Teams عبر bot أو قناة للوكلاء.
  • مكتب المساعدة الداخلي (Teams أولًا): دردشة Teams وbot مع حضور Graph > تسجيل دخول موحد (SSO) للموظفين > استقبال عام اختياري عبر النماذج أو تهيئة الضيوف.
  • الجسر الهجين: ACS للأداة العامة <-> وسيط (ربط المعرفات، وتحويل الرسائل، ومزامنة الحضور، وخطافات الامتثال) <-> تجربة القناة أو الوكيل في Teams.

قائمة التحقق من البناء

  • حدِّد المستخدم الأساسي: الموظفون، أو المتعاقدون، أو الجمهور العام.
  • قرِّر مكان وجود البيانات، ومن يملك الاستبقاء وعمليات التدقيق.
  • ارسم تدفقات الهوية (SSO والضيوف والمستخدمون المجهولون) قبل كتابة أي شيفرة.
  • تحقَّق من متطلبات الحضور مبكرًا، ولا تُلحقها لاحقًا.
  • اختبر حدود Graph وإنتاجية الرسائل والمكالمات في ACS تحت الحمل.
  • خصِّص ميزانية لـالتراخيص مقابل التشغيل (الوسيط، والتدقيق، والمراقبة).
  • خطِّط لـالتراجع والخروج إذا تغيّرت احتياجاتك في الربع القادم.

الأسئلة المتداولة المختصرة

  • هل يمكن لمستخدمي ACS الانضمام إلى اجتماع Teams بشكل أصلي؟ ليس مباشرةً؛ توقَّع جسرًا أو تدفق ضيف عبر AAD.
  • هل أحتاج إلى تراخيص M365 لمستخدمي ACS؟ لا، فـACS قائم على الاستخدام.
  • هل تتعامل Teams APIs مع المستخدمين الخارجيين المجهولين؟ ليس بسلاسة؛ عادةً يتطلب ذلك تهيئة ضيف في AAD.
  • هل يتوفر الحضور مع ACS؟ ليس لمستخدمي Teams؛ ويتطلب مزامنة مخصصة أو حلولًا بديلة.

خطوات العمل

  1. حدِّد أهم ثلاثة متطلبات لديك: (مثل: الدردشة المجهولة، وحضور Teams، وeDiscovery).
  2. نفِّذ تجربة استكشافية ذات مسارين: PoC لـ ACS من أجل الدردشة العامة، وPoC لـ Teams من أجل الوكلاء الداخليين.
  3. إذا كانت المتطلبات كلاهما مطلوبًا، فحدِّد نطاق MVP للوسيط: ربط الهويات، وإعادة توجيه الرسائل، ومزامنة حضور بسيطة، وتسجيل التدقيق.
  4. وازِن الميزانية: مقاعد M365 مقابل استخدام ACS مع عدد الموظفين التشغيليين اللازمين للامتثال.

وختامًا، فإن تصميم بنية تربط بنجاح جزر الهوية بين Azure Communication Services وAzure AD يتطلب فهمًا واضحًا لجمهورك. سواء كنت تبني بوابة استهلاكية مفتوحة أو مكتب مساعدة مؤسسيًا داخليًا، فإن إبقاء الهوية في صدارة اهتماماتك سيوفر عليك متاعب كثيرة لاحقًا. لمناقشة أعمق لهذه الخيارات، استمع إلى الحلقة المصاحبة على Azure Communication Services vs Teams APIs، واشترك لتبقى على اطلاع دائم بكل ما يتعلق بـ Microsoft 365 وبنية Azure!

Entities in this article

Microsoft Entra ID eDiscovery Middleware Compliance Microsoft Teams Technical debt Throttling OneDrive SharePoint

Related articles

RSS