تشير صفحة إضافة مصادقة SAML هنا إلى أن “مصادقة SAML متاحة في خطط الاستضافة المؤسسية”.
هل يعني هذا أنني لن أتمكن من استخدام مصادقة SAML على نسختي المجانية المستضافة ذاتيًا من Discourse؟ في المثال المثالي، أرغب في استخدام مصادقة Azure AD لنسخة Discourse الخاصة بي.
هذه الرسالة تشير إلى استضافتنا. وهذا يعني أنه لا يمكنك استخدام إضافة 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.
يمكنك إخفاء رابط تسجيل الدخول عبر CSS، ولن يتمكن أي مستخدم من رؤيته. يمكنك بعد ذلك مشاركة (أو نشر على موقع داخلي) رابط مباشر لتسجيل الدخول باستخدام OpenID أو SAML لمستخدميك الداخليين. وبما أن المستخدمين غير مسجلين في الدخول عند وصولهم إلى صفحة تسجيل الدخول، فلا توجد طريقة لمعرفة ما إذا كانوا داخليين أم لا.
يمكنك أيضًا تغيير تسمية الزر لمحاولة تجنب الالتباس. على سبيل المثال، في الصورة أدناه، قمنا بتسمية الزر الخاص بـ “المستخدمين الداخليين” باسم “موظفو Discourse”. إذا حاول شخص غير من موظفي Discourse استخدامه، فليكن ذلك: