استخدام Discourse كمزود هوية (SSO، DiscourseConnect)

[Discourse]

هل تريد استخدام Discourse كموفر للهوية لتطبيق الويب الخاص بك؟ رائع! لنبدأ.

تفعيل إعداد موفر DiscourseConnect

ضمن إعدادات موقع المسؤول في Discourse (/admin/site_settings)، قم بتمكين الإعداد enable discourse connect provider وأضف سلسلة سرية إلى discourse connect provider secrets (تُستخدم لتجزئة حمولات SSO).

تطبيق DiscourseConnect في تطبيق الويب الخاص بك:

• قم بإنشاء قيمة عشوائية nonce. لنسمي هذه القيمة NONCE. احفظها مؤقتًا حتى تتمكن من التحقق منها باستخدام قيمة الـ nonce التي سيتم إرجاعها في الاستجابة.

• أنشئ حمولة جديدة باستخدام NONCE و RETURN_URL (حيث سيعيد Discourse توجيه المستخدم بعد التحقق). يجب أن تبدو الحمولة كما يلي: nonce=NONCE&return_sso_url=RETURN_URL. يجب أن يتطابق مضيف RETURN_URL مع نمط النطاق الذي استخدمته عند تكوين discourse connect provider secrets.

• قم بتشفير الحمولة الأولية أعلاه بتشفير Base64. لنسمي هذه الحمولة BASE64_PAYLOAD.

• قم بترميز عنوان URL لـ BASE64_PAYLOAD أعلاه. لنسمي هذه الحمولة URL_ENCODED_PAYLOAD.

• قم بإنشاء توقيع HMAC-SHA256 من BASE64_PAYLOAD باستخدام سر موفر SSO الخاص بك كمفتاح، ثم قم بإنشاء سلسلة سداسية عشرية بأحرف صغيرة منها. لنسمي هذا التوقيع HEX_SIGNATURE.

إرسال طلب المصادقة إلى Discourse

قم بإعادة توجيه المستخدم إلى DISCOURSE_ROOT_URL/session/sso_provider?sso=URL_ENCODED_PAYLOAD&sig=HEX_SIGNATURE

الحصول على استجابة من Discourse:

إذا تم تنفيذ الخطوات المذكورة أعلاه بشكل صحيح، فسيقوم Discourse بإعادة توجيه المستخدم الذي قام بتسجيل الدخول إلى RETURN_URL المقدم. ستحصل على معلمات سلسلة الاستعلام مع sig و sso جنبًا إلى جنب مع بعض معلومات المستخدم. اتبع الخطوات أدناه الآن:

• احسب HMAC-SHA256 لـ sso باستخدام سر موفر SSO كمفتاح لك.

• قم بتحويل sig من تمثيل السلسلة السداسية عشرية الخاصة به مرة أخرى إلى بايتات.

• تأكد من أن القيمتين السابقتين متساويتان.

• قم بفك تشفير Base64 لـ sso؛ ستحصل على سلسلة الاستعلام المضمنة التي تم تمريرها. ستحتوي على مفتاح يسمى nonce يجب أن تتطابق قيمته مع الـ nonce الذي تم تمريره في الأصل. تأكد من أن هذا هو الحال، وتأكد من حذف الـ nonce من نظامك.

• ستجد أن سلسلة الاستعلام هذه ستحتوي أيضًا على مجموعة من معلومات المستخدم. استخدمها حسب الرغبة.

هذا كل شيء. بحلول هذا الوقت، يجب أن تكون قد أعددت تطبيق الويب الخاص بك لاستخدام Discourse كموفر SSO!

المزيد من المعلمات، والمزيد من الخيارات

بالإضافة إلى nonce و return_sso_url، تحتوي حمولة الطلب على العديد من المعلمات الاختيارية الإضافية.

• prompt: إذا كانت prompt=none، يتم التعامل مع طلب SSO كطلب “مجرد تحقق”. إذا كان المتصفح/الجهاز قد قام بتسجيل الدخول بالفعل إلى Discourse، فسيقوم Discourse بإرجاع استجابة SSO ناجحة تتضمن معلومات مصادقة المستخدم، كالمعتاد. إذا لم يكن المتصفح/الجهاز قد قام بتسجيل الدخول بالفعل، فلن يطلب Discourse من المستخدم تسجيل الدخول، وسيقوم فورًا بإرجاع استجابة SSO تتضمن المعلمة failed=true بدلاً من معلومات المستخدم. يوفر هذا آلية للاستعلام عما إذا كان المستخدم قد سجل الدخول، دون توجيه المستخدم أبدًا إلى مربع حوار تسجيل الدخول إذا لم يكن كذلك.

• logout: إذا كانت logout=true، يصبح طلب SSO طلب تسجيل خروج. إذا كان المستخدم قد سجل الدخول إلى Discourse على هذا المتصفح/الجهاز، فسيتم تسجيل خروجه من هذا الجهاز. في كلتا الحالتين، سيقوم Discourse بإعادة التوجيه فورًا إلى return_sso_url، بدون إضافة sso أو sig إلى سلسلة الاستعلام.

• require_2fa: إذا كانت require_2fa=true، فسيطلب Discourse من المستخدم التحقق من المصادقة الثنائية قبل إعادة التوجيه. ستحتوي حمولة الاستجابة على confirmed_2fa=true إذا أكمل المستخدم التحقق من 2FA بنجاح، أو no_2fa_methods=true إذا لم يكن لدى المستخدم أي طرق 2FA مهيأة.

prompt=none و logout=true لا يمكن أن يتواجدا معًا؛ لا معنى لتقديمهما في نفس الطلب.

مرجع حمولة sso=

معلمات الطلب:

• nonce: (سلسلة، مطلوب) سلسلة عشوائية تم إنشاؤها بشكل آمن
• return_sso_url: (سلسلة، مطلوب) عنوان URL لإعادة التوجيه إليه مع الاستجابة
• prompt: (سلسلة، اختياري) إذا كانت none، فقم بفحص حالة المصادقة دون مطالبة المستخدم بتسجيل الدخول.
• logout: (قيمة منطقية، الافتراضي false) إذا كانت true، فقم بتسجيل خروج المستخدم من Discourse.
• require_2fa: (قيمة منطقية، الافتراضي false) إذا كانت true، فقم بمطالبة المستخدم بالتحقق من المصادقة الثنائية قبل إعادة التوجيه.

معلمات النتيجة:

• لا توجد حمولة sso=، أو توقيع، استجابةً لطلب تسجيل الخروج، فقط إعادة توجيه إلى return_sso_url العادي للطلب.
• حمولة النتيجة لطلب تسجيل الدخول ستحتوي دائمًا على nonce، المعكوس من الطلب.
• ستعكس حمولة النتيجة أيضًا أي معلمات طلب أخرى. لا تعتمد على هذا السلوك؛ إنه ليس مقصودًا بالضرورة وليس جانبًا مضمونًا من واجهة برمجة التطبيقات. (على سبيل المثال، لماذا يتم نسخ المعلمة return_sso_url إلى الحمولة التي يتم إرسالها إلى return_sso_url؟)
• إذا فشل الطلب في مصادقة مستخدم، فستحتوي حمولة النتيجة على failed=true.
• إذا نجح الطلب في مصادقة مستخدم، فستحتوي حمولة النتيجة على بيانات اعتماد/معلومات المستخدم:
  • external_id: (سلسلة) معرّف مستخدم Discourse
  • username: (سلسلة) اسم المستخدم/المقبض
  • name: (سلسلة) اسم المستخدم الحقيقي
  • email: (سلسلة) عنوان البريد الإلكتروني
  • avatar_url: (سلسلة) رابط CDN كامل لصورة الصورة الرمزية للمستخدم التي تم تحميلها
  • admin: (قيمة منطقية) true إذا كان المستخدم مسؤولاً، وإلا false
  • moderator: (قيمة منطقية) true إذا كان المستخدم مشرفًا، وإلا false
  • groups: (سلسلة) قائمة مفصولة بفواصل من المجموعات (حسب الاسم) التي ينتمي إليها المستخدم
  • profile_background_url: (سلسلة) رابط CDN كامل لصورة خلفية ملف تعريف المستخدم
  • card_background_url: (سلسلة) رابط CDN كامل لصورة خلفية البطاقة للمستخدم
  • confirmed_2fa: (قيمة منطقية) true إذا أكمل المستخدم التحقق من 2FA (موجود فقط عند طلب require_2fa=true)
  • no_2fa_methods: (قيمة منطقية) true إذا لم يكن لدى المستخدم أي طرق 2FA مهيأة (موجود فقط عند طلب require_2fa=true)

قد تكون name و avatar_url و profile_background_url و card_background_url مفقودة إذا لم يقم المستخدم بتعيينها. (سيتم حذف أي عنصر تكون قيمته nil داخل Discourse من الاستجابة.)

تطبيقات Discourse الرسمية “استخدام Discourse كموفر هوية”:

• وكيل HTTP (يستخدم golang) يقوم بمصادقة المستخدمين باستخدام Discourse SSO (للمسؤولين فقط): GitHub - discourse/discourse-auth-proxy: An http proxy that uses the DiscourseConnect protocol to authenticate users · GitHub (صنعه @sam)

تطبيقات المجتمع المساهمة “استخدام Discourse كموفر SSO”:

• سكربت PHP يطبق Discourse كموفر SSO: Discourse sso provider login · GitHub (صنعه @paxmanchris)

• Ruby:
  GitHub - AstonJ/sso_with_discourse: Implementation in ruby for https://meta.discourse.org/t/using-discourse-as-a-sso-provider/32974 · GitHub

• Erlang:
  https://github.com/reverendpaco/discourse-as-sso-erlang

• Node.js:
  GitHub - edhemphill/passport-discourse: A Passport strategy for authenticating using a Discourse forum · GitHub
  GitHub - ArmedGuy/discourse_sso_node: npm package for Discourse SSO login features. · GitHub

• ASP.NET Core (يتطلب فقط التكوين):
  GitHub - Biarity/DiscourseSso: Easy, configurable Discourse SSO: GET /auth/login -> recieve a JWT with user data · GitHub

• امتداد MediaWiki (PHP):
  DiscourseSsoConsumer, a SSO extension for MediaWiki (صنعه @mdoggydog)

[jamesmarkcook (James Cook)]

Great how to, thanks.

FYI, the term ‘nonce’ has an unfortunate meaning in Britain.

[gogo52cn (david)]

I wrote a class to implement the process in Ruby. I use it to work with devise in my web application.

https://github.com/gogo52cn/sso_with_discourse

[ianmackinnon]

@techAPJ

Compute the HMAC-SHA256 of sso using sso_secret as your key.

sso seems to have a trailing newline which needs to be included when sent to the HMAC function, so it’s important to make sure that SSO consumer applications don’t strip whitespace from these query arguments.

[geneles (Michael Geneles)]

Our app users get their own subdomains. Is there a way to implement this with variable SSO urls?

[sam (Sam Saffron)]

interesting, this is tricky you would need to monkey patch this in, or better still make core extensible in this way and add a plugin.

[reverend_paco (Daniel Eklund)]

Hello,

I have created an Erlang implementation for encoding/decoding the payloads described in this specification. You can find it here:
https://github.com/reverendpaco/discourse-as-sso-erlang
Feedback is welcome.

Thanks to @mpalmer on another thread for setting me straight.

As I put together this implementation, I realized that the specification does not say too much about a few things:

1. the user information that is returned in the query parameters,
2. what happens when a user is not found

When I got around to testing I found the answers, and then confirmed by looking at the code, here: discourse/app/controllers/session_controller.rb at main · discourse/discourse · GitHub

I shall assume that in regards to 1. that while new user information may be added, that none of these values (“name”,“username”,“email”,“external_id”, etc) will be removed. This is just as important, contractually as what is described in the main post.

One piece of feedback I’d like to give the Discourse team is that it would be nice to add a means to optionally return back to the calling application in the case of a missing user.

Currently, at line 51 a non-logged-in or non-registered user will be forwarded to the Discourse login page. While this can be useful, I would rather programmatically have the option to learn that this person has not yet logged in (or registered) and give them the opportunity on my site to continue anonymously.

I can imagine something like this:

DISCOURSE_ROOT_URL/session/sso_provider?
sso=URL_ENCODED_PAYLOAD&sig=HEX_SIGNATURE&
returnBackIfUserMissing=true

and then the Discourse site sending back to the return_sso_url with either a special header, or an attribute, rather than redirecting to /login.

This change should be backwards compatible.
I’m new here, so if this is something that could be contributed via a pull-request, please tell me and I could take a shot at it next week.

thanks,
daniel

[sam (Sam Saffron)]

@reverend_paco

One piece of feedback I’d like to give the Discourse team is that it would be nice to add a means to optionally return back to the calling application in the case of a missing user.

Sure, totally open to add another option to the payload you send us for create_new=false PR welcome.

[reverend_paco (Daniel Eklund)]

added a PR for this

Optional 'no_user_found_return_sso_url' parameter for using Discourse as SSO

Commit-Message:

Implemented an optional 'no_user_found_return_sso_url' parameter to be called
 by the client when client is using Discourse as an SSO and wants Discourse to 
redirect back to a place of the client's choosng when a user is not found.

Currently, the Discourse as an SSO implementation checks the cookies _t and
 _session_forum to see if the user is registered and present in the database 
(_t is the token that is located in the users table). If a user is not found, 
the current implemenation forwards to the forum's /login URL. This behavior 
may be what the client wants, but it would be good to give an option to the 
client to send somewhere else.

This commit allows the client to embed an optional 'no_user_found_return_sso_url' 
parameter in the payload, prior to base64 and URL-encoding. If the Discoure SSO
endpoint detects that this parameter is present in the payload (and has a non-empty
value) the Discourse server will redirect to this new location if it does not detect the 
user. If this parameter is not present, then the redirection to /login will take place 
as it currently does.

Additionally, as the client may choose to use the same URL for
'no_user_found_return_sso_url' as for 'return_url', this commit introduces a new 
query-string name-value pair to be sent back to the client 'no_user_found_return_sso_url' 
location. This parameter 'user_found' will ALWAYS be sent back to the client, either when 
the user is found and 'return_url' is used or when the user is not found 
'no_user_found_return_sso_url' is used (values will be 'true' and 'false' respectively).

thanks,
daniel

[fantasticfears (Erick Guan)]

Nice work

redirect_to can be routed to a url with parameters. But isn’t a create_new=false enough? Or whatever name it is. You’ll get nonce and the flag back.

[reverend_paco (Daniel Eklund)]

@fantasticfears

But isn’t a create_new=false enough? Or whatever name it is. You’ll get nonce and the flag back.

I wanted to give the client the flexibility of sending a failure to a different URL than the success url (return_url). With complicated SSO architectures, this might be a requirement. (Selfishly, I wanted to make my return endpoint code less convoluted – i.e. on my side I have two codebases at /sso for success and /sso_failure for failure).

Implicitly there are already two URLs (return_url for success and ‘/login’ for failure) – I didn’t want to lose that.

So just to be clear, the payload you send to the Discourse endpoint should have both return_url and no_user_found_return_sso_url if you want Discourse to send it back when no user is found. It should have return_url only if you are ok with Discourse forwarding to /login.

Should look like this:

1.If you want Discourse to forward to login if no user found, then:

PAYLOAD = return_url=mydomain.com/clientendpoint&nonce=xE787euK
2. If you want Discourse to send back to you to the same endpoint for failure as success:

PAYLOAD = no_user_found_return_sso_url=mydomain.com/clientendpoint&return_url=mydomain.com/clientendpoint&nonce=xE787euK
3. If you want Discourse to send back to you to a different endpoint as success:

PAYLOAD = no_user_found_return_sso_url=sub.mydomain.com/handleNewUser&return_url=mydomain.com/clientendpoint&nonce=xE787euK

Potentially a bit over-engineered, but that was my thought process.

[fantasticfears (Erick Guan)]

@reverend_paco

I wanted to give the client the flexibility of sending a failure to a different URL than the success url (return_url). With complicated SSO architectures, this might be a requirement. (Selfishly, I wanted to make my return endpoint code less convoluted – i.e. on my side I have two codebases at /sso for success and /sso_failure for failure).

To be clear, it’s not user_not_found, it’s not logged in.

It’s about protocol not engineering in the first place. Given two endpoints, you have to deal with two possible endpoints. In both cases you must validate the nonce and destroy it. It’s a hurdle not benefit.

In extreme case, a client can ask Discourse several times with/without session (current_user), thus you would get n responses in each endpoints. It would be twice as hard to secure it due to changing cookies on your end.

[reverend_paco (Daniel Eklund)]

@fantasticfears

It’s about protocol not engineering in the first place.

Completely agree on protocol over engineering. Hence, my submission.

The semantics are equivalent to an if-else block, or more generally a case/switch block. result_url is our true condition, and user_not_found_url is our else block. If we didn’t provide it, we would force the client to have to deal with the ‘failure’ condition in the same codebase/endpoint – and for 90% of the people, this will be fine.

90% of people who want Discourse to return back to them will set return_url and user_not_found_url to be exact same thing. This bears repeating, and really renders the motivations for the 10% moot.

90% of the time you will make return_url and user_not_found_url the exact same thing. These 90%-ers will use their JSESSIONID/ PHPSESSID/ ASPSESSIONID /_session to look up the returned encoded nonce in their framework-supplied session-store and engineer accordingly.

7% of people will be happy to pass it to a different URL on their same app-server, which does some decoration (servlet-chains anyone?) or routing, but still looks up the nonce in their session.

3% will have some complicated polyglotish system that uses a distributed session store (like memcache) to store sessions for different app servers implemented in different legacy codebases. It’s up to them to store/invalidate the nonce across these different systems.

I realize I might not have been completely clear, but the user_not_found_url still receives the sso and sig parameters, just like the return_url.

So, if you are the 90% scenario, when you get the payload and verify/decode it, you will find the parameter user_found=false|true to know why it’s coming back to you.

[reverend_paco (Daniel Eklund)]

@fantasticfears, as per your recommendation on the PR, I have renamed the attribute from user_not_found_url to return_sso_unlogged_in_url.

[thomasschmit]

Great job !

Do you know how it possible to adapt it to GitLab in order to allow the Discourse users to directly login there?

[edhemphill (Ed)]

Hey folks, I could not find anything, so I created a npm for Discourse auth using Passport for node.js.

It’s here, and in npm if anyone needs it:

GitHub - edhemphill/passport-discourse: A Passport strategy for authenticating using a...

(really appreciate the team’s work, we’ve been a user since the very early days @ talk.wigwag.com)

[reverend_paco (Daniel Eklund)]

@sam,

I have submitted a reply back to your rejection of the PR:
Optional 'no_user_found_return_sso_url' parameter for using Discourse as SSO by reverendpaco · Pull Request #4211 · discourse/discourse · GitHub

As I have been relying on my patched version of discourse for these months, I would be interested in convincing you as to my need.

[reverend_paco (Daniel Eklund)]

@reverend_paco

@sam,

I have submitted a reply back to your rejection of the PR:
Optional 'no_user_found_return_sso_url' parameter for using Discourse as SSO by reverendpaco · Pull Request #4211 · discourse/discourse · GitHub

As I have been relying on my patched version of discourse for these months, I would be interested in convincing you as to my need.

If this PR is going to be rejected, could you explain what I can do to get the functionality that I need?

[Sveinn_S (Sveinn Svavarsson)]

Does anyone know of a wordpress plugin that works with discourse as the SSO provider?