সিঙ্গেল সাইন অন বা এস-এস-ও (Single Sign On - SSO)
অক্টোবর ১৬, ২০১৫, শুক্রবার।
একটা নতুন কনসেপ্ট-এর সাথে পরিচিত হলাম। যদিও অনেকদিন ধরেই তা ব্যবহার করে আসছি - কিন্তু ব্যাপারটা জানতাম না। সিঙ্গেল সাইন অন বা এস-এস-ও। আমার কাজের জায়গায় ইদানিং এটা নিয়ে বেশ জোরেসোরে কাজ হচ্ছে। এটা কী, কেনই বা দরকার - তার দুই-একটা উদাহরণ দেয়ার চেষ্টা করবো আজকের লেখায়।
সিনারিও -১:
অনেক ইউনিভার্সিটি-ই Microsoft Outlook বা Google -র Gmail ইমেইল একাউন্ট হিসাবে ব্যবহার করে। যদিও ইমেইল এড্রেস ইউনিভার্সিটির নিজস্ব হয়, যেমন আমারটা ছিল: ishtiaque[dot]hussain@mavs.uta.edu - কিন্তু সার্ভিসটা মাইক্রোসফট-এর। একই ভাবে অনেক কর্পোরেট কোম্পানিও তাদের ইমেইল সার্ভিস হিসাবে মাইক্রোসফট বা গুগল ব্যবহার করে। এখন প্রশ্ন হচ্ছে, এইসব ইউনিভার্সিটি বা কোম্পানি গুলোর ছাত্র/কর্মচারীদের লগইন/পাসওয়ার্ড কারা ম্যানেজ করবে? যদি মাইক্রোসফট/গুগল -এর ইঞ্জিনিয়ার বা ডাটাবেস অ্যাডমিনদের করতে হয়, তাহলে তো ওদের মাথা খারাপ হয়ে যাবে! কেননা, কোনো ছাত্র বা কর্মচারী যখন চলে যায়, তখন এদের একাউন্ট ডিএক্টিভেট করা, পাসওয়ার্ড ভুলে গেলে রিসেট করা - ইত্যাদি অনেক কাজ। তার উপর ওদের পার্সোনাল ইনফরমেশন (লগইন, পাসওয়ার্ড) নিরাপদ রাখাও তো একটা চ্যালেন্জ, ঠিক না?
সিনারিও - ২:
কোনো বড় কোম্পানি যখন ছোট ছোট অনেকগুলো কোম্পানি কিনে ফেলে, আমাদের ক্ষেত্রে যেমন Infor প্রায় ৭ টা ছোট ছোট কোম্পানি কিনে নিয়েছে, তখন এক কোম্পানির কাস্টমার আরেক বা একাধিক কোম্পানির সার্ভিস ফ্রি পেতে পারবে। কেননা, তখন সবাই-ই তো আসলে বড় কোম্পানির কাস্টমার (আমাদের ক্ষেত্রে যেমন Infor -র), তাই না? কিন্তু প্রশ্ন হচ্ছে, সবার সার্ভিসের তো লগইন, পাসওয়ার্ড আলাদা। Seamlessly এক সার্ভিস থেকে আরেক সার্ভিস-এ কীভাবে যাওয়া যায়?
দুই ক্ষেত্রেই যে প্রোটোকলটা সমস্যার সমাধান করে তার নাম: SAML বা Security Assertion Markup Language.
SAML -র স্পেসিফিকেশন অনেক জটিল হলেও, আইডিয়াটা কিন্তু বেশ সিম্পল।
একটা Identity Provider (IDP) থাকবে যার কাজ হবে ইউসার-এর লগইন, পাসওয়ার্ড, রোল ইত্যাদি মেইন্টেইন করা। কর্পোরেট গুলোর (নিচের ছবিতে পার্টনার) দায়িত্ব হবে IDP সামলানো। যখন কোনো ইউসার ওয়েব ব্রাউসার ব্যবহার করে প্রথম বারের মত কোনো সার্ভিস প্রোভাইডার (SP)-এর সার্ভিস এক্সেস করতে যাবে (যেমন কর্পোরেট ইমেইল যা কিনা মাইক্রোসফট/গুগলের ইমেইল, বা ছোট কোনো কোম্পানির সার্ভিস) তখন তা IDP -র কাছে রিডাইরেক্ট করে দিবে। IDP -র কাজ হবে ইউসার-এর লগইন/পাসওয়ার্ড নিয়ে ভেরিফাই করা আর ভেরিফাই হয়ে গেলে একটা টোকেন SP -র কাছে পাঠানো। এই টোকেন অবশ্য ডিজিটাল সিগনেচার, এনক্রিপ্ট করে পাঠানো হয় যাতে কেউ পরিবর্তন করতে না পারে। এই টোকেন আর কিছুই না - মূলত এটা সার্ভিস প্রোভাইডারকে বলবে যে “হ্যা, আমি একে চিনি, তুমি একে এক্সেস করতে দিতে পারো”।
আর এই যে রিডাইরেক্ট গুলো হবে, তা কিন্তু ইউসার-র অগোচরেই হবে। খুব খেয়াল করলে হয়তো ইউসার তার ব্রাউসার-র এড্রেস বারে url পরিবর্তন হতে দেখবে। আর একবার ভেরিফাই হয়ে গেলে, ব্রাউসার-এর কুকি ব্যবহার করে (যতক্ষণ না কুকির সময় expire বা শেষ না হচ্ছে) ইউসার অন্য সার্ভিস গুলো ব্যবহার করতে পারবে - নতুন করে লগইন না করেই!
নিচে গুগল ডেভেলপার'স ব্লগ থেকে নেয়া একটা ডায়াগ্রাম দিলাম :
 |
| Diagram by Google |
ACS = গুগল-র Assertion Consumer Service
আর এই পুরো ব্যাপারটাই সিঙ্গেল সাইন অন বা এস-এস-ও। চিন্তা করে দেখুন, IDP থাকাতে, আর তা সামলানোর দায়িত্ব কর্পোরেট কোম্পানিগুলোর নিজেদের হওয়াতে কতগুলো সুবিধা হচ্ছে:
১. কোম্পানির কর্মচারী চলে গেলে বা রোল/দায়িত্ব বদলালে, কোম্পানি নিজেই তার লগইন/পাসওয়ার্ড ডিএক্টিভেট করতে পারছে। সার্ভিস প্রোভাইডার-এর কাছে ধর্ণা দিতে হচ্ছে না।
২. সার্ভিস প্রোভাইডার-র কাস্টমার-র লগইন/পাসওয়ার্ড জানতে বা সামলাতে হচ্ছে না।
৩. সার্ভিস প্রোভাইডার-এর কাছে এইসব ইনফরমেশন না থাকায় সিকিউরিটি লিক হয়ে বিপদে পড়ার সম্ভাবনা থাকছে না।
৪. এক লগইন/পাসওয়ার্ড দিয়েই অনেকগুলো সাব-সার্ভিস কাস্টমার পেতে পারছে। প্রতিটা সাব-সার্ভিসের জন্য আর আলাদা লগইন/পাসওয়ার্ড মনে রাখতে হচ্ছে না।
যাই হোক, শেষ করি। আজকের লেখার পুরাটাই নিচের ২/৩ টা লিংক থেকে নেয়া।
রেফারেন্স:
ধন্যবাদ
--ইশতিয়াক।
No comments:
Post a Comment