SSO مع CAS أو OAuth؟

Question

أتساءل عما إذا كان يجب أن تستخدم كاس. البروتوكول أو OAuth. + بعض مزود المصادقة ل تسجيل الدخول الفردي.

مثال سيناريو:

1. يحاول المستخدم الوصول إلى مورد محمي، ولكن غير مصادق عليه.
2. يقوم التطبيق بإعادة توجيه المستخدم إلى خادم SSO.
3. إذا تم مصادقة Beeing، يحصل المستخدم على رمز رمزي من خادم SSO.
4. يعيد SSO إلى التطبيق الأصلي.
5. يتحقق التطبيق الأصلي الرمز المميز مقابل خادم SSO.
6. إذا كان الرمز المميز على ما يرام، فسيتم السماح بالوصول والتطبيق يعرف معرف المستخدم.
7. يقوم المستخدم بإجراء تسجيل خروج وتسجيل الخروج من جميع التطبيق المتصل في نفس الوقت (تسجيل الخروج واحد).

بقدر ما أفهم أن هذا هو بالضبط ما تم اختراعه من أجل. يتعين على عملاء CAS تنفيذ بروتوكول CAS لاستخدام خدمة المصادقة. الآن أنا أتساءل عن استخدام CAS أو OAuth في موقع العميل (المستهلك). هل OAuth بديل لهذا الجزء من CAS؟ يجب أن يكون oAuth كمعيار جديد في الواقع؟ هل هناك استبدال سهلة الاستخدام (وليس Sun Opensso!) لاستبدال جزء المصادقة من CAS دعم طرق مختلفة مثل اسم المستخدم / كلمة المرور، OpenID، TLS Certifactes ...؟

سياق الكلام:

• يجب أن تعتمد التطبيقات المختلفة على مصادقة خادم SSO ويجب استخدام شيء ما تشبه الجلسة.
• يمكن أن تكون التطبيقات تطبيقات ويب GUI أو (الراحة).
• يجب تقديم خادم SSO معرف مستخدم، وهو أمر ضروري للحصول على مزيد من المعلومات حول المستخدمين مثل الأدوار والبريد الإلكتروني وما إلى ذلك من متجر معلومات المستخدم المركزي.
• يجب أن يكون تسجيل الدخول الموحد ممكنا.
• معظم العملاء مكتوبة في Java أو PHP.

انا فقط اكتشف التفاف, ، والتي يمكن أن تصبح خليفة oAuth. إنه بروتوكول جديد يحدده Microsoft و Google و Yahoo.

إضافة

لقد تعلمت أن OAuth لم يتم تصميمه للمصادقة حتى أنه يمكن استخدامه لتنفيذ SSO، ولكن فقط جنبا إلى جنب مع خدمة SSO مثل OpenID.

يبدو لي OpenID لي أن أكون "CAS الجديد". CAS لديه بعض الميزات تفوت OpenID (مثل تسجيل الخروج واحد)، ولكن لا ينبغي أن يكون من الصعب إضافة الأجزاء المفقودة في سيناريو معين. أعتقد أن OpenID لديه قبول واسع، ومن الأفضل دمج OpenID في تطبيقات أو خوادم التطبيقات. أعلم أن CAS يدعم أيضا OpenID، لكنني أعتقد أن CAS يتم الاستغناء عن OpenID.

Answer 1

OpenID ليس "خلفا" أو "بديلا" ل CAS، فهي مختلفة، في النية وفي التنفيذ.

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

openid. اللامركزية المصادقة. استخدمه إذا كنت تريد تطبيق طلبك من قبول تسجيل الدخول للمستخدمين إلى أي خدمة المصادقة التي يريدونها (يوفر المستخدم عنوان خادم OpenID - في الواقع، فإن عنوان "اسم المستخدم" هو عنوان URL للخادم).

لا شيء من إذن التعامل أعلاه (بدون ملحقات و / أو تخصيص).

Oauth يتعامل مع إذن، لكنه ليس بديلا عن "جدول المستخدم" التقليدي (وصول المستخدم). إنها تعالج إذن لأطراف ثالثة.

على سبيل المثال، تريد دمج طلبك مع Twitter: يمكن للمستخدم السماح له بالتويت تلقائيا عند تحديث بياناتها أو نشر محتوى جديد. تريد الوصول إلى بعض خدمة أو مورد لجهة خارجية نيابة عن مستخدم، دون الحصول على كلمة مروره (التي من الواضح أنها غير آمنة للمستخدم). التطبيق يسأل twitter للوصول، المستعمل يخوله (من خلال Twitter)، ثم قد يكون التطبيق الوصول إليه.

لذلك، OAuth لا يتعلق بتسجيل الدخول الوحيد (ولا بديل لبروتوكول CAS). ليس حول أنت التحكم في ما يمكن للمستخدم الوصول إليه. الأمر يتعلق بالترك المستعمل للسيطرة على كيفية ذلك هم يمكن الوصول إلى الموارد من قبل أطراف ثالثة. اثنين من حالات استخدام مختلفة جدا.

إلى السياق الذي وصفته، ربما يكون CAS هو الاختيار الصحيح.

محدث

ومع ذلك، يمكنك تنفيذ SSO مع OAuth، إذا كنت تفكر في هوية المستخدم كمورد مضمون. هذا هو ما "اشترك مع Github" و Likes Do، أساسا. ربما لا تكون النية الأصلية للبروتوكول، ولكن يمكن القيام به. إذا قمت بالتحكم في خادم Oauth، وقم بتقييد التطبيقات للمصادقة معها فقط، فهذا SSO.

لا طريقة قياسية لفرض تسجيل الخروج، على الرغم من (CAS له هذه الميزة).

Answer 2

أميل إلى التفكير في الأمر بهذه الطريقة:

استخدم CAS إذا كنت تحكم / تملك نظام مصادقة المستخدم وتحتاج إلى دعم مجموعة غير متجانسة من الخوادم والتطبيقات التي تحتاج إلى مصادقة مركزية.

استخدم OAuth إذا كنت ترغب في دعم مصادقة المستخدم من الأنظمة التي لا تملكها / تدعمها (أي Google و Facebook وما إلى ذلك).

Answer 3

openid. هو بروتوكول المصادقة، OAuth. و ouuth التفاف هي بروتوكولات التفويض. يمكن دمجها مع الهجين openid التمديد.

سأفضل بشدة أن أرى الناس بناء على أعلى المعايير التي لها الكثير من الزخم (الدعم المتاح أكثر، أسهل للحصول على أطراف ثالثة المعنية)، حتى لو لم تكن ملائمة بالضبط للتطبيق في متناول اليد. في هذه الحالة، لدى OAuth الزخم وليس CAS. يجب أن تكون قادرا على القيام بكل ما أو على الأقل تقريبا ما عليك القيام به مع OAuth. في وقت لاحق من ذلك في المستقبل، يجب على التفاف Oauth تبسيط الأمور أكثر (يجعل بعض المقايضات القيمة باستخدام رمزية حامل ودفع التشفير وصولا إلى طبقة البروتوكول)، لكنها لا تزال في مهدها، وفي هذه الأثناء، OAuth ربما تفعل الوظيفة جيدة فقط.

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

Answer 4

المشاركة القديمة، ولكن قد يكون هذا مفيدا:

سيدعم CAS 3.5 OAuth كعميل وخادم. يرى: https://wiki.jasig.org/display/casum/oauth.

Answer 5

بالنسبة لي، فإن الفرق الحقيقي بين SSO و OAuth هو المنح، وليس المصادقة لأن الخادم الذي ينفذ OAuth من الواضح لديها المصادقة (يجب تسجيل الدخول إلى Google أو OpenID أو Facebook للحصول على OAuth لتطبيق العميل)

في SSO، يمنح مستخدم الطاقة / Sysadmin الوصول إلى المستخدم النهائي إلى تطبيق مسبقا على "تطبيق SSO" في OAuth، وصول تطبيق المستخدم النهائي إلى "بيانات" في "تطبيق Oauth"

لا أرى لماذا لا يمكن استخدام بروتوكول OAUTH كجزء من خادم SSO. ما عليك سوى إخراج شاشة المنحة من التدفق والسماح لخادم OAuth بالمنحة من الدعم DB.