Discourse OpenID Connect (OIDC)

[Discourse]

	ملخص	يسمح Discourse OpenID Connect باستخدام مزود OpenID Connect كمزود مصادقة لـ Discourse.
	دليل التثبيت	هذه الإضافة مدمجة مع نواة Discourse. لا حاجة لتثبيت الإضافة بشكل منفصل.

نظرًا لأن هذه إضافة #رسمية يديرها فريق Discourse، يمكن تقديم طلبات #contribute:bug، و#contribute:ux، و#contribute:feature في الفئات المعنية هنا على Meta، مع وضع العلامة المناسبة للإضافة. يُقدَّم الدعم في Support > SSO. انقر على أحد الروابط أدناه لبدء موضوع جديد.

الدعم خطأ تجربة المستخدم ميزة

الميزات

تهدف هذه الإضافة إلى تقديم تنفيذ بسيط لـ المواصفة. على وجه التحديد، تدعم «تدفق رمز التفويض». للبدء، اتبع تعليمات تثبيت الإضافة، أو اتصل بمزود الاستضافة الخاص بك.

يمكن استخدام إضافة oauth2-basic للاتصال ببعض مزودي OpenID Connect (حيث إن OpenID Connect مبني على OAuth2). ومع ذلك، فإن هذه الإضافة تتطلب إعدادًا يدويًا أقل بكثير، ويمكنها استخدام «رمز الهوية» JWT إذا لم يكن واجهة برمجة التطبيقات JSON متاحة.

يتم إجراء الإعداد تلقائيًا باستخدام مستند اكتشاف OpenID Connect. وفقًا للمواصفة، يجب أن يكون هذا المستند موجودًا في <nطاق المصدر>/.well-known/openid-configuration، لكن Discourse يدعم أي مسار للسماح بتنفيذات غير متوافقة (مثل Azure B2C). يتم تخزين مستند الاكتشاف مؤقتًا لمدة 10 دقائق لتحسين الأداء في المواقع ذات الزيارات العالية.

إذا تضمن مستند الاكتشاف معلمة userinfo_endpoint، فستستخدم الإضافة هذه المعلمة لجمع بيانات المستخدم الوصفية. وإلا، ستستخرج الإضافة البيانات الوصفية من id_token (وهو JWT) المقدم من طرف الرمز. الإضافة لا تتحقق من صحة توقيع JWT، لأن ذلك سيزيد التعقيد بشكل كبير. يدعم هذا القرار المواصفة:

إذا تم استلام رمز الهوية عبر اتصال مباشر بين العميل وطرف الرمز (وهو الحال في هذا التدفق)، فيمكن استخدام التحقق من خادم TLS للتحقق من المصدر بدلاً من التحقق من توقيع الرمز.

لمزودي الهوية الذين يدعمون التفويض بدون سر باستخدام «تدفق رمز التفويض مع مفتاح الإثبات لتبادل الرمز»، يجب تمكين PKCE، ويمكن إغفال إعداد client_secret.

الإعداد

خيارات الإعداد الأساسية

• openid_connect_enabled: تمكين مصادقة OpenID Connect

• openid_connect_discovery_document: عنوان URL لمستند اكتشاف OpenID Connect. عادةً ما يكون موجودًا في https://your.domain/.well-known/openid-configuration

• openid_connect_client_id: معرف عميل OpenID Connect

• openid_connect_client_secret: سر عميل OpenID Connect

• openid connect rp initiated logout: إعادة توجيه المستخدم إلى end_session_endpoint بعد تسجيل الخروج. يجب أن يدعمه مزود الهوية الخاص بك وأن يكون مدرجًا في مستند الاكتشاف.

• openid connect rp initiated logout redirect: (اختياري) عنوان post_logout_redirect_uri الذي سيتم تمريره إلى طرف تسجيل الخروج. إذا تم توفيره، فيجب تسجيله لدى مزود الهوية.

• openid_connect_authorize_scope: النطاقات المرسلة إلى طرف التفويض. يجب أن تتضمن «openid»

• openid_connect_use_pkce: تمكين مفتاح الإثبات لتبادل الرمز (PKCE) لمصادقة OpenID Connect.

• openid_connect_verbose_logging: تسجيل معلومات تفصيلية حول مصادقة openid-connect في /logs. يُنصح بإبقاء هذا الخيار معطلًا أثناء الاستخدام العادي.

خيارات الإعداد المتقدمة

• openid_connect_token_scope: النطاقات المرسلة عند طلب طرف الرمز. المواصفة الرسمية لا تتطلب ذلك.

• openid_connect_error_redirects: إذا احتوى error_reason في رد الاستدعاء على المعامل الأول، سيتم إعادة توجيه المستخدم إلى عنوان URL في المعامل الثاني. يُستخدم للتنفيذات غير العادية التي ترسل أخطاء استجابةً لإدخال المستخدم (مثل Azure B2C)

• openid_connect_allow_association_change: السماح للمستخدمين بفصل وإعادة ربط حسابات Discourse الخاصة بهم مع مزود OpenID Connect

• openid_connect_groups_claim: اسم المطالبة في استجابة OIDC^[1] التي تحتوي على مجموعات المستخدم كمصفوفة من السلاسل النصية. اتركها فارغة لتعطيل مزامنة المجموعات. انظر مزامنة المجموعات أدناه.

• openid_connect_user_field_mappings: تعيينات لمطالبات OIDC^[2] سيتم تخزينها في حقول المستخدم في Discourse. يتم تحديد حقول المستخدم بمعرفها الرقمي، والذي يمكن العثور عليه في عنوان URL عند تحريرها عبر لوحة الإدارة.

مزامنة المجموعات

يمكن للإضافة مزامنة عضويات المجموعات تلقائيًا من مزود OpenID Connect الخاص بك إلى مجموعات Discourse. في كل تسجيل دخول، ستقرأ الإضافة المطالبة المهيأة من رمز OIDC وتحدّث عضويات مجموعات المستخدم وفقًا لذلك. لتمكين مزامنة المجموعات:

1. قم بإعداد مزود الهوية الخاص بك لإرجاع مصفوفة من المجموعات في إحدى المطالبات. يجب أن تكون هذه مصفوفة من السلاسل النصية.

2. اضبط openid_connect_groups_claim على اسم المطالبة في رمز OIDC التي تحتوي على مجموعات المستخدم (مثل cognito:groups). بمجرد تعيينها، سيبدأ ذلك في مزامنة المعلومات مع نظام «المجموعات المرتبطة» في Discourse.

3. ابحث عن مجموعة Discourse التي ترغب في ربطها. انتقل إلى «الإعدادات» → «العضوية» → «تلقائي»، ثم اختر المجموعات المرتبطة للربط. يتم تعبئة قائمة القائمة المنسدلة هذه بمعلومات من مزود الهوية، لذا يجب أن يكون عضو واحد على الأقل قد سجّل الدخول لظهور خيار.

مثال على الإعداد

سنقوم هنا بإعداد إضافة openid-connect للاتصال بمزود OpenID Connect من Google. هذا يحاكي وظيفة موجودة بالفعل في نواة Discourse، لكنه يعمل كمثال سهل الوصول.

1. انتقل إلى OpenID Connect  |  Sign in with Google  |  Google for Developers واتبع التعليمات للحصول على بيانات اعتماد OAuth.

2. في نفس الصفحة، اتبع التعليمات لإضافة عنوان URL لإعادة التوجيه. يجب أن يكون https://<منتدى_كـم>/auth/oidc/callback (بدون شرطة مائلة في النهاية)

3. انتقل إلى إعدادات موقع Discourse وابحث عن “openid_connect”

   • openid connect enabled: [x]

   • openid connect discovery document: https://accounts.google.com/.well-known/openid-configuration

   • openid connect client id: <client-id>

   • openid connect client secret: <client-secret>

   • openid connect authorize scope: openid email (مع مسافة بينهما)

4. لقد انتهيت. الآن سيتم تسجيل الدخول باستخدام زر «تسجيل الدخول باستخدام OpenID Connect» عبر Google . يمكن تطبيق نفس الخطوات هذه على مزودين آخرين مع تغييرات طفيفة جدًا.

استكشاف الأخطاء وإصلاحها

بالإضافة إلى إعداد verbose_logging الموصوف أعلاه، يمكنك الوصول إلى بيانات حول ارتباطات OIDC باستخدام إضافة data-explorer:

SELECT user_id, provider_name, provider_uid
FROM user_associated_accounts
WHERE provider_name = 'oidc'

أو في وحدة تحكم rails:

User.find_by_username("david").user_associated_accounts.where(provider_name: 'oidc')

ملاحظات خاصة بالمزودين

لا تتردد في تحديث هذا إذا وجدت أي غرائب خاصة بمزود معين تتعلق بهذا التكامل:

Entra ID (سابقًا Azure AD)

أضف نطاق email، وتأكد من استخدام مستند إعداد الإصدار 2. على سبيل المثال

https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration

@andy.czerwonka

• تأكد من استخدام الإصدار 2.0 من طرف الإعداد كما هو موضح في الملاحظات أعلاه. الإصدار الافتراضي v1.0 لا يدعم نطاق email أو profile.
• إذا كانت هناك مشاكل مع سر العميل، جرب إنشاء سر جديد. واجهنا بعض المشاكل، لكن بعد إنشاء عدة سريّين بدا الأمر على ما يرام.
• تأكد من تمكين «تسجيل الدخول وقراءة ملف تعريف المستخدم» كـ «إذن مفوض» في Azure AD عند إنشاء إدخال لموقعك.
• تأكد من إضافة استدعاء صحيح، وهو ‘https://your-site/auth/oidc/callback’

Azure B2C

يمكن العثور على تفاصيل عنوان URL لمستند الاكتشاف هنا: Web sign in with OpenID Connect - Azure AD B2C | Microsoft Learn

على سبيل المثال، يقع مستند البيانات الوصفية لتدفق المستخدم b2c_1_sign_in في fabrikamb2c.onmicrosoft.com في:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=b2c_1_sign_in

لجعل البريد الإلكتروني يعمل:

@Umer_Nawab

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

Tutorial - Create user flows and custom policies - Azure Active Directory B2C | Microsoft Learn

بعد تنفيذ الخطوات المذكورة في المقال أعلاه، بدأ ظهور مطالبة البريد الإلكتروني عند تسجيل المستخدم الجديد، لكن عند تسجيل مستخدم موجود، كانت مطالبة البريد الإلكتروني مفقودة من الرمز. ثم اضطررت إلى إجراء بعض التغييرات في ملف XML للسياسة المخصصة باتباع الخطوات المذكورة في هذا المنشور:

https://stackoverflow.com/questions/59669666/email-claims-not-populated-with-custom-policies-in-azure-b2c

بعد هذه التغييرات، تظهر مطالبة البريد الإلكتروني الآن عند تسجيل المستخدم الجديد وكذلك عند تسجيل الدخول.

Yahoo

1. انتقل إلى https://developer.yahoo.com/apps وأنشئ تطبيقًا جديدًا

2. أدخل اسم التطبيق، واضبط نطاق الاستدعاء على نطاق المنتدى الخاص بك (مثل meta.discourse.org)

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

4. احفظ التطبيق

5. في إعدادات OIDC في Discourse، اضبط مستند الاكتشاف على

   https://login.yahoo.com/.well-known/openid-configuration
   

6. أدخل معرف العميل والسر من Yahoo

7. قم بتمكين إضافة OIDC

AWS Cognito

1. انتقل إلى Cognito وحدد أو أنشئ مجمع مستخدمين جديد.
2. عرّف تطبيقًا في عملاء التطبيق.
3. اترك كل شيء على الوضع الافتراضي، لكن غيّر إعداد تدفقات المصادقة لاختيار ALLOW_REFRESH_TOKEN_AUTH فقط.
4. انتقل إلى إعدادات عميل التطبيق وحدد التطبيق الجديد.
5. غيّر عنوان URL للاستدعاء إلى https://yoursite.example.com/auth/oidc/callback.
6. ضع علامة فقط على تدفق منح رمز التفويض ضمن «تدفقات OAuth المسموح بها».
7. ضع علامة على جميع النطاقات المطلوبة (لقد وضعت علامة على جميعها).

Okta

1. قم بإعداد Discourse مع معرف عميل تطبيق Okta والسر الخاص به

2. اضبط عنوان URL لمستند الاكتشاف على

   https://{your-app}.okta.com/.well-known/openid-configuration
   

3. في Discourse، اضبط openid connect authorize scope على openid email

مستضافون لدينا؟ هذه الإضافة متاحة في خططنا للأعمال والشركات. OAuth 2.0 & OpenID Connect Support | Discourse - Civilized Discussion

هل تحتاج إلى أتمتة تسجيلات دخول المستخدمين؟ انظر Auto-provisioning user accounts when SSO is enabled

---

1. الرمز أو حمولة معلومات المستخدم ↩︎

2. من الرمز أو حمولة معلومات المستخدم ↩︎