SAML Plugin على استضافة ذاتية لـ Discourse

تشير صفحة إضافة مصادقة SAML هنا إلى أن “مصادقة SAML متاحة في خطط الاستضافة المؤسسية”.

هل يعني هذا أنني لن أتمكن من استخدام مصادقة SAML على نسختي المجانية المستضافة ذاتيًا من Discourse؟ في المثال المثالي، أرغب في استخدام مصادقة Azure AD لنسخة Discourse الخاصة بي.

يمكنك استخدامه. يتوفر الإضافة على GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub.

هذه الرسالة تشير إلى استضافتنا. وهذا يعني أنه لا يمكنك استخدام إضافة SAML في خططنا القياسية أو التجارية.

ومع ذلك، لا ينبغي أن تحتاج إلى SAML للربط مع Azure-AD. راجع Discourse OpenID Connect (OIDC) للحصول على إعداد أبسط بكثير. توجد ملاحظات خاصة بـ Azure-AD في النهاية.

إذن، هل يمكن استخدام جميع الإضافات المدرجة في دليل الإضافات على مثيل ديسكورد المجاني المستضاف ذاتيًا الخاص بي؟

بالتأكيد! وهناك عدد أكبر بكثير من الإضافات #الرسمية مما هو مدرج في الموقع، ويمكنك استخدامها بحرية. تأكد أيضًا من الاطلاع على #مكون_القالب.

شكرًا مجددًا على المعلومات الإضافية.

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

هل يمكنني تقييد إضافة مصادقة OpenID Connect بـ Azure AD وتقييدها بالمستخدمين الداخليين فقط؟

يُعد OpenID Connect، وكذلك SAML، من «موفري المصادقة». عند إعداد أحد هذه الموفرين في موقعك، سيتمكن المستخدمون افتراضيًا من اختيار تسجيل الدخول المحلي أو أحد موفري المصادقة. ومثال جيد على ذلك هو Meta، حيث يمكنك الاختيار بين تسجيل الدخول المحلي أو عبر فيسبوك أو جوجل أو غيت هب، وغيرها.

في حالتك، سيكون أمام المستخدمين خيار بين تسجيل الدخول المحلي وOpenID، أو بين تسجيل الدخول المحلي وSAML. يمكنك اختيار ما يناسبك وما يسهل إعداده لبيئتك.

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

لكن هل من الممكن إخفاء ذلك عن المستخدمين الخارجيين؟ لا أود أن يحاول عملاؤنا التفكير في أنهم يستطيعون تسجيل الدخول باستخدام Azure AD.

ماذا عن صفحة تسجيل دخول/تسجيل منفصلة لا يعرفها سوى المستخدمون الداخليون، حيث يكون مصادقة Azure AD هي الخيار الوحيد؟

يمكنك إخفاء رابط تسجيل الدخول عبر CSS، ولن يتمكن أي مستخدم من رؤيته. يمكنك بعد ذلك مشاركة (أو نشر على موقع داخلي) رابط مباشر لتسجيل الدخول باستخدام OpenID أو SAML لمستخدميك الداخليين. وبما أن المستخدمين غير مسجلين في الدخول عند وصولهم إلى صفحة تسجيل الدخول، فلا توجد طريقة لمعرفة ما إذا كانوا داخليين أم لا.

يمكنك أيضًا تغيير تسمية الزر لمحاولة تجنب الالتباس. على سبيل المثال، في الصورة أدناه، قمنا بتسمية الزر الخاص بـ “المستخدمين الداخليين” باسم “موظفو Discourse”. إذا حاول شخص غير من موظفي Discourse استخدامه، فليكن ذلك:

جوشوا - أنا أقدر حقًا مساعدتك السريعة والمفيدة.
شكرًا جزيلًا، وابقَ آمنًا!