VPN SSO কি ব্যবহারকারীদের অভ্যন্তরীণ অ্যাপে স্বয়ংক্রিয়ভাবে সাইন ইন করায়?
একটি সাইন-ইন টানেল এবং তার পিছনের অ্যাপগুলো ঢাকতে পারে, তবে কেবল তখনই যখন প্রতিটি অ্যাপের নিজস্ব বিশ্বাস থাকে। এটিকে সংযুক্ত ও পরীক্ষা করার ক্রম এখানে দেওয়া হলো।
একটি পরিচয় প্রদানকারীর মাধ্যমে প্রমাণীকরণ করা VPN গেটওয়ে কেবল একটি বিষয় প্রমাণ করে: প্রদানকারী গেটওয়ের কাছে একজন ব্যবহারকারীর পক্ষে জামিন দিয়েছে। এটি সেই ব্যবহারকারীকে ইন্ট্রানেট উইকি, মনিটরিং ড্যাশবোর্ড বা বিল্ড সার্ভারের জন্য কোনো প্রমাণপত্র দেয় না। ওই সেবাগুলো নিজেদের ফেডারেশনের মাধ্যমে মানুষকে সাইন ইন করায় এবং নিজেদের অনুমোদন প্রয়োগ করে, আর টানেল কেবল ঠিক করে কোন প্যাকেটগুলো তাদের কাছে পৌঁছাতে পারে।
তিনটি সেশন, তিনটি পৃথক সিদ্ধান্ত
অবস্থাগুলো আলাদা রাখুন, কারণ প্রতিটি নিজের সময়সূচিতে শেষ হয়। VPN সেশন হলো একটি পরিচয়ের প্রতি গেটওয়ের স্বীকৃতি এবং যে নেটওয়ার্ক অ্যাক্সেস এটি দিয়েছে। পরিচয় প্রদানকারীর ব্রাউজার সেশন হলো ব্রাউজার ওই প্রদানকারীর জন্য যা এখনো ধরে রাখে এবং তার নীতির অধীনে পুনরায় ব্যবহার করতে পারে। অ্যাপ্লিকেশন সেশনটি এমন একটি সেবার, যা তার কাছে পাঠানো একটি উত্তর যাচাই করেছে।
এই অবস্থাগুলো গুলিয়ে ফেললে ভুল প্রশ্ন তৈরি হয়, সাধারণত এভাবে বলা হয় কেন টানেল ব্যবহারকারীকে সর্বত্র সাইন ইন করায় না। প্রশ্নটি বদলে বলুন: কোন অ্যাপের ফেডারেশন এন্ট্রি নেই, কোনটি ব্যবহারকারীকে প্রত্যাখ্যান করে, আর কোনটির রুট নেই। ইন্ট্রানেট অ্যাপ খোলা একটি একক সাইন-ইন প্রম্পট তবুও প্রদানকারীর কাছে ফিরে যেতে পারে, কারণ দ্বিতীয় রিডাইরেক্ট ভিন্ন অডিয়েন্সের জন্য নতুন অনুমোদন অনুরোধ।
গেটওয়েকে তার নিজস্ব অ্যাপ হিসেবে যুক্ত করুন
প্রদানকারীর কাছে VPN-কে অনুমোদিত অ্যাপ হিসেবে নিবন্ধন করুন, নিজস্ব শনাক্তকারী, রিডাইরেক্ট URI এবং ব্যবহারকারী নির্ধারণসহ। তারপর ঠিক করুন ওই লগইন কোন নেটওয়ার্ক অনুমোদন দেয়, কারণ এটি প্রদানকারীর বৈশিষ্ট্য নয়, VPN নীতি। যাদের কেবল মনিটরিং সাবনেটে পৌঁছানো উচিত তারা ভিন্ন গেটওয়ে নীতি পায়, ভিন্ন পাসওয়ার্ড নয়।
টানেলের প্রমাণীকরণ উত্তর পুনরায় ব্যবহারযোগ্য প্রমাণপত্র নয়। OIDC আইডি টোকেনে অডিয়েন্স দাবি থাকে যা সেই ক্লায়েন্টের নাম বলে যার জন্য সেগুলো তৈরি, আর SAML বিয়ারার অ্যাসার্শন অডিয়েন্সকে গ্রহণকারী সেবা প্রদানকারীতে সীমাবদ্ধ করে। যে দ্বিতীয় সেবা প্রথম সেবার উত্তর গ্রহণ করে সেটি ভুলভাবে কনফিগার করা, আর একটি অ্যাপে টোকেন কপি করা ইন্টিগ্রেশন নয়।
প্রতিটি অভ্যন্তরীণ অ্যাপ নিবন্ধন করুন, তারপর ব্রাউজার প্রসঙ্গ ঠিক করুন
প্রতিটি সেবার সমর্থিত SAML বা OIDC মান প্রয়োজন: ইস্যুয়ার, ক্লায়েন্ট শনাক্তকারী, কলব্যাক বা অ্যাসার্শন-কনজিউমার URL, প্রয়োজনীয় দাবি এবং নির্ধারণ। নাগালযোগ্যতা তার উপরে আসে, কারণ পরিচয় যাচাই কখনো রুট বা DNS উত্তর দেয় না।
- অ্যাপ্লিকেশন এন্ট্রি তৈরি করুন এবং নিশ্চিত করুন যে এন্টিটি বা ক্লায়েন্ট আইডি অ্যাপ যা পাঠায় তার সঙ্গে মেলে।
- স্কিম ও পোর্টসহ সঠিক কলব্যাক URL নিবন্ধন করুন; সামান্য ভুল ব্যবহারকারীর প্রমাণীকরণের পরে ব্যর্থ হয়।
- ব্যবহারকারী বা গ্রুপ নির্ধারণ করুন, তারপর নিশ্চিত করুন প্রয়োজনীয় দাবিগুলো প্রকাশিত হয়েছে।
- ব্যক্তিগত অ্যাপের পাশাপাশি পরিচয় প্রদানকারীর এন্ডপয়েন্টগুলোও অনুমোদন করুন, নইলে রিডাইরেক্ট সম্পূর্ণ হতে পারবে না।
ব্রাউজার প্রসঙ্গ ঠিক করে বিদ্যমান প্রদানকারী সেশন পুনরায় ব্যবহৃত হবে কি না। যে নেটিভ ক্লায়েন্ট সিস্টেম ব্রাউজার খোলে সে ওই অবস্থা ভাগ করতে পারে, কিন্তু নিজস্ব কুকি জারসহ এমবেডেড ভিউ সাধারণত পারে না। নতুন ব্রাউজার, প্রাইভেট উইন্ডো এবং দ্বিতীয় প্রোফাইল শূন্য থেকে শুরু হয়, যা প্রত্যাশিত, ভাঙা SSO কনফিগারেশন নয়।
প্রবাহটি চালান এবং দেখুন কোথায় থামে
ব্রাউজারের নেটওয়ার্ক প্যানেল দিয়ে পুনরুৎপাদন করুন এবং রিডাইরেক্ট চেইন দেখুন। কার্যকর একটি পাস একবারে একটি ধাপ অনুসরণ করে: গেটওয়ে থেকে প্রদানকারী, প্রদানকারী থেকে কোড বা অ্যাসার্শনসহ অ্যাপে, অ্যাপ থেকে প্রদানকারীর টোকেন এন্ডপয়েন্টে, অ্যাপ সেশন ইস্যু হয়। যে ধাপে চেইন থামে সেটিই ঠিক করার উপাদানের নাম বলে দেয়।
কমান্ড লাইনের দুটি যাচাই সাধারণ সন্দেহ মেটায়, আর দুটোই অ্যাডমিন হোস্ট থেকে চালানো নিরাপদ:
curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'যখন মেটাডেটা এমন এন্ডপয়েন্ট তালিকাভুক্ত করে যা আপনি কখনো নিবন্ধন করেননি, অ্যাপটি ভিন্ন টেন্যান্ট বা ইস্যুয়ারে নির্দেশ করছে। যখন অ্যাপে প্রথম অনুরোধ অপ্রত্যাশিত হোস্টে 302 উত্তর দেয়, তখন অ্যাপের ফেডারেশন কনফিগারেশনই দেখার জায়গা, VPN প্রোফাইল নয়।
কে জিজ্ঞেস করেছে তা খুঁজে প্রম্পট ঠিক করুন
দ্বিতীয় পাসওয়ার্ড প্রম্পট স্বয়ংক্রিয়ভাবে ত্রুটি নয়। অ্যাপটি উচ্চতর আশ্বাস স্তর চাইতে পারে, অথবা প্রদানকারী সর্বোচ্চ সেশন বয়স এবং নতুন চ্যালেঞ্জ প্রয়োগ করতে পারে. প্রবাহকে শান্ত করতে ওই প্রয়োজনীয়তাগুলো সরানো ইচ্ছাকৃত নিয়ন্ত্রণ দুর্বল করে, তাই নীতি বদলানোর আগে নির্ধারণ করুন কোন উপাদান চেয়েছিল।
তারপর ঠিক করুন কী উন্নত করবেন। প্রম্পট অ্যাপ থেকে এলে তার ফেডারেশন এন্ট্রি ঠিক করুন। নীতি অনুসারে প্রদানকারী থেকে এলে প্রয়োজনীয়তা লিখে রাখুন। সফল সাইন-ইনের পরেও অ্যাপে পৌঁছানো না গেলে সন্দেহ টানেলের রাউটিং, কারণ পরিচয় ও প্যাকেট বিতরণ ভিন্ন জায়গায় ব্যর্থ হয় এবং ব্যবহারকারীর আসন থেকে একই রকম দেখায়।