সিএএস বা ওউথের সাথে এসএসও?


184

আমি ভাবছি যদি আমার একক সাইন- অনের জন্য CAS প্রোটোকল বা OAuth + কিছু প্রমাণীকরণ সরবরাহকারী ব্যবহার করা উচিত।

উদাহরণ পরিস্থিতি:

  1. একজন ব্যবহারকারী একটি সুরক্ষিত সংস্থান অ্যাক্সেস করার চেষ্টা করে, তবে তা প্রমাণীকরণ হয় না।
  2. অ্যাপ্লিকেশনটি ব্যবহারকারীকে এসএসও সার্ভারে পুনঃনির্দেশ করে।
  3. মৌমাছিকরণ প্রমাণিত হলে ব্যবহারকারী এসএসও সার্ভার থেকে একটি টোকেন পান।
  4. এসএসও মূল অ্যাপ্লিকেশনটিতে পুনঃনির্দেশ করে।
  5. মূল অ্যাপ্লিকেশনটি এসএসও সার্ভারের বিপরীতে টোকেনটি পরীক্ষা করে।
  6. যদি টোকেন ঠিক থাকে তবে অ্যাক্সেসের অনুমতি দেওয়া হবে এবং অ্যাপ্লিকেশনটি ব্যবহারকারীর আইডি সম্পর্কে জানবে।
  7. ব্যবহারকারী একটি লগ-আউট সম্পাদন করে এবং একই সাথে সমস্ত সংযুক্ত অ্যাপ্লিকেশন থেকে লগ আউট হয় (একক সাইন আউট)।

যতদূর আমি বুঝতে পেরেছি ঠিক এটিই সিএএস আবিষ্কার হয়েছিল। অনুমোদনের পরিষেবাটি ব্যবহারের জন্য সিএএস ক্লায়েন্টদের সিএএস প্রোটোকলটি প্রয়োগ করতে হবে। এখন আমি ক্লায়েন্ট (ভোক্তা) সাইটে সিএএস বা ওআউথ ব্যবহার করার বিষয়ে ভাবছি। ওএথ কি সিএএসের সেই অংশের প্রতিস্থাপন? নতুন ডি-ফ্যাক্টো স্ট্যান্ডার্ড হিসাবে ওএউথকে কী পছন্দ করা উচিত? ব্যবহারকারীর নাম / পাসওয়ার্ড, ওপেনআইডি, টিএলএস সার্টিফিকেটস ... এর মতো বিভিন্ন পদ্ধতি সমর্থনকারী সিএএসের অনুমোদনের অংশের জন্য কি সহজে ব্যবহার করার (সান ওপেনএসএসও নয়!) প্রতিস্থাপন রয়েছে?

প্রসঙ্গ:

  • বিভিন্ন অ্যাপ্লিকেশনগুলির এসএসও সার্ভারের প্রমাণীকরণের উপর নির্ভর করা উচিত এবং সেশন-জাতীয় কিছু ব্যবহার করা উচিত।
  • অ্যাপ্লিকেশনগুলি জিইউআই ওয়েব অ্যাপ্লিকেশন বা (আরএসটি) সার্ভিস হতে পারে।
  • এসএসও সার্ভারকে অবশ্যই একটি ব্যবহারকারী আইডি সরবরাহ করতে হবে, যা কেন্দ্রীয় ব্যবহারকারী তথ্য স্টোর থেকে ভূমিকা, ইমেল ইত্যাদির মতো ব্যবহারকারীর সম্পর্কে আরও তথ্য পাওয়ার জন্য প্রয়োজনীয়।
  • একক সাইন আউট সম্ভব হওয়া উচিত।
  • বেশিরভাগ ক্লায়েন্ট জাভা বা পিএইচপি লিখিত হয়।

আমি সবেমাত্র Wrap আবিষ্কার করেছি , যা OAuth উত্তরসূরি হতে পারে। এটি মাইক্রোসফ্ট, গুগল এবং ইয়াহু দ্বারা নির্দিষ্ট একটি নতুন প্রোটোকল।

অভিযোজ্য বস্তু

আমি শিখেছি যে OAuth প্রমাণীকরণের জন্য ডিজাইন করা হয়নি এমনকি এটি এসএসও বাস্তবায়নের জন্য ব্যবহার করা যেতে পারে তবে কেবল একসাথে ওপেনআইডিএস এর মতো এসএসও পরিষেবা দিয়ে।

ওপেনআইডি আমার কাছে "নতুন সিএএস" বলে মনে হচ্ছে। সিএএস-এর কয়েকটি বৈশিষ্ট্য ওপেনআইডি মিস (যেমন একক সাইন আউট), তবে কোনও নির্দিষ্ট দৃশ্যে অনুপস্থিত অংশগুলি যুক্ত করা শক্ত হওয়া উচিত নয়। আমি মনে করি ওপেনআইডিটির ব্যাপক গ্রহণযোগ্যতা রয়েছে এবং অ্যাপ্লিকেশন বা অ্যাপ্লিকেশন সার্ভারগুলিতে ওপেনআইডিআইডি সংহত করা ভাল। আমি জানি যে সিএএস ওপেনআইডি সমর্থন করে তবে আমি মনে করি ওপেনআইডি-র মাধ্যমে সিএএস ব্যয়যোগ্য।


6
একক সাইন আউট একটি বিরোধী বৈশিষ্ট্য। আমি যে সমস্ত ব্যবহারকারী স্টাডি সম্পর্কে অবহিত রয়েছি তা এটিকে আবৃত করে রেখেছে যে এটি কোথাও কোথাও নবজাতক এবং শক্তি ব্যবহারকারীদের কাছে অত্যন্ত বিভ্রান্তিকর থেকে শুরু করে। আমাকে ব্যক্তিগতভাবে এমন একটি সিস্টেম ব্যবহার করতে হবে যা প্রতিদিনের ভিত্তিতে একক সাইন-আউট ব্যবহার করে এবং আমি এটি অবিশ্বাস্যরূপে বিরক্তিকর বলে মনে করি। এটি আমি চাই আচরণের প্রায় না।
বব আমান

16
একমত সাইন আউট হ'ল একটি antifeature যে সম্মত হন না। এটি সমস্ত প্রশ্নযুক্ত অ্যাপ্লিকেশনগুলির উপর নির্ভর করে। ওয়েব অ্যাপ্লিকেশনগুলির জন্য যা একরকম অন্যটির সাথে সম্পর্কিত, যেমন গুগল মেল এবং গুগল ক্যালেন্ডার, এটি বুঝতে পারছে যে আপনি যদি একটির বাইরে স্পষ্টভাবে লগআউট করেন তবে আপনি অন্যটির লগআউট করেন। অ্যাপ্লিকেশনগুলির ক্ষেত্রে যেখানে আপাত "সম্পর্ক" নেই, আমি বব এর সাথে একমত নই।
অ্যাশউডস

6
দ্রষ্টব্য যে এই প্রশ্নটি OAuth 2.0 চালু হওয়ার আগে মূলত জিজ্ঞাসা করা হয়েছিল, সুতরাং OAuth সম্পর্কিত তথ্য আর সঠিক হতে পারে না।
অ্যান্ড্রু

উত্তর:


238

ওপেনআইডি সিএএস-এর 'উত্তরসূরি' বা 'বিকল্প' নয়, এগুলি ভিন্ন, উদ্দেশ্য এবং বাস্তবায়নের ক্ষেত্রে।

সিএএস প্রমাণীকরণকে কেন্দ্রিয় করে তোলে। আপনি যদি আপনার সমস্ত (সম্ভবত অভ্যন্তরীণ) অ্যাপ্লিকেশনগুলি ব্যবহারকারীদের একটি একক সার্ভারে লগইন করতে বলেন (সমস্ত অ্যাপ্লিকেশনগুলি একটি সিএএস সার্ভারে নির্দেশ করার জন্য কনফিগার করা আছে)।

ওপেনআইডিটি অনুমোদনের বিকেন্দ্রীকরণ করে । আপনি যদি অ্যাপ্লিকেশন ব্যবহারকারীদের যে কোনও প্রমাণীকরণ পরিষেবা চান তা লগইন গ্রহণ করতে চান তবে এটি ব্যবহার করুন (ব্যবহারকারী ওপেনআইডি সার্ভারের ঠিকানা সরবরাহ করে - আসলে 'ব্যবহারকারীর নাম' সার্ভারের ইউআরএল)।

উপরের কোনও হ্যান্ডেল অনুমোদন (এক্সটেনশন এবং / বা কাস্টমাইজেশন ছাড়াই)।

OAuth অনুমোদন পরিচালনা করে, তবে এটি theতিহ্যবাহী 'USER_ROLES টেবিল' (ব্যবহারকারী অ্যাক্সেস) এর বিকল্প নয় not এটি তৃতীয় পক্ষের জন্য অনুমোদন পরিচালনা করে।

উদাহরণস্বরূপ, আপনি নিজের অ্যাপ্লিকেশনটি টুইটারের সাথে সংহত করতে চান: কোনও ব্যবহারকারী যখন তাদের ডেটা আপডেট করে বা নতুন সামগ্রী পোস্ট করে তবে এটি স্বয়ংক্রিয়ভাবে টুইট করার অনুমতি দিতে পারে। আপনি কোনও ব্যবহারকারীর পক্ষে পাসওয়ার্ড না পেয়ে কিছু তৃতীয় পক্ষের পরিষেবা বা সংস্থান অ্যাক্সেস করতে চান (এটি সম্ভবত ব্যবহারকারীর পক্ষে অনিরাপদ)। অ্যাপ্লিকেশনটি অ্যাক্সেসের জন্য টুইটারকে জিজ্ঞাসা করে, ব্যবহারকারী এটি (টুইটারের মাধ্যমে) অনুমোদন দেয় এবং তারপরে অ্যাপ্লিকেশনটির অ্যাক্সেস থাকতে পারে।

সুতরাং, ওআউথ একক সাইন-অন সম্পর্কে নয় (না সিএএস প্রোটোকলের বিকল্প)। ব্যবহারকারী কী অ্যাক্সেস করতে পারে তা আপনার নিয়ন্ত্রণ করার বিষয়ে নয় । এটি ব্যবহারকারীদের কীভাবে তাদের সংস্থানগুলি তৃতীয় পক্ষগুলি অ্যাক্সেস করতে পারে তা নিয়ন্ত্রণ করতে দেয়। দুটি খুব ভিন্ন ব্যবহারের ক্ষেত্রে।

আপনার বর্ণিত প্রসঙ্গে, সিএএস সম্ভবত সঠিক পছন্দ।

[আপডেট]

এটি বলেছে, আপনি যদি সুরক্ষিত সংস্থান হিসাবে ব্যবহারকারীর পরিচয় বিবেচনা করেন তবে আপনি OAuth এর সাথে এসএসও বাস্তবায়ন করতে পারেন। এটিই 'গিটহাবের সাথে সাইন আপ করুন' এবং পছন্দগুলি মূলত করে। সম্ভবত প্রোটোকলের মূল অভিপ্রায় নয়, তবে এটি করা যেতে পারে। আপনি যদি OAuth সার্ভারটি নিয়ন্ত্রণ করেন এবং অ্যাপগুলি কেবল এটির সাথে প্রমাণীকরণ করতে সীমাবদ্ধ রাখেন, এটি এসএসও।

লগআউটকে জোর করার কোনও মানক উপায় নেই, যদিও (সিএএস এর এই বৈশিষ্ট্যটি রয়েছে)।


11
যদিও ওআউথ মূলত অনুমোদনের বিষয়ে, এটি কোনও কেন্দ্রীয় প্রমাণীকরণের সার্ভারের মতো ব্যবহার করা যেতে পারে। যেমন OAuth সরবরাহকারীর কোনও পরিষেবা ব্যবহার না করেই গুগল ওআউথ অ্যাকাউন্ট প্রমাণীকরণের জন্য অনেকগুলি সাইট (এসও সহ) ব্যবহার করে Like
আমির আলী আকবরী

1
তদুপরি, বার্টল জবাব অনুসারে, সিএএস এখন ক্লায়েন্ট বা সার্ভার হিসাবে উভয়কে সরবরাহ করে।
অ্যান্টনি ও।

3
এই উত্তরটি কি এখনও প্রাসঙ্গিক যে OAuth 2.0 বিদ্যমান? OAuth 2.0 এর সাথে আপনার মতামত কীভাবে পরিবর্তিত হয়েছে?
অ্যান্ড্রু

6
OAuth 2.0 এখনও একটি অনুমোদন প্রোটোকল এবং কোনও প্রমাণীকরণ প্রোটোকল নয় তবে একটি প্রমাণীকরণ প্রোটোকল তৈরি করতে OAuth 2.0 এর শীর্ষে তৈরি করতে পারে, যা ফেসবুক / লিংকডইন ইত্যাদি করেছে; OAuth 2.0 এর একমাত্র মানক প্রসারণ যা প্রমাণীকরণ সরবরাহ করে সেটি হ'ল ওপেনআইডি কানেক্ট, যা ওপেনআইডি-র মনোনীত উত্তরসূরি
হ্যান্স জেড।

48

আমি এটি এইভাবে চিন্তা করার ঝোঁক:

সিএএস ব্যবহার করুন যদি আপনি ব্যবহারকারীর প্রমাণীকরণ সিস্টেমটি নিয়ন্ত্রণ / মালিকানাধীন হন এবং সেন্ট্রালাইজড প্রমাণীকরণের প্রয়োজন এমন সার্ভার এবং অ্যাপ্লিকেশনগুলির একটি ভিন্ন ভিন্ন সেট সমর্থন করার প্রয়োজন হয়।

আপনার নিজের / সমর্থিত নয় এমন সিস্টেমগুলি (যেমন গুগল, ফেসবুক, ইত্যাদি) থেকে ব্যবহারকারী প্রমাণীকরণ সমর্থন করতে চাইলে OAuth ব্যবহার করুন।


6
ওপেনআইডি একটি প্রমাণীকরণ প্রোটোকল, ওআউথ একটি অনুমোদন প্রোটোকল।
zenw0lf

13

ওপেনআইডি হ'ল একটি প্রমাণীকরণ প্রোটোকল, ওআউথ এবং ওআউথ র‌্যাপের অনুমোদন প্রোটোকল। এগুলিকে হাইব্রিড ওপেনআইডি এক্সটেনশনের সাথে একত্রিত করা যায় ।

আমি দৃ strongly়তার সাথে লোকদের এমন মানদণ্ডের শীর্ষে গড়ে তুলতে পছন্দ করব যাগুলির প্রচুর গতি রয়েছে (আরও উপলব্ধ সহায়তা, তৃতীয় পক্ষগুলিকে জড়িত করা সহজ), এমনকি যদি তারা হাতে থাকা অ্যাপ্লিকেশনটির জন্য উপযুক্ত নাও থাকে। এই ক্ষেত্রে, ওআউথের গতি আছে, সিএএস নয় not OAuth এর সাথে আপনার যা করতে হবে তার সমস্ত বা কমপক্ষে প্রায় সমস্ত করতে সক্ষম হবেন। ভবিষ্যতের কিছু পরে, ওআউথ র‌্যাপের বিষয়গুলিকে আরও সরল করা উচিত (এটি একটি বাহক টোকেন ব্যবহার করে এবং প্রোটোকল স্তরটিতে এনক্রিপশনটি চাপিয়ে কিছুটা বাণিজ্য বানিয়ে তোলে) তবে এটি এখনও শৈশবকালেই রয়েছে এবং এরই মধ্যে OAuth সম্ভবত কাজ ঠিক কাজ করবে।

শেষ পর্যন্ত, আপনি যদি ওপেনআইডিআইডি এবং ওআউথ ব্যবহার করতে চান তবে আপনার জন্য এবং সিস্টেমের সাথে সংহত হওয়ার জন্য অন্য যে কোনও ব্যক্তির কাছে আরও ভাষার জন্য আরও গ্রন্থাগার রয়েছে। আপনার প্রোটোকলগুলির দিকে তাকাতে আরও অনেকগুলি চোখের বল রয়েছে, তারা নিশ্চিত হওয়া উচিত যে তারা সত্যই নিরাপদ secure


8

আমার কাছে SSO এবং OAuth এর মধ্যে আসল পার্থক্যটা অনুদান না প্রমাণীকরণ কারণ এমন একটি সার্ভার যা কার্যকরী স্পষ্টত OAuth হয়েছে প্রমাণীকরণ (আপনি OAuth ক্লায়েন্ট অ্যাপ্লিকেশন দিয়ে ঘটতে জন্য আপনার Google, OpenID বা Facebook এ লগ ইন করতে হবে আছে)

এসএসও-তে একটি পাওয়ার ব্যবহারকারী / সিসাদমিন OAuth- এ "এসএসও অ্যাপ্লিকেশন" এর আগে একটি অ্যাপ্লিকেশনটিতে চূড়ান্ত ব্যবহারকারীর অ্যাক্সেসকে মঞ্জুরি দেয়, চূড়ান্ত ব্যবহারকারী "OAuth অ্যাপ্লিকেশন" এর "ডেটা" তে অ্যাপ্লিকেশন অ্যাক্সেসকে মঞ্জুর করে

আমি দেখতে পাচ্ছি না যে কেন OAuth প্রোটোকলটি কোনও এসএসও সার্ভারের অংশ হিসাবে ব্যবহার করা গেল না। কেবল প্রবাহ থেকে অনুদানের স্ক্রীনটি নিয়ে যান এবং ওএথ সার্ভারকে ব্যাকিং ডিবি থেকে অনুদানটি অনুসন্ধান করতে দিন।


7

পুরানো পোস্ট, তবে এটি কার্যকর হতে পারে:

সিএএস 3.5 ক্লায়েন্ট এবং সার্ভার হিসাবে ওআউথকে সমর্থন করবে। দেখুন: https://wiki.jasig.org/display/CASUM/OAuth


3
লোকেরা এটি দেখে এবং সম্ভবত বিভ্রান্ত হয়ে রয়েছে, এখানে CASউল্লিখিত হ'ল সিএএস প্রোটোকলের পরিবর্তে সিএএস সার্ভার
এনজি সেক লং
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.