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. من الرمز أو حمولة معلومات المستخدم ↩︎

[Ramón]

مرحباً،
نحن نستخدم إضافة المصادقة OpenID Connect مع تثبيت Discourse على AWS.
لقد قمنا بنشر حاويات Discourse و Discourse Sidekiq و Redis (بناءً على Bitnami ولكن رجاءً لا تطردوني ؛). قاعدة البيانات تعمل على AWS RDS. نستخدم KeyCloak.

الأمور تسير على ما يرام.

ولكن في بعض الأحيان بعد إعادة تشغيل مهمة Discourse AWS، يحدث أنها تعتقد أن لديها مستند الاكتشاف في ذاكرة التخزين المؤقت ولكن لا يوجد مستند هناك. ولا تحاول استعادته مرة أخرى من KeyCloak:

سجل OIDC: تم تحميل مستند الاكتشاف من ذاكرة التخزين المؤقت
سجل OIDC: مستند الاكتشاف هو
---
(oidc) بدأت مرحلة الطلب.
(oidc) فشل المصادقة! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError، مستند الاكتشاف مفقود

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

ماذا يمكنك أن تنصح؟

[Tomáš_Guba]

مرحباً،

هل هناك طريقة لتعيين مصدر صورة ملف تعريف مستخدم Discourse إلى حقل محدد في خدمة openID؟

تعديل: نحن نستخدم Keycloak

[gmoirod (Guillaume Moirod)]

مرحباً،

لدي متطلب مشابه لمتطلب @Tomáš_Guba: أود الحصول على قيمة من إدخال مخصص في ملف تعريف المستخدم واستخدامها في حقل مستخدم [مخصص].

في حالتي الشخصية، لدي مستند اكتشاف به userinfo_endpoint

هل هناك شيء كهذا في خارطة طريق البرنامج المساعد؟

شكراً

[Rubens_Flinco]

مرحباً، لقد تمكنت من جعل المكون الإضافي يعمل مع معرّف OpenID الخاص بتسجيل الدخول الموحد (SSO) الخاص بي، ولكنه لا يظهر مملوءًا في حقل اسم المستخدم للنظام الآخر أو البريد الإلكتروني من بين حقول أخرى…

أتخيل أنه يجب عليّ تكوين شيء ما في حقل “مطالبات اتصال OpenID”، ولكني لا أعرف كيفية تكوين هذا الحقل مباشرة. هل يمكن لأحد أن يعطيني مثالاً؟ إليك بعض لقطات الشاشة لكيفية ظهور مشروعي:
https://imgur.com/gallery/LWvkJUV

[snikch (Mal Curtis)]

هل هناك طريقة لتجنب “فقدان” المسار الأصلي عند تسجيل الدخول إلى منشور خاص؟

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

[Hyan]

مرحباً @david،
هل يمكنك إلقاء نظرة على المشكلة المذكورة في المنشور التالي؟ أود استخدام إضافة OIDC بدلاً من OAuth الأساسي. لكنني أواجه نفس المشكلة - لا يمكنني تمرير المعلمات إلى طلب /authorize. لقد وضعت القيمة في الإضافة بالتنسيق foo=bar.

Cannot add additional parameters to authorize endpoint

I switched to the Oauth2 Basic plugin. Problem solved.

[JJ_IA]

لم أتمكن من جعل هذا يعمل في LinkedIn. هل لدى أي شخص آخر؟ أصل إلى تسجيل الدخول إلى LinkedIn بعد إعادة التوجيه إليه عند النقر على زر “تسجيل الدخول باستخدام…” ثم “السماح” لتطبيقي باستخدام بريدي الإلكتروني من LinkedIn، ثم أحصل على “عذرًا، حدث خطأ أثناء التفويض لحسابك. يرجى المحاولة مرة أخرى.”

https:/discourse.mysite.com/auth/failure?message=invalid_credentials&origin=https%3A%2F%2Fdiscourse.mysite.com%2F&strategy=oidc

[JJ_IA]

ما زلت أواجه مشكلة في هذا. أحصل على الخطأ التالي:

(oidc) فشل المصادقة! invalid_credentials: OAuth2::Error, invalid_request: A required parameter "client_secret" is missing {"error":"invalid_request","error_description":"A required parameter

هذا خطأ omniauth ويبدو أنه متعلق بـ [ربما]: No longer works with oauth2 gem v2.0+ · Issue #68 · decioferreira/omniauth-linkedin-oauth2 · GitHub

المساعدة محل تقدير!

[Discoder (Hector)]

أتلقى الأخطاء التالية:

(oidc) فشل المصادقة! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError، مستند الاكتشاف مفقود

سجل OIDC: جلب مستند الاكتشاف أثار خطأ Faraday::ConnectionFailed FinalDestination: فشل البحث

لدي إعداد المكون الإضافي “وثيقة اكتشاف OpenID Connect” في إعدادات المسؤول على النحو التالي: https://<auth_provider>/.well-known/openid-configuration ويمكنني الوصول إليها بنجاح في حاوية Docker للتطبيق التي تعمل باستخدام أمر Curl وحتى في وحدة تحكم Rails.

هل لديك أي فكرة عن سبب تلقي هذه الأخطاء؟ لا يمكنني التكامل بشكل صحيح بسبب ذلك. أيضًا، أنا خلف الشبكة الداخلية وأستخدم وكيل شركة إذا كان ذلك مفيدًا. كما ذكرت، مع تمكين الوكيل في متغيرات البيئة للحاوية، يمكنني الوصول بشكل صحيح إلى عنوان URL الخاص بـ “وثيقة اكتشاف OpenID Connect”.

[weber-s (Samuël Weber/GwendalD)]

مرحباً!

سؤال جديد: هل تدعم هذه الإضافة إدارة الجلسات؟ (Final: OpenID Connect Session Management 1.0).
لا أعتقد ذلك لأنه حتى لو أرسل موفر الهوية بيانات session_state، لا أرى في أي مكان في الكود حيث يتم تخزينها كملف تعريف ارتباط أو ما شابه.

لذا هذا سؤال/طلب ميزة سيكون رائعاً!

[swt2c (Scott Talbert)]

عند استخدام هذه الإضافة مع AWS Cognito، لتسجيل الخروج، يتطلب Cognito تمرير معلمة client_id إلى عنوان URL لتسجيل الخروج. على حد علمي، لا توجد طريقة لإضافة معلمات استعلام إضافية إلى عنوان URL لتسجيل الخروج - هل هذا صحيح؟ إذا لم يكن كذلك، فهل من الممكن إضافة هذه الإمكانية؟

[chrisblech (Christoph Blechschmitt)]

أهلاً بالجميع

لقد كتبت إضافة صغيرة لهذا المكون الإضافي (تقنيًا في شكل سمة/مكون) - لإخفاء الزر “تسجيل الدخول عبر OIDC” في نافذة تسجيل الدخول المنبثقة، ولكن لبدء تدفق تسجيل الدخول عبر OIDC عن طريق الوصول إلى عنوان URL خاص.

discourse-autooidc.zip (1.0 كيلوبايت)

حالة الاستخدام لهذه الميزة هي توفير تسجيل دخول آمن ومريح (تلقائي) عبر OAuth لأعضاء شركتنا، دون الكشف عن رابط عام لموفر OAuth (Authentik في حالتنا، ولكن يجب أن يعمل أيضًا مع Authelia و Keycloak و Auth0 و Okta،…) ودون إزعاج جميع المستخدمين الآخرين بزر تسجيل الدخول عبر OIDC الذي لا يمكنهم أو لا ينبغي عليهم استخدامه أبدًا.

لتسجيل الدخول عبر OIDC، ما عليك سوى استدعاء https://<your-discourse-base-url>/login#autooidc

[david (David Taylor)]

قد تكون مهتمًا بـ https://github.com/discourse/discourse-hide-auth-method، والذي يفعل شيئًا مشابهًا

[kluvi (Jakub Kluvánek)]

يدعم Keycloak Backchannel logout URL:\n\u003e عنوان URL الذي سيؤدي إلى تسجيل خروج العميل من نفسه عند إرسال طلب تسجيل خروج إلى هذا النطاق (عبر end_session_endpoint). إذا تم حذفه، فلن يتم إرسال أي طلب تسجيل خروج إلى العميل في هذه الحالة.\n\n سيكون من الرائع لو كشف هذا المكون الإضافي عن نقطة نهاية تقبل حمولة من Keycloak وتسجل خروج مستخدم معين فورًا من جميع الجلسات. بخلاف ذلك، عندما نقوم بتعطيل مستخدم في Keycloak، يجب علينا انتظار maximum session age (وهو كبير جدًا افتراضيًا)

[Firepup650 (Firepup Sixfifty)]

@kluvi

يجب أن ننتظر أقصى عمر للجلسة

يمكنك أيضًا تسجيل خروجهم من جميع الجلسات باستخدام صفحة مسؤول المستخدم (على سبيل المثال، /admin/-1/system) وانقر فوق الزر تسجيل الخروج في أعلى الصفحة.

[nfrog (Nicolas)]

مرحباً،

عندما يفشل جلب مستند الاكتشاف (على سبيل المثال، عند انتهاء المهلة)، يقوم المكون الإضافي بتخزين الخطأ مؤقتًا، مما يعني أن المصادقة غير متاحة لمدة 10 دقائق. هل من الممكن عدم تخزين الخطأ مؤقتًا حتى تتم إعادة محاولة الجلب في وقت أقرب؟

مع خالص التقدير

[balazsorban44 (Balázs Orbán)]

عذرًا على الإزعاج، ولكن هناك طلب سحب (PR) مفتوح لهذا الغرض والذي يجب أن يكون من السهل دمجه لإضافة دعم PKCE.

@nbianca رأيت أنك آخر من قام بالالتزام في المستودع، هل يمكنك إلقاء نظرة، ربما؟

Enable PKCE Support