আপনি সম্ভবত ইতিমধ্যেই এটির সম্মুখীন হচ্ছেন। কর্মীরা Microsoft 365-এ সাইন ইন করেন, তারপর একটি বুকিং টুলে, তারপর HR-এ, তারপর একটি লাইন-অফ-বিজনেস অ্যাপে, তারপর কর্পোরেট WiFi-এ, প্রায়শই প্রতিটির জন্য আলাদা পদ্ধতি ব্যবহার করে। একটি হোটেল গ্রুপের হেড অফিসে এক সেট সিস্টেম এবং প্রপার্টিতে অন্য সেট সিস্টেম থাকে। একটি হাসপাতালের ক্লিনিকাল অ্যাপ, শেয়ার করা ওয়ার্কস্টেশন এবং সেগমেন্টেড ওয়্যারলেস অ্যাক্সেস থাকে। একজন রিটেল অপারেটরের কর্মীরা স্টোর, ট্যাবলেট, POS এবং ব্যাক-অফিস ড্যাশবোর্ডের মধ্যে যাতায়াত করেন।
এই মিশ্রণটি দ্রুত জটিলতা তৈরি করে। ব্যবহারকারীরা পাসওয়ার্ড ভুলে যান, আইটি টিম অ্যাকাউন্ট রিসেট করে এবং শেয়ার্ড WiFi ক্রেডেনশিয়ালগুলি সরিয়ে ফেলার অনেক পরেও থেকে যায়। এর ফলে শুধু বিরক্তিরই সৃষ্টি হয় না। বরং কে, কোন ডিভাইস থেকে এবং কতক্ষণের জন্য কী অ্যাক্সেস করতে পারছে তার উপর নিয়ন্ত্রণ দুর্বল হয়ে যায়।
সেখানেই single sign-on, বা SSO, দরকারী হয়ে ওঠে। আপনি যদি what is single sign on খুঁজছেন, তবে সংক্ষিপ্ত উত্তরটি সহজ: এটি একজন ব্যবহারকারীকে একবার অথেন্টিকেট করার অনুমতি দেয় এবং তারপরে বারবার ক্রেডেনশিয়াল প্রবেশ না করেই একাধিক অনুমোদিত সিস্টেমে অ্যাক্সেস দেয়। আরও দরকারী উত্তরটি অপারেশনাল। SSO আইটি-কে অ্যাপ্লিকেশনে অ্যাক্সেসের জন্য একটি আইডেন্টিটি লেয়ার প্রদান করে এবং সঠিক ডিজাইনে, এটি মানুষ ও ডিভাইসগুলি কীভাবে সুরক্ষিত নেটওয়ার্কে যুক্ত হবে তাও সমর্থন করতে পারে।
পাসওয়ার্ডের বিশৃঙ্খলার অবসান
বেশিরভাগ এন্টারপ্রাইজ পরিবেশ ইচ্ছাকৃতভাবে অগোছালো হয়ে ওঠেনি। এগুলো এভাবেই বড় হয়েছে। একটি ক্লাউড অ্যাপ থেকে পাঁচটি হয়েছে। একটি অফিস থেকে অনেকগুলো সাইট হয়েছে। IT-এর জন্য একটিমাত্র ওয়্যারলেস নেটওয়ার্ক থেকে স্টাফ, গেস্ট, ঠিকাদার এবং ডিভাইসের জন্য আলাদা আলাদা SSID তৈরি হয়েছে।
এভাবেই পাসওয়ার্ডের বিশৃঙ্খলা শুরু হয়। কোনো কর্মীর আসল কাজ শুরু করার আগেই ইমেল, HR, শিডিউলিং, ফাইল অ্যাক্সেস, ইন্টারনাল ড্যাশবোর্ড এবং নেটওয়ার্ক অ্যাক্সেসের প্রয়োজন হতে পারে। IBM SSO-কে এমন একটি স্কিম হিসেবে বর্ণনা করে যেখানে ব্যবহারকারীরা এক সেট ক্রেডেন্সিয়াল দিয়ে একবার লগ ইন করেন এবং একই সেশনের সময় একাধিক অ্যাপ্লিকেশন অ্যাক্সেস করতে পারেন, যা পরিষেবা প্রদানকারী এবং একটি পরিচয় প্রদানকারীর মধ্যে একটি বিশ্বস্ত সম্পর্কের মাধ্যমে সম্ভব হয়। IBM-এর single sign-on এর ওভারভিউ যুক্তরাজ্যের প্রতিষ্ঠানগুলোর প্রয়োজনীয়তার সাথে হুবহু মিলে যায় যখন ক্লাউড গ্রহণ এবং রিমোট ওয়ার্ক দ্রুত বৃদ্ধি পেয়েছিল।
পাসওয়ার্ডের বিশৃঙ্খলা কার্যক্রমে কী প্রভাব ফেলে
যখন প্রতিটি অ্যাপ্লিকেশন নিজস্ব লগইন চায়, ব্যবহারকারীরা তখন সহজ পথ খোঁজা শুরু করেন। তারা পাসওয়ার্ড পুনরায় ব্যবহার করেন। তারা ব্রাউজারে সেগুলো সংরক্ষণ করেন। তারা সহকর্মীদের কাছে "স্টাফ WiFi পাসওয়ার্ড" চান কারণ এটি IT-এর জন্য অপেক্ষা করার চেয়ে দ্রুত কাজ করে।
একজন এন্টারপ্রাইজ IT ম্যানেজারের জন্য নিয়ন্ত্রণ সবচেয়ে গুরুত্বপূর্ণ বিষয়। আলাদা আলাদা লগইন অ্যাক্সেসের আলাদা আলাদা দ্বীপ তৈরি করে, এবং যখন কর্মচারীরা রোল পরিবর্তন করেন, ব্যবসা ছেড়ে চলে যান বা একাধিক লোকেশনে কাজ করেন, তখন সেই দ্বীপগুলো পরিচালনা করা কঠিন হয়ে পড়ে।
পাসওয়ার্ডের বিশৃঙ্খলা সাধারণত কোনো বড় বিপর্যয় নয়। এটি সাধারণত একশত ছোট ছোট অ্যাক্সেসের সিদ্ধান্ত যা কেউ ধারাবাহিকভাবে পরিচালনা করতে পারে না।
SSO কেন সম্পূর্ণ দৃশ্যপট পরিবর্তন করে দেয়
SSO ব্যবহারকারীদের পরিচালনা করার জন্য প্রয়োজনীয় পাসওয়ার্ডের সংখ্যা কমিয়ে দেয়, যা লগইন অভিজ্ঞতাকে উন্নত করে এবং কেন্দ্রীয় পলিসি ও MFA-এর সাথে যুক্ত হলে আরও শক্তিশালী নিরাপত্তা নিশ্চিত করে। এটি এমন বিস্তৃত প্রতিষ্ঠানের বাস্তবতার সাথেও মানানসই যেখানে কর্মীদের ইমেল, HR, বুকিং টুল, POS, অভ্যন্তরীণ অ্যাপস এবং সাইট পরিষেবা জুড়ে একটি মাত্র লগইন প্রয়োজন হয়।
এই একই যুক্তি এখন নেটওয়ার্ক অ্যাক্সেসকে নতুন রূপ দিচ্ছে। আপনি যদি ইতিমধ্যেই অ্যাপ্লিকেশনের জন্য আইডেন্টিটি-নেতৃত্বাধীন অ্যাক্সেসের দিকে অগ্রসর হন, তবে পাসওয়ার্ডহীন WiFi-কে একটি আলাদা সমস্যা হিসাবে না দেখে একই ডিজাইন পদ্ধতির অংশ হিসাবে বিবেচনা করা যৌক্তিক।
মূল SSO ধারণাটি বোঝা
SSO প্রতিটি পৃথক অ্যাপ্লিকেশন থেকে অথেন্টিকেশন সরিয়ে নেয় এবং এটিকে একটি বিশ্বস্ত পরিচয় সিস্টেমে স্থাপন করে। ব্যবহারকারী একবার সাইন ইন করেন, সেই পরিচয় যাচাই করা হয় এবং সংযুক্ত পরিষেবাগুলি অন্য পাসওয়ার্ড না চেয়ে সেই ফলাফলটি গ্রহণ করে।
এটি শুনতে সহজ মনে হলেও এর গুরুত্ব আর্কিটেকচারাল। আপনি ট্রাস্ট বা বিশ্বাসের অবস্থানটি পরিবর্তন করছেন।
প্রতিটি SSO ফ্লোতে থাকা তিনটি পক্ষ
প্রতিটি SSO ডিজাইনের তিনটি অংশীদার থাকে এবং প্রত্যেকের আলাদা কাজ থাকে:
- ব্যবহারকারী কোনো অ্যাপ্লিকেশন, পরিষেবা বা নেটওয়ার্ক রিসোর্সে অ্যাক্সেস চান।
- আইডেন্টিটি প্রোভাইডার বা IdP আইডেন্টিটি যাচাই করে এবং সাইন-ইন পলিসি প্রয়োগ করে। UK-র সংস্থাগুলিতে সাধারণ উদাহরণগুলির মধ্যে রয়েছে Microsoft Entra ID এবং Okta।
- সার্ভিস প্রোভাইডার বা SP হলো সেই সিস্টেম যেখানে ব্যবহারকারী পৌঁছানোর চেষ্টা করছেন, যেমন Salesforce, একটি বুকিং প্ল্যাটফর্ম, একটি ইন্ট্রানেট বা অন্য কোনো ব্যবসায়িক সিস্টেম।
যে বিষয়টি প্রায়ই বিভ্রান্তি তৈরি করে তা হলো ট্রাস্ট (trust)। অ্যাপ্লিকেশনটির নিজে পাসওয়ার্ড সংগ্রহ ও যাচাই করার প্রয়োজন নেই। এটি সঠিকভাবে সেই কাজটি করার জন্য IdP-এর ওপর নির্ভর করে, তারপর ফলাফলটি গ্রহণ করে।
ট্রাস্ট রিলেশনশিপ (trust relationship) বলতে আসলেই কী বোঝায়
Auth0 এন্টারপ্রাইজ পরিভাষায় SSO-কে স্পষ্টভাবে ব্যাখ্যা করে: IdP ব্যবহারকারীকে একবার প্রমাণীকরণ করে, তারপর একটি সেশন আর্টিফ্যাক্ট বা টোকেন ইস্যু করে যা বিশ্বস্ত পরিষেবা প্রদানকারীরা পরবর্তী অ্যাক্সেসের জন্য যাচাই করে। বাস্তবে, ব্যবহারকারীকে IdP-তে রিডাইরেক্ট করা হয়, সেখানে প্রমাণীকরণ করা হয় এবং বারবার ক্রেডেন্সিয়ালের অনুরোধ ছাড়াই প্রতিটি অ্যাপে ফিরিয়ে দেওয়া হয়। Auth0-এর how single sign-on works গাইডটি SaaS এবং অভ্যন্তরীণ সিস্টেম জুড়ে Microsoft Entra ID ব্যবহারকারী যুক্তরাজ্যের পরিবেশগুলোর জন্য বিশেষভাবে প্রাসঙ্গিক।
এটিকে সহজভাবে বোঝার একটি ব্যবহারিক উপায় হলো:
- একজন ব্যবহারকারী একটি অ্যাপ্লিকেশন ওপেন করেন।
- অ্যাপ্লিকেশনটি যাচাই করে যে কোনো বিশ্বস্ত IdP ইতিমধ্যে সেই ব্যবহারকারীকে প্রমাণীকরণ করেছে কিনা।
- যদি কোনো সক্রিয় সেশন না থাকে, ব্যবহারকারী IdP-এর মাধ্যমে সাইন ইন করেন।
- IdP আইডেন্টিটি নিশ্চিত করে এবং এমন প্রমাণ ফেরত পাঠায় যা অ্যাপ্লিকেশনটি যাচাই করতে পারে।
- অন্যান্য সংযুক্ত সিস্টেমগুলি সেশন চলাকালীন সেই একই প্রমাণ গ্রহণ করতে পারে।
ব্যবহারিক নিয়ম: SSO প্রতিটি সিস্টেমকে একটি প্ল্যাটফর্মে রূপান্তর করে না। এটি একাধিক সিস্টেমকে পরিচয় যাচাই করার জন্য একটি নির্দিষ্ট স্থান প্রদান করে।
ওয়েব অ্যাপের বাইরে এটি কেন গুরুত্বপূর্ণ
এখানেই SSO শুধুমাত্র একটি SaaS সুবিধা হিসেবে সীমাবদ্ধ না থেকে আরও কার্যকারী হয়ে ওঠে। পরিচয় একবার কেন্দ্রীভূত হয়ে গেলে, ব্রাউজার সেশনের চেয়েও বেশি কাজের জন্য একই মডেল ব্যবহার করা যেতে পারে। এটি আপনি কীভাবে অভ্যন্তরীণ পরিষেবাগুলিতে অ্যাক্সেস নিয়ন্ত্রণ করেন এবং সঠিক ডিজাইনে, ব্যবহারকারীরা কীভাবে কর্পোরেট ওয়্যারলেস নেটওয়ার্কে যুক্ত হন তা নির্ধারণ করতে পারে।
এটি আইটি অপারেশনের জন্য অত্যন্ত গুরুত্বপূর্ণ। একটি ফাইন্যান্স অ্যাপ, একটি VPN সেশন এবং একটি কর্মচারী WiFi সংযোগ ভিন্ন পরিষেবা হতে পারে, তবে তারা সবাই একই প্রশ্ন দিয়ে শুরু করে: এই ব্যবহারকারী কে, এবং তাদের কি প্রবেশাধিকার দেওয়া উচিত? যখন Microsoft Entra ID বা Okta এই প্রশ্নের ধারাবাহিক উত্তর দেয়, তখন অ্যাপ্লিকেশন এবং নেটওয়ার্ক এন্ট্রি পয়েন্ট উভয় জুড়েই অ্যাক্সেস পলিসি পরিচালনা করা সহজ হয়ে যায়।
যেসব দল এখনও শেয়ার করা পাসওয়ার্ড দিয়ে কর্মীদের WiFi চালাচ্ছেন, তাদের জন্য এটি একটি বড় পরিবর্তন। সবার জানা একটি পাসওয়ার্ড দিয়ে ডিভাইস প্রমাণীকরণ করার পরিবর্তে, আপনি একটি বিশ্বস্ত আইডেন্টিটি উৎসের বিপরীতে একজন ব্যক্তি বা একটি পরিচালিত ডিভাইস প্রমাণীকরণ করেন। এটি আপনাকে আরও কঠোর নিয়ন্ত্রণ, স্পষ্ট অডিট ট্রেইল এবং ভূমিকা পরিবর্তন বা চাকরি শেষ হলে অ্যাক্সেস সরিয়ে নেওয়ার একটি আরও পরিষ্কার উপায় দেয়।
SSO যেভাবে কাজ করে - মূল প্রোটোকলসমূহ
ব্যবহারকারীর অভিজ্ঞতা সহজ মনে হয়। এর অভ্যন্তরে, SSO স্ট্যান্ডার্ড প্রোটোকলের ওপর নির্ভর করে যা কোনো অ্যাপ্লিকেশনকে অন্য কোথাও নেওয়া আইডেন্টিটি ডিসিশনকে বিশ্বাস করতে সাহায্য করে।
একজন এন্টারপ্রাইজ IT ম্যানেজারের জন্য, ব্যবহারিক প্রশ্নটি কেবল "SSO কী?" তা নয়। এটি হলো "ব্যবহারকারীকে পুনরায় লগ ইন করতে না বলে কীভাবে একটি সিস্টেম অন্য সিস্টেম থেকে প্রমাণ গ্রহণ করে?" এর উত্তরটি প্রোটোকলের একটি ছোট সেটের উপর নির্ভর করে যা অ্যাপ্লিকেশন, আইডেন্টিটি প্রোভাইডার এবং কখনও কখনও ডিভাইসের নিজের মধ্যে আইডেন্টিটি ডেটা স্থানান্তর করে।
এটি ব্রাউজার লগইনের বাইরেও গুরুত্বপূর্ণ। SaaS অ্যাপ খোলার জন্য ব্যবহৃত একই ট্রাস্ট মডেল ব্যবহারকারীরা কীভাবে VPN, তারযুক্ত নেটওয়ার্ক এবং কর্পোরেট WiFi-এ সংযোগ করবে তা নির্ধারণ করতে পারে, যখন সেই অ্যাক্সেসের সিদ্ধান্তগুলি Microsoft Entra ID, Okta বা অন্য কোনো কেন্দ্রীয় পরিচয় উৎসের সাথে সংযুক্ত থাকে।
সহজ ভাষায় SAML
এন্টারপ্রাইজ SSO-তে SAML 2.0 এখনও অত্যন্ত সাধারণ, বিশেষ করে প্রতিষ্ঠিত SaaS প্ল্যাটফর্ম এবং লাইন-অফ-বিজনেস সিস্টেমগুলোর জন্য।
SAML অ্যাপ্লিকেশন এবং আইডেন্টিটি প্রোভাইডারের মধ্যে বিশ্বস্ত আইডেন্টিটি স্টেটমেন্ট পাস করার মাধ্যমে কাজ করে। একজন ব্যবহারকারী একটি অ্যাপ্লিকেশন খোলার চেষ্টা করেন। অ্যাপ্লিকেশনটি তাদের IdP-তে রিডাইরেক্ট করে। IdP ব্যবহারকারীকে প্রমাণীকরণ করে একটি ডিজিটালি সাইনড অ্যাসারশন ফেরত পাঠায়। অ্যাপ্লিকেশনটি সেই স্বাক্ষরটি পরীক্ষা করে, আইডেন্টিটি দাবিটি গ্রহণ করে এবং একটি সেশন তৈরি করে।
যেসব পরিবেশে ব্রাউজার অধিকাংশ কাজ পরিচালনা করে এবং অ্যাপ্লিকেশন একটি আনুষ্ঠানিক, স্ট্যান্ডার্ড-ভিত্তিক ডেটা এক্সচেঞ্জ আশা করে, সেখানে এই ফ্লো চমৎকার কাজ করে।
SAML সাধারণত নিচের ক্ষেত্রগুলোর জন্য বেশ উপযুক্ত:
- এইচআর, ফাইন্যান্স বা লেগ্যাসি বিজনেস অ্যাপ্লিকেশনের মতো এন্টারপ্রাইজ SaaS
- ব্রাউজার-ভিত্তিক ওয়ার্কফ্লো যেখানে ব্যবহারকারীরা একটি ওয়েব সেশনের মাধ্যমে সিস্টেম অ্যাক্সেস করেন
- কেন্দ্রীয় পলিসি প্রয়োগ যখন আইটি টিম অথেন্টিকেশন পরিচালনার জন্য একটি একক জায়গা চায়
সহজ ভাষায় OAuth এবং OIDC
OAuth 2.0 মূলত কোনো ক্রেডেনশিয়াল শেয়ার না করে একটি রিসোর্সে সীমিত অ্যাক্সেস মঞ্জুর করার উপায় হিসেবে শুরু হয়েছিল। এটি মূলত অথরাইজেশন বা অনুমোদনের কাজ করে।
OpenID Connect বা OIDC, OAuth 2.0-এর উপরে আইডেন্টিটি যোগ করে। এটি আধুনিক অ্যাপ্লিকেশনগুলোকে টোকেন-ভিত্তিক অ্যাক্সেস প্যাটার্ন ব্যবহার করার সাথে সাথে ব্যবহারকারী কে তা নিশ্চিত করার একটি আদর্শ উপায় প্রদান করে। SAML যদি প্রায়শই পুরানো ব্রাউজার-কেন্দ্রিক SaaS-এর জন্য উপযুক্ত হয়, তবে OIDC সাধারণত নতুন ওয়েব অ্যাপ, মোবাইল অ্যাপ এবং API-চালিত পরিষেবাগুলোর জন্য উপযুক্ত।
বাস্তবে, আধুনিক ডেভেলপমেন্ট টিমের কাছে OIDC-কে অনেক সহজ মনে হয় কারণ টোকেনগুলি ফ্রন্ট-এন্ড অ্যাপ, ব্যাক-এন্ড সার্ভিস এবং মোবাইল ক্লায়েন্ট জুড়ে ভালোভাবে কাজ করে। আইটির জন্য এর অর্থ হলো, অ্যাপ্লিকেশনটি যখন ঐতিহ্যগত ব্রাউজার সেশন না হয় তখন কম জটিল সমাধানের প্রয়োজন হয়।
OIDC সাধারণত নিচের ক্ষেত্রগুলোর জন্য উপযুক্ত:
- আধুনিক ক্লাউড অ্যাপ্লিকেশনসমূহ
- মোবাইল এবং সিঙ্গেল-পেজ অ্যাপস
- API-নির্ভর পরিবেশ যেখানে টোকেন ইতিমধ্যেই ডিজাইনের অংশ
Kerberos সম্পর্কে একটি সংক্ষিপ্ত তথ্য
SSO সংক্রান্ত আলোচনায় আপনি Kerberos-এর নামও শুনতে পারেন। Kerberos মূলত প্রথাগত Active Directory পরিবেশ এবং অন-প্রেমিস Windows অথেন্টিকেশনের সাথে ঘনিষ্ঠভাবে যুক্ত। এটি অভ্যন্তরীণ এন্টারপ্রাইজ এস্টেটে এখনও প্রাসঙ্গিক, বিশেষ করে যেখানে ডোমেন-যুক্ত ডিভাইস এবং লেগ্যাসি অ্যাপ্লিকেশন এখনও সাধারণ।
তা সত্ত্বেও, বর্তমানের অনেক SSO প্রকল্প ক্লাউড এবং হাইব্রিড পরিষেবা জুড়ে ফেডারেটেড আইডেন্টিটির উপর ফোকাস করে। সেই ক্ষেত্রে, SAML এবং OIDC সাধারণত বেশি মনোযোগ পায় কারণ এগুলি SaaS প্ল্যাটফর্ম এবং বাহ্যিকভাবে অ্যাক্সেসযোগ্য পরিষেবাগুলির সাথে আরও স্বাভাবিকভাবে সংযোগ স্থাপন করে।
এক নজরে SAML বনাম OIDC
| ফিচার | SAML 2.0 | OAuth 2.0 / OIDC |
|---|---|---|
| প্রধান ভূমিকা | এন্টারপ্রাইজ ওয়েব অ্যাপ্লিকেশনের জন্য প্রমাণীকরণ | OIDC এর মাধ্যমে পরিচয় যুক্ত করে অনুমোদন |
| সাধারণ ব্যবহারের ক্ষেত্র | প্রতিষ্ঠিত SaaS এবং ব্রাউজার-ভিত্তিক এন্টারপ্রাইজ অ্যাপস | আধুনিক ওয়েব অ্যাপস, মোবাইল অ্যাপস, এবং API |
| ফরম্যাট | XML-ভিত্তিক অ্যাসারশন | টোকেন-ভিত্তিক ফ্লো |
| স্বাভাবিক ফ্লো | IdP-তে রিডাইরেক্ট, প্রমাণীকরণ, এবং স্বাক্ষরিত অ্যাসারশন রিটার্ন করা | রিডাইরেক্ট বা টোকেন ফ্লো, তারপর পরিচয় ও অ্যাক্সেসের জন্য অ্যাপ টোকেন ব্যবহার করে |
| সবচেয়ে উপযুক্ত | ঐতিহ্যবাহী এন্টারপ্রাইজ SSO ইন্টিগ্রেশন | নতুন ক্লাউড-নেটিভ এবং অ্যাপ-কেন্দ্রিক আর্কিটেকচার |
একজন IT ম্যানেজারের জন্য যা গুরুত্বপূর্ণ
ডিজাইন পছন্দের তুলনায় প্রোটোকলের নামগুলো কম গুরুত্বপূর্ণ। চারটি অপারেশনাল প্রশ্নের স্পষ্ট উত্তর আপনার প্রয়োজন:
- কোন অ্যাপগুলো SAML বা OIDC সমর্থন করে
- কোন IdP আপনার সেন্ট্রাল কন্ট্রোল প্লেন হিসেবে কাজ করবে
- কীভাবে সেশন টাইমআউট, MFA এবং শর্তসাপেক্ষ অ্যাক্সেস কার্যকর করা হবে
- একই উৎসের বিপরীতে নেটওয়ার্ক অ্যাক্সেস - যার মধ্যে কর্মীদের WiFi-ও রয়েছে - তা পরিচয় যাচাই করবে কিনা
এই শেষ পয়েন্টটিই হলো যেখানে পরিকাঠামো দলগুলির জন্য SSO বিশেষভাবে দরকারী হয়ে ওঠে। যদি আপনার ওয়্যারলেস প্ল্যাটফর্মটি আপনার SaaS এস্টেটের মতো একই আইডেন্টিটি লেয়ার ব্যবহার করতে পারে, তবে লগইন পেজ থেকে শুরু করে নেটওয়ার্কের প্রান্ত পর্যন্ত অ্যাক্সেস পলিসি আরও সামঞ্জস্যপূর্ণ হয়ে ওঠে। এটি একটি কারণ যার জন্য অনেক দল যারা অ্যাক্সেস কন্ট্রোল এবং অপারেশনগুলির জন্য single sign-on এর সুবিধাগুলি পর্যালোচনা করছে, তারা কেবল ওয়েব অ্যাপ লগইন নয়, বরং আইডেন্টিটি-ব্যাকড WiFi অথেন্টিকেশনের দিকেও তাকাতে শুরু করেছে।
সুবিধা এবং সিকিউরিটির আপসসমূহ মূল্যায়ন করা
SSO-কে প্রায়শই ব্যবহারকারীর সুবিধাজনক ফিচার হিসেবে উপস্থাপন করা হয়। এটি এর প্রকৃত গুরুত্বকে কমিয়ে দেখায়। সঠিকভাবে সম্পন্ন করা হলে, এটি এমন একটি অ্যাক্সেস কন্ট্রোল মডেল যা একই সাথে ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে এবং অপারেশনাল সিকিউরিটি আরও জোরদার করতে পারে।
Okta উল্লেখ করেছে যে SSO-এর প্রযুক্তিগত সুবিধা কেবল সুবিধাই নয়। এটি পাসওয়ার্ডের বিস্তৃতি এবং বারবার লগইন করার ঘটনাগুলি হ্রাস করে যা হেল্প-ডেস্কের কাজের চাপ এবং ব্যবহারকারীর ঝামেলা বাড়ায়। Okta-এর single sign-on security-এর ওভারভিউ এমন একটি পয়েন্টকেও হাইলাইট করে যা আর্কিটেক্টরা গুরুত্ব দেন: যদি IdP সেশনটি বাতিল হয়ে যায়, তবে সংযুক্ত অ্যাপ্লিকেশনগুলি পরবর্তী টোকেন চেক করার সময় অ্যাক্সেস অস্বীকার করতে পারে।
ব্যবসায়িক মূল্য যেখানে প্রকাশ পায়
প্রথম সুবিধাটি হলো সহজতর অ্যাক্সেস। ব্যবহারকারীরা একবার লগ ইন করেন, দ্রুত কাজ শুরু করতে পারেন এবং অথেনটিকেশনকে দৈনিক বাধা হিসেবে বিবেচনা করা বন্ধ করেন।
দ্বিতীয়টি হলো আরও শক্তিশালী কেন্দ্রীয় নিয়ন্ত্রণ। প্রতিটি অ্যাপ্লিকেশনের ভেতরে সেটিংস খোঁজার পরিবর্তে IT বিভাগ একটি সিঙ্গেল আইডেন্টিটি লেয়ার থেকে MFA, কন্ডিশনাল অ্যাক্সেস, সেশন পলিসি এবং রিভোকেশন প্রয়োগ করতে পারে।
তৃতীয় সুবিধাটি হলো জয়নার, মুভার এবং লিভারদের আরও সহজভাবে পরিচালনা করা। যখন আইডেন্টিটি সেন্ট্রাল বা কেন্দ্রীয়ভাবে থাকে, তখন অনবোর্ডিং এবং অফবোর্ডিং আরও সুসংগত হয়ে ওঠে। এটিই অন্যতম কারণ যে টিমগুলো single sign-on benefits বা একক সাইন-অন সুবিধাগুলো অন্বেষণ করছে, তারা প্রায়শই SSO প্রজেক্টগুলোকে বৃহত্তর আইডেন্টিটি গভর্নেন্সের কাজের সাথে সংযুক্ত করে।
যেসব ট্রেড-অফ আপনার গুরুত্ব সহকারে বিবেচনা করা উচিত
এখানে একটি বাস্তব "মূল চাবিকাঠি" সংক্রান্ত উদ্বেগ রয়েছে। যদি কোনো আক্রমণকারী ব্যবহারকারীর প্রাথমিক সাইন-ইন নিয়ন্ত্রণে নিয়ে নেয়, তবে ক্ষতির পরিধি আরও বড় হতে পারে কারণ একটিমাত্র অ্যাকাউন্ট অনেকগুলো সিস্টেমে অ্যাক্সেস দিতে পারে।
সহনশীলতার ঝুঁকিও রয়েছে। IdP অনুপলব্ধ হলে, সংযুক্ত পরিষেবাগুলিতে অ্যাক্সেস বাধাগ্রস্ত হতে পারে। এবং ইন্টিগ্রেশন সবসময় মসৃণ হয় না। পুরানো অ্যাপ, নির্দিষ্ট ক্ষেত্রের সিস্টেম এবং স্থানীয় নেটওয়ার্ক পরিষেবাগুলি সবসময় একটি আধুনিক SSO মডেলের সাথে খাপ খায় না।
সঠিক প্রশ্নটি এটি নয় যে SSO-এর কোনো আপস বা সমঝোতা আছে কিনা। বরং এটি যে, আপনি কি সেই আপসগুলো কেন্দ্রীয়ভাবে পরিচালনা করতে চান নাকি ডজন ডজন সংযোগহীন আপস পরিচালনা করতে চান।
সাধারণ সমাধানসমূহ
একটি বহুমুখী স্তরযুক্ত পদ্ধতি ব্যবহার করুন:
- IdP-কে ব্যাপকভাবে সুরক্ষিত রাখুন MFA, কন্ডিশনাল অ্যাক্সেস, ডিভাইস ট্রাস্ট এবং শক্তিশালী অ্যাডমিন কন্ট্রোলের মাধ্যমে।
- স্থিতিস্থাপকতার পরিকল্পনা করুন যাতে কোনো IdP সমস্যা পুরো সংস্থাকে স্থবির করে না দেয়।
- ধাপে ধাপে চালু করুন উচ্চ-মূল্যের অ্যাপ এবং স্পষ্ট ব্যবহারকারী গ্রুপ দিয়ে শুরু করে।
- নিয়মিত অ্যাক্সেস পর্যালোচনা করুন যাতে অপ্রয়োজনীয় এনটাইটেলমেন্টগুলি দীর্ঘ সময় ধরে টিকে না থাকে।
একটি দুর্বল SSO রোলআউট সমস্যাগুলোকে একীভূত করতে পারে। কিন্তু একটি শক্তিশালী SSO রোলআউট নিয়ন্ত্রণকে কেন্দ্রীভূত করে।
ওয়েব অ্যাপের বাইরে SSO: নেটওয়ার্ক এবং WiFi অ্যাক্সেস
অধিকাংশ নিবন্ধ SaaS-এই শেষ হয়ে যায়। এটি দরকারী, কিন্তু অপূর্ণাঙ্গ। বাস্তব পরিবেশে, কর্মীদের কেবল অ্যাপ অ্যাক্সেসের প্রয়োজন হয় না। সাইটে পৌঁছানোর পর, একটি পরিচালিত ল্যাপটপ সংযোগ করার সময়, কোনো শাখায় ট্যাবলেট খোলার সময় অথবা বিভিন্ন প্রপার্টির মধ্যে রোমিং করার সময় তাদের নিরাপদ নেটওয়ার্ক অ্যাক্সেসের প্রয়োজন হয়।
সেখানেই SSO আলোচনাটি আরও আকর্ষণীয় হয়ে ওঠে। Microsoft 365, HR সিস্টেম বা অভ্যন্তরীণ ড্যাশবোর্ডে অ্যাক্সেস পরিচালনা করা একই আইডেন্টিটি প্রোভাইডার ওয়্যারলেস অথেন্টিকেশন পলিসির জন্য সোর্স অফ ট্রুথ হতে পারে।
Optimal IdM তাদের single sign-on adoption-এর আলোচনায় রিপোর্ট করেছে যে, উত্তর আমেরিকার ৫২% IT পেশাদার আইডেন্টিটি পরিচালনার জন্য SSO ব্যবহার করেন। একাধিক ভেন্যু বা প্রপার্টি রয়েছে এমন UK-এর প্রতিষ্ঠানগুলির জন্য এই পরিপক্কতা অত্যন্ত গুরুত্বপূর্ণ কারণ কর্মীদের প্রায়ই বারবার লগইন না করেই শেয়ার করা সিস্টেমে নিরাপদ অ্যাক্সেসের প্রয়োজন হয়।
অ্যাপ SSO এবং নেটওয়ার্ক আইডেন্টিটি পরস্পর সম্পর্কিত, কিন্তু অভিন্ন নয়
পাঠকদের জন্য বিভ্রান্তির একটি সাধারণ বিষয় হলো যে অ্যাপ্লিকেশনের জন্য SSO এবং আইডেন্টিটি-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস একে অপরের সাথে যুক্ত ধারণা, তবে এগুলো একই মেকানিজম নয়।
অ্যাপ SSO বলতে সাধারণত বোঝায় ব্যবহারকারী একবার IdP-এর মাধ্যমে অথেন্টিকেট করেন এবং একটি টোকেন বা সেশন লাভ করেন যা সংযুক্ত অ্যাপ্লিকেশনগুলি দ্বারা গৃহীত হয়। নেটওয়ার্ক অ্যাক্সেস প্রায়শই বিভিন্ন নিয়ন্ত্রণ ব্যবহার করে, যেমন ডিভাইস সার্টিফিকেট, ওয়্যারলেস অথেন্টিকেশন পদ্ধতি, ডিরেক্টরি-ব্যাকড পলিসি এবং পশ্চার বা ট্রাস্ট যাচাইকরণ।
যা তাদের সংযুক্ত করে তা হলো পরিচয় উৎস। যদি Microsoft Entra ID বা Okta ইতিমধ্যে জানে ব্যবহারকারী কে, তারা কোন গ্রুপের অন্তর্ভুক্ত এবং তাদের ডিভাইসটি পরিচালিত কিনা, তবে তারা কর্মী নেটওয়ার্কে যোগ দিতে পারবে কিনা তা নির্ধারণ করতে আপনি সেই পরিচয় প্রসঙ্গ ব্যবহার করতে পারেন।
কর্পোরেট WiFi-তে এটি দেখতে কেমন লাগে
একটি পরিপক্ক ডিজাইনে, কর্মীদের কোনো শেয়ার্ড WiFi পাসওয়ার্ড টাইপ করার প্রয়োজন হয় না। তাদের প্রতিষ্ঠান-পরিচালিত ডিভাইসটি নথিভুক্ত, বিশ্বস্ত এবং তাদের পরিচয়ের সাথে যুক্ত থাকে। তারা যখন বিল্ডিংয়ে প্রবেশ করে, তখন ডিভাইসটি সার্টিফিকেট-ভিত্তিক বা সমতুল্য এন্টারপ্রাইজ অথেন্টিকেশন ব্যবহার করে উপযুক্ত সুরক্ষিত SSID-এর সাথে সংযুক্ত হয়।
এটি কার্যক্রমগতভাবে অনেক কিছু পরিবর্তন করে দেয়:
- শেয়ার করা পাসওয়ার্ডগুলি দূর হয়ে যায়, তাই একটি মাত্র ক্রেডেনশিয়াল ফাঁস হলে তা পুরো কর্মক্ষেত্রের নেটওয়ার্ককে প্রভাবিত করে না।
- অ্যাক্সেস রোল-অ্যাওয়ার হয়ে ওঠে, কারণ পলিসি আইডেন্টিটি গ্রুপগুলিকে অনুসরণ করতে পারে।
- বাতিলকরণ দ্রুততর হয়, কারণ যখন ডিরেক্টরি অ্যাক্সেস পরিবর্তিত হয়, তখন নেটওয়ার্ক অ্যাক্সেসও এর সাথে পরিবর্তিত হতে পারে।
- রোমিং আরও সহজ হয়ে যায়, বিশেষ করে মাল্টি-সাইট এস্টেটগুলিতে যেখানে ব্যবহারকারীরা সর্বত্র একই অভিজ্ঞতা আশা করেন।
হসপিটালিটি, রিটেইল এবং হেলথকেয়ার সেক্টরে এটি কেন গুরুত্বপূর্ণ
এই সেক্টরগুলো ব্যতিক্রমী পরিস্থিতিতে পূর্ণ। এখানে শিফট কর্মী, শেয়ার করা ডিভাইস, এজেন্সি স্টাফ, রোমিং টিম এবং কর্পোরেট, সেমি-কর্পোরেট ও গেস্ট অ্যাক্সেসের চাহিদার একটি ধারাবাহিক মিশ্রণ রয়েছে।
একটি হোটেল গ্রুপ চাইতে পারে যে সমস্ত সম্পত্তিতে PMS অ্যাক্সেস, ব্যাক-অফিস অ্যাপস এবং সুরক্ষিত অভ্যন্তরীণ WiFi পরিচালনা করার জন্য কর্মীদের একটি একক পরিচয় থাকুক। একটি রিটেল চেইন চাইতে পারে যাতে তাদের পরিচালিত হ্যান্ডহেল্ড ডিভাইসগুলো স্বয়ংক্রিয়ভাবে স্টোরের WiFi-এর সাথে সংযুক্ত হয় এবং গেস্ট ট্রাফিক সম্পূর্ণ আলাদা থাকে। একটি স্বাস্থ্যসেবা প্রদানকারী প্রতিষ্ঠান ক্লিনিকাল ব্যবহারকারী, ভিজিটর এবং সংযুক্ত ডিভাইসগুলির মধ্যে আরও শক্তিশালী বিভাজন চাইতে পারে।
এখানেই network access control solutions আলোচনার অংশ হয়ে ওঠে। এগুলো অ্যাপ্লিকেশন লেয়ার থেকে নেটওয়ার্ক লেয়ারে আইডেন্টিটি পলিসি প্রসারিত করতে সহায়তা করে।
যেখানে Purple খাপ খায়
একটি ব্যবহারিক বিকল্প হলো Purple, যা কর্মীদের এবং মাল্টি-টেন্যান্ট পরিবেশের জন্য আইডেন্টিটি-ভিত্তিক নেটওয়ার্কিং সমর্থন করে, যার মধ্যে শেয়ার করা পাসওয়ার্ডের উপর নির্ভর না করে নিরাপদ অ্যাক্সেসের জন্য Entra ID, Google Workspace এবং Okta-এর সাথে ইন্টিগ্রেশন অন্তর্ভুক্ত রয়েছে। এই ধরণের পদ্ধতি তখন দরকারী যখন আপনি চান অ্যাপের আইডেন্টিটি এবং নেটওয়ার্ক আইডেন্টিটি একই তথ্যের উৎস থেকে কাজ করুক।
আপনার শিল্পে SSO এর ব্যবহারিক ক্ষেত্র
SSO-এর গুরুত্ব বোঝার সবচেয়ে সহজ উপায় হলো আর্কিটেকচার ডায়াগ্রামের দিকে না তাকিয়ে দৈনিক কাজের দিকে নজর দেওয়া।
আতিথেয়তা শিল্প
একজন হোটেল অপারেশনস ম্যানেজার দিনের শুরু করেন একটি প্রোপার্টিতে এবং শেষ করেন অন্যটিতে। উভয় লোকেশনেই তাদের শিডিউলিং, একটি প্রোপার্টি ম্যানেজমেন্ট সিস্টেম, শেয়ার করা ডকুমেন্টস এবং অভ্যন্তরীণ WiFi-তে অ্যাক্সেসের প্রয়োজন হয়।
SSO-এর মাধ্যমে, সেই পরিচয় তাদের অনুসরণ করে। তারা একবার সাইন ইন করে এবং অনুমোদিত সিস্টেমগুলি সেই সেশনটি সনাক্ত করে। যদি প্রতিষ্ঠানটি নেটওয়ার্ক অ্যাক্সেসকেও একই পরিচয় উৎসের সাথে যুক্ত করে, তবে তাদের পরিচালিত ডিভাইসটি ডিউটি ম্যানেজারকে সর্বশেষ পাসওয়ার্ড টেক্সট না করেই কর্মীদের WiFi-এ যুক্ত হতে পারে।
খুচরা ব্যবসা
একজন রিজিওনাল ম্যানেজার হাতে একটি ট্যাবলেট নিয়ে একটি স্টোরে প্রবেশ করলেন। সরাসরি তাদের সেলস ড্যাশবোর্ড, স্টক টুল এবং ইন্টারনাল কমিউনিকেশন অ্যাপ্লিকেশনের অ্যাক্সেস প্রয়োজন।
একটি খণ্ডিত সেটআপে, প্রতিটি ধাপে আরেকটি লগইন প্রম্পট, আরেকটি মেয়াদোত্তীর্ণ পাসওয়ার্ড বা সহায়তার জন্য আরেকটি কল করার প্রয়োজন হতে পারে। একটি পরিচয়-চালিত মডেলে, ট্যাবলেটটি নির্বিঘ্নে অথেন্টিকেট করে, অ্যাক্সেস ব্যবহারকারীর ভূমিকা প্রতিফলিত করে এবং স্টোরের কর্মীদের কাজ করার জন্য স্থানীয় ক্রেডেনশিয়াল শেয়ার করতে হয় না।
ভালো SSO অ্যাক্সেসকে অদৃশ্য করে না। এটি বৈধ অ্যাক্সেসকে অনুমানযোগ্য করে তোলে।
স্বাস্থ্যসেবা
একজন ক্লিনিশিয়ান শিফট শুরু করেন এবং কোর সিস্টেমে দ্রুত ও নিয়ন্ত্রিত অ্যাক্সেসের প্রয়োজন হয়। তারা সারাদিনে একাধিক ওয়ার্কস্টেশন, শেয়ার্ড ডিভাইস এবং রেস্ট্রিক্টেড নেটওয়ার্ক সেগমেন্টের মধ্যে যাতায়াত করতে পারেন।
এখানে, SSO অনুমোদিত অ্যাপ্লিকেশনগুলিতে বারবার সাইন-ইন করার ঝামেলা কমাতে সাহায্য করে, অন্যদিকে পরিচয়-ভিত্তিক নেটওয়ার্ক নিয়ন্ত্রণগুলি সঠিক ব্যবহারকারী এবং ডিভাইসগুলি যাতে সঠিক ওয়্যারলেস পরিবেশের সাথে সংযুক্ত হয় তা নিশ্চিত করতে সহায়তা করে। এই বিভাজনটি গুরুত্বপূর্ণ। ক্লিনিকাল অ্যাক্সেস, গেস্ট অ্যাক্সেস এবং ডিভাইস অ্যাক্সেস সব একই উপায়ে পরিচালিত হওয়া উচিত নয়।
মাল্টি-টেন্যান্ট প্রোপার্টি এবং ক্যাম্পাস
শিক্ষার্থীদের আবাসন, বিজনেস সেন্টার এবং বহুমুখী ব্যবহারের সম্পত্তিতে, স্টাফ এবং বাসিন্দারা প্রায়শই একই ফিজিক্যাল ইনফ্রাস্ট্রাকচার ব্যবহার করেন কিন্তু তাদের কখনই একই অ্যাক্সেস মডেল শেয়ার করা উচিত নয়।
কর্মীদের বিল্ডিং সিস্টেম, সাপোর্ট টুল এবং অভ্যন্তরীণ অ্যাডমিন অ্যাপের প্রয়োজন হতে পারে। বাসিন্দা বা ভাড়াটেদের নির্ভরযোগ্য সংযোগের প্রয়োজন, কিন্তু অপারেশনাল প্ল্যাটফর্মে অ্যাক্সেসের প্রয়োজন নেই। এই প্রেক্ষাপটে, আইডেন্টিটি ডিজাইন সবচেয়ে বেশি গুরুত্বপূর্ণ। SSO কর্মীদের অ্যাক্সেস সমর্থন করতে পারে, যেখানে পৃথক নেটওয়ার্ক আইডেন্টিটি পলিসি ভাড়াটে এবং গেস্ট ট্রাফিককে আলাদা রাখে।
SSO বাস্তবায়ন এবং সর্বোত্তম অনুশীলনসমূহ
একটি সফল SSO প্রকল্পের শুরু হয় একটি সিদ্ধান্তের মাধ্যমে: আপনার কন্ট্রোল প্লেন হিসেবে কাজ করবে এমন আইডেন্টিটি প্রোভাইডার নির্বাচন করা। অনেক প্রতিষ্ঠানের জন্য এটি হলো Microsoft Entra ID বা Okta, কারণ এই প্ল্যাটফর্মগুলি ইতিমধ্যেই ব্যবহারকারীর লাইফসাইকেল, MFA এবং ডিভাইস পলিসির কাছাকাছি অবস্থান করে।
রোলআউট ধাপে ধাপে হওয়া উচিত। সবচেয়ে গুরুত্বপূর্ণ অ্যাপ্লিকেশন এবং সবচেয়ে বেশি উপকৃত হতে পারে এমন ব্যবহারকারী গ্রুপ দিয়ে শুরু করুন। ডুপ্লিকেট অ্যাকাউন্টগুলো পরিষ্কার করুন, রোল গ্রুপগুলো সঠিকভাবে সংজ্ঞায়িত করুন এবং পরিধি বাড়ানোর আগে সেশন আচরণ পরীক্ষা করুন।
যে নিয়ন্ত্রণগুলো সবচেয়ে বেশি গুরুত্বপূর্ণ
একটি সাধারণ ডেমো এবং একটি টেকসই ডেপ্লয়মেন্টের মধ্যে পার্থক্য গড়ে দেয় কয়েকটি সাধারণ অনুশীলন:
- প্রাথমিক সাইন-ইন পয়েন্টে MFA আবশ্যক করুন। যদি একটি লগইন অনেক রিসোর্সে অ্যাক্সেস দিতে পারে, তবে সেই লগইনের জন্য আরও শক্তিশালী সুরক্ষা প্রয়োজন।
- তাত্ক্ষণিক বাতিলের প্রক্রিয়া তৈরি করুন। সেন্ট্রাল আইডেন্টিটি তখনই সাহায্য করে যখন অ্যাকাউন্টের পরিবর্তনগুলো দ্রুত কার্যকর হয়।
- ভূমিকা অনুযায়ী অ্যাক্সেস পর্যালোচনা করুন। কার কার এখনও অ্যাক্সেস রয়েছে তা কেউ পরীক্ষা না করলে SSO-এর কারণে অতিরিক্ত সুবিধা পাওয়ার বিষয়টি সহজে চোখ এড়িয়ে যেতে পারে।
- IdP বিঘ্নের জন্য পরিকল্পনা রাখুন। আপনার পরিচয় পরিষেবাটি অনুপলব্ধ থাকলে কী ঘটবে এবং কোন সিস্টেমগুলোর ব্যাকআপ হ্যান্ডলিং প্রয়োজন তা জেনে রাখুন।
SSO কখন সঠিক সরঞ্জাম নয় তা জানুন
এই পয়েন্টটি অনেক সাধারণ ব্যাখ্যায় বাদ পড়ে যায়। OneLogin বাস্তব-ক্ষেত্রের ডেপ্লয়মেন্টে কর্মীদের SSO এবং গেস্ট বা ডিভাইস অ্যাক্সেসের মধ্যে একটি ক্রমবর্ধমান পার্থক্য লক্ষ্য করে এবং how single sign-on works-এর ব্যাখ্যায় একটি দরকারী ক্রেতার প্রশ্ন জিজ্ঞাসা করে: কখন SSO ভুল টুল এবং কখন অ্যাপ লগইনের পরিবর্তে নেটওয়ার্ক অ্যাক্সেসে আইডেন্টিটি প্রয়োগ করা উচিত?
এটি WiFi ডিজাইনের ক্ষেত্রে গুরুত্বপূর্ণ। কর্মীদের প্রায়শই পরিচয়-সংযুক্ত, নীতি-চালিত অ্যাক্সেস ব্যবহার করা উচিত। অতিথিদের সাধারণত আরও হালকা, সহজ এবং পৃথক কিছুর প্রয়োজন হয়। কর্মীদের SSO-এর মাধ্যমে প্রতিটি অ্যাক্সেসের সমস্যা সমাধানের চেষ্টা করলে অপ্রয়োজনীয় জটিলতার সৃষ্টি হয়।
আপনি যদি আরও বড় অ্যাক্সেস কৌশলের অংশ হিসাবে SSO পর্যালোচনা করেন, তবে একই আলোচনায় অ্যাপস, স্টাফ WiFi, গেস্ট অনবোর্ডিং, শেয়ার করা ডিভাইস এবং রিভোকেশন ওয়ার্কফ্লো অন্তর্ভুক্ত করুন। সাধারণত সেখানেই সবচেয়ে বড় অপারেশনাল সুবিধা দেখা যায়।
আপনি যদি অ্যাপস, কর্মীদের WiFi, গেস্ট অনবোর্ডিং, বা মাল্টি-টেন্যান্ট নেটওয়ার্ক জুড়ে অ্যাক্সেস পুনর্বিবেচনা করেন, তবে Purple দেখতে পারেন। এটি আইডেন্টিটি-ভিত্তিক নেটওয়ার্কিং প্রদান করে যা Entra ID, Okta এবং Google Workspace-এর মতো প্ল্যাটফর্মগুলির সাথে কাজ করতে পারে, যা কর্মীদের, অতিথিদের এবং বাসিন্দাদের নিয়ন্ত্রিত অ্যাক্সেস দেওয়ার জন্য টিমগুলোকে শেয়ার করা পাসওয়ার্ড এবং জটিল Captive Portal পরিবর্তন করতে সহায়তা করে।
