Self-hosted সফটওয়্যারে SSO tax কেন নেওয়া হয়?

SSO tax কী

self-hosted সফটওয়্যারের ক্ষেত্রে SSO tax হলো এমন একটি ধারা যেখানে অ্যাপ্লিকেশনটি বিনামূল্যে ব্যবহার করা গেলেও single sign-on (SSO) ফিচারটি ব্যবহারের জন্য অর্থ প্রদান করতে হয়। আপনি কোনো লাইসেন্স কি (licence key) বা নির্দিষ্ট ব্যবহারকারীর সংখ্যা (seat count) ছাড়াই আপনার নিজস্ব VPS-এ পুরো অ্যাপ্লিকেশনটি চালাতে পারেন। কিন্তু এরপর যখন আপনি ডকুমেন্টেশনে গিয়ে authentication পেজটি খোলেন, তখন দেখেন যে OpenID Connect (OIDC) অথবা SAML (security assertion markup language) শুধুমাত্র পেইড প্ল্যানের অন্তর্ভুক্ত।

এটি সাধারণ কোনো পেইড ফিচারের চেয়ে বেশি গুরুত্বপূর্ণ, কারণ SSO-ই হলো সেই মাধ্যম যা বিভিন্ন self-hosted সার্ভিসকে একটি একক সিস্টেমের মতো কাজ করতে সাহায্য করে। একটি identity provider (IdP) আপনাকে প্রতি ব্যক্তির জন্য একটি অ্যাকাউন্ট, একটি পাসওয়ার্ড পলিসি, multi-factor authentication (MFA) চালু করার একটি জায়গা এবং কাউকে অ্যাক্সেস থেকে সরিয়ে দেওয়ার একটি কেন্দ্রীয় নিয়ন্ত্রণ ব্যবস্থা প্রদান করে। এটি ছাড়া, প্রতিটি অ্যাপের নিজস্ব ছোট একটি ইউজার ডাটাবেস থাকে এবং আপনাকে প্রতিটি ডাটাবেস আলাদাভাবে রক্ষণাবেক্ষণ করতে হয়।

এই ধারাটি এত পুরনো যে এর একটি পাবলিক স্কোরবোর্ডও রয়েছে। sso.tax-এ SSO Wall of Shame সেইসব ভেন্ডরদের তালিকা প্রকাশ করে যারা single sign-on-এর জন্য অতিরিক্ত প্রিমিয়াম চার্জ করে। এই তালিকায় 2018 সাল থেকে এন্ট্রি রয়েছে এবং এর লেখক একটি যৌক্তিক মানদণ্ড নির্ধারণ করেছেন: "যদি আপনার SSO সাপোর্টের জন্য মূল মূল্যের ওপর মাত্র 10% বৃদ্ধি করা হয়, তবে আপনি এই তালিকায় নেই।" এই তালিকার বেশিরভাগই ক্লোজড-সোর্স সফটওয়্যার। এখন একই ধরনের প্রাইসিং লজিক ওপেন সোর্স প্রজেক্টগুলোতেও দেখা যাচ্ছে যা আপনি নিজে হোস্ট করেন।

কেন মেইনটেইনাররা সিঙ্গেল সাইন-অন (SSO) কে পেইড টায়ারের অন্তর্ভুক্ত করেন

এর দুটি কারণ রয়েছে এবং উভয়ই যৌক্তিক। SSO সাপোর্ট করা ব্যয়বহুল এবং এটি হাতেগোনা কয়েকটি ফিচারের মধ্যে একটি, যার জন্য বড় প্রতিষ্ঠানগুলো অর্থ প্রদান করতে রাজি থাকে।

সাপোর্ট খরচটি বাস্তব, কারণ একটি আইডেন্টিটি ইন্টিগ্রেশন কখনোই পুরোপুরি শেষ হয় না। প্রতিটি IdP তাদের ক্লেইমগুলো কিছুটা ভিন্নভাবে ফরম্যাট করে। গ্রুপ ম্যাপিং, সেশন লাইফটাইম, রিডাইরেক্ট URL এবং ক্লক স্কিউ—এগুলোর প্রতিটিই লগইন ত্রুটি তৈরি করতে পারে। আর একটি লগইন ত্রুটি মানেই সব ব্যবহারকারী একসাথে লক হয়ে যাওয়া, তাই এই টিকিটগুলো অত্যন্ত জরুরি ভিত্তিতে সমাধান করতে হয়। এরপর আসে পরবর্তী অনুরোধগুলো: নেস্টেড গ্রুপ, রোল ম্যাপিং, SCIM (system for cross-domain identity management) এর মাধ্যমে স্বয়ংক্রিয় প্রোভিশনিং এবং অডিট লগ, যা কমপ্লায়েন্স টিম যাচাই করে।

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

সাধারণ অভিযোগের বিপরীতে একটি সংশোধন: কোনো ফিচার সরিয়ে ফেলা হয়েছে বলে ধরে নেওয়ার আগে চেঞ্জলগ চেক করুন, কারণ কোনো কিছু সরিয়ে ফেললে তা রিলিজ নোটে উল্লেখ থাকে। এই পোস্টের জন্য আমি যেসব প্রজেক্ট যাচাই করেছি, সেগুলোর পেইড SSO ফিচারগুলো শুরু থেকেই পেইড টায়ারের জন্য তৈরি করা হয়েছিল। আমি এমন কোনো ঘটনা খুঁজে পাইনি যেখানে কার্যকর ফ্রি SSO সুবিধা সরিয়ে নেওয়া হয়েছে। Grafana এক্ষেত্রে একটি আদর্শ উদাহরণ। তাদের SAML পৃষ্ঠায় এক লাইনের একটি নোট আছে, "Available in Grafana Enterprise and Grafana Cloud", অথচ ওপেন সোর্স বিল্ডে আপনার নিজস্ব ইস্যুয়ারে জেনেরিক OAuth ব্যবহার করা যায়।

SSO tax আসলে আপনার কী ক্ষতি করে

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

এর বড় ক্ষতিটি হলো ম্যানুয়াল আইডেন্টিটি ম্যানেজমেন্টের কাজ, যা চারটি ক্ষেত্রে প্রভাব ফেলে।

• প্রতিটি অ্যাপের জন্য আলাদা পাসওয়ার্ড স্টোর থাকে, তাই একটি পাসওয়ার্ড পুনরায় ব্যবহার করা হলে তা সেই পাসওয়ার্ড ব্যবহার করা প্রতিটি অ্যাপের নিরাপত্তার জন্য ঝুঁকি তৈরি করে।
• মেমোরি বা স্মৃতি থেকে অফবোর্ডিং করা। একজন কর্মী কোন কোন সার্ভিস ব্যবহার করতেন তা আপনাকে মনে রাখতে হয়, আর যে সার্ভিসটি আপনি ভুলে যান সেটিই সবচেয়ে গুরুত্বপূর্ণ হয়ে দাঁড়ায়।
• প্রতিটি অ্যাপে আলাদাভাবে MFA কনফিগার করা, যদি অ্যাপটি তা সমর্থন করে।
• শেয়ারড লগইন, যা এই চাপের মুখে ছোট টিমগুলোতে বাস্তবে ঘটে থাকে।

শেষ পয়েন্টটি আলাদাভাবে আলোচনার দাবি রাখে। যখন একটি টিমের সবাই ডকুমেন্ট ম্যানেজারের একটি অ্যাডমিনিস্ট্রেটর অ্যাকাউন্ট শেয়ার করে, তখন অডিট ট্রেইলে সব কাজের জন্য একটি নামই রেকর্ড হয়। ফলে কে ইনভয়েস ডিলিট করেছে তা শনাক্ত করা অসম্ভব হয়ে পড়ে। প্রতি-ব্যবহারকারী অনুমতি বা per-user permissions-ও কাজ করা বন্ধ করে দেয়, কারণ সেখানে ব্যবহারকারী মাত্র একজন। SSO tax-এর আসল ক্ষতি এখানেই: এটি ছোট টিমগুলোকে একটি শেয়ারড অ্যাকাউন্টের দিকে ঠেলে দেয়, যা অন্য যেকোনো বিকল্পের চেয়ে বেশি ঝুঁকিপূর্ণ।

যেকোনো কিছু গ্রহণ করার আগে যে চেকলিস্ট অনুসরণ করবেন

অ্যাপটিতে 400টি ডকুমেন্ট জমা হওয়ার পরে নয়, বরং docker compose up চালানোর আগেই এটি সম্পন্ন করুন।

1. ডকুমেন্টেশনের অথেন্টিকেশন পেজটি খুলুন এবং একদম উপরে থাকা টায়ার (tier) সংক্রান্ত নোটটি পড়ুন। পেইড ফিচারগুলোতে একটি ব্যাজ বা এক লাইনের প্রাপ্যতা সংক্রান্ত বাক্য থাকে।
2. অ্যাপটি নির্দিষ্ট কিছু পাবলিক প্রোভাইডারের তালিকার পরিবর্তে আপনার নিজস্ব ইস্যুয়ারে OIDC বা SAML সমর্থন করে কি না তা নিশ্চিত করুন।
3. রোল এবং গ্রুপ ম্যাপিং পরীক্ষা করুন। ইউজার তৈরি করা কাজের অর্ধেক; দশটি অ্যাপে হাতে কলমে পারমিশন অ্যাসাইন করা বাকি অর্ধেক কাজ যা বেশ কষ্টসাধ্য।
4. অ্যাপটি কোনো ট্রাস্টেড প্রক্সি থেকে হেডার হিসেবে অথেন্টিকেটেড ইউজারনেম গ্রহণ করে কি না এবং আপনি কোন প্রক্সিকে ট্রাস্ট করবেন তা নির্ধারণ করা যায় কি না, তা যাচাই করুন।
5. গিট (git)-এ লাইসেন্স হিস্ট্রি পড়ুন এবং কন্ট্রিবিউটররা CLA (contributor licence agreement) স্বাক্ষর করে কি না তা দেখুন।
6. অফবোর্ডিং (offboarding) প্রক্রিয়া যাচাই করুন। IdP অ্যাকাউন্ট ডিজেবল করা হলে API (application programming interface) টোকেন এবং লাইভ সেশনের কী হয় তা খুঁজে বের করুন।

2 নম্বর পয়েন্টটি নিয়ে সবচেয়ে বেশি হতাশ হতে হয়। "Sign in with Google" বাটন মানেই আপনার আইডেন্টিটি প্রোভাইডারের সাথে OIDC নয়: এটি একটি নির্দিষ্ট ভেন্ডরের সাথে ফিক্সড ইন্টিগ্রেশন। প্রকৃত সাপোর্টে আপনার কাছে একটি ইস্যুয়ার URL চাওয়া হবে এবং বাকি সবকিছু ডিসকভারি থেকে আসবে। আপনি একটি কমান্ডের মাধ্যমেই আপনার প্রোভাইডারের দিকটি নিশ্চিত করতে পারেন।

curl -s https://id.example.com/.well-known/openid-configuration \
  | jq '.issuer, .authorization_endpoint, .token_endpoint'

একটি সঠিক কনফিগারেশন সম্পন্ন প্রোভাইডারের কাছ থেকে তিনটি URL পাওয়া যায়। ফলাফল খালি থাকা বা 404 এর অর্থ সাধারণত ডিসকভারি পাথটি ভুল, এবং এই পাথটি প্রোভাইডার ভেদে ভিন্ন হয়: Keycloak এটি /realms/<realm>/.well-known/openid-configuration এর অধীনে পাবলিশ করে। যদি অ্যাপটিতে ইস্যুয়ার URL দেওয়ার কোনো ফিল্ড না থাকে, তবে ফিচারের তালিকায় যাই লেখা থাকুক না কেন, এটি আপনার IdP-এর সাথে যোগাযোগ করতে পারবে না।

6 নম্বর পয়েন্টটি সাধারণত কেউ চলে যাওয়ার কয়েক সপ্তাহ পরে সমস্যার কারণ হয়ে দাঁড়ায়। IdP-তে অ্যাকাউন্ট ডিজেবল করলে নতুন লগইন বন্ধ হয়। কিন্তু এটি অ্যাপের আগে ইস্যু করা কোনো API টোকেনকে বাতিল করে না, কারণ অ্যাপটি নিজেই সেই টোকেন ভ্যালিডেট করে এবং IdP-কে এ বিষয়ে কিছুই জিজ্ঞেস করে না। তাই অফবোর্ডিংয়ের দুটি ধাপ রয়েছে: প্রথমে IdP-তে অ্যাকাউন্ট ডিজেবল করুন, তারপর প্রতিটি অ্যাপের ভেতর থেকে ইউজার বা তার টোকেনগুলো ডিলিট করুন।

টিয়ার ব্যাজগুলো আসলে কী নির্দেশ করে

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

Grafana তাদের SAML-কে "Available in Grafana Enterprise and Grafana Cloud" হিসেবে প্রকাশ করে, যার সাথে টিম সিঙ্ক এবং SCIM প্রোভিশনিং অন্তর্ভুক্ত থাকে। জেনেরিক OAuth, GitHub OAuth, LDAP (lightweight directory access protocol) এবং auth proxy সবই ওপেন সোর্স বিল্ডে পাওয়া যায়, তাই ছোট পরিসরে যারা self-host করেন তারা তাদের নিজস্ব প্রোভাইডারের মাধ্যমে লগইন করতে পারেন। পেইড ফিচারের সীমাটি SSO-এর সামগ্রিক ধারণার পরিবর্তে SAML-এর ক্ষেত্রে প্রযোজ্য, যা "SSO tax" শব্দগুচ্ছের মাধ্যমে অনেক সময় অস্পষ্ট হয়ে যায়।

Metabase-এর অবস্থান আরও স্পষ্ট। তাদের ডকুমেন্টেশনে বলা হয়েছে, "SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud)।" ওপেন সোর্স সংস্করণে পাসওয়ার্ড লগইন এবং LDAP সুবিধা বজায় রাখা হয়েছে।

Passbolt তাদের SSO ডকুমেন্টেশনে Pro এবং Cloud-এর উল্লেখ রেখেছে, তাই কমিউনিটি সংস্করণে এই সুবিধা নেই। ডকুমেন্টেশনে উল্লিখিত প্রোভাইডারগুলোর মধ্যে Keycloak এবং Entra ID অন্তর্ভুক্ত।

এখন অন্য দিকটি দেখা যাক, কারণ এই প্যাটার্নটি সব ক্ষেত্রে প্রযোজ্য নয়।

• GitLab Self-Managed তাদের SAML পেজে "Tier: Free, Premium, Ultimate" উল্লেখ করেছে, তাই আপনার নিজস্ব GitLab-এ SAML ব্যবহারের জন্য কোনো খরচ নেই।
• Paperless-ngx, PAPERLESS_SOCIALACCOUNT_PROVIDERS-এর মাধ্যমে OIDC কনফিগার করে, PAPERLESS_DISABLE_REGULAR_LOGIN ব্যবহার করে লোকাল লগইন ফর্ম লুকিয়ে রাখে এবং PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS-এর মাধ্যমে ক্লেইমগুলোকে গ্রুপে ম্যাপ করে।
• Planka, OIDC_ISSUER, OIDC_CLIENT_ID এবং OIDC_CLIENT_SECRET গ্রহণ করে, ডিফল্ট স্কোপ হিসেবে openid profile email ব্যবহার করে এবং একটি রোল ক্লেইম থেকে অ্যাডমিনিস্ট্রেটরদের প্রমোট করে OIDC_ADMIN_ROLES-এর মাধ্যমে।
• BookStack, AUTH_METHOD=oidc-এর মাধ্যমে সুইচ করে এবং এরপর প্রোভাইডার গ্রুপগুলোকে তাদের নিজস্ব রোলে ম্যাপ করে OIDC_USER_TO_GROUPS=true এবং OIDC_GROUPS_CLAIM ব্যবহার করে।
• Vaultwarden, 27 ডিসেম্বর 2025-এ তাদের 1.35.0 ভার্সনে "support for SSO with OpenID Connect" যুক্ত করেছে, যা একজন কন্ট্রিবিউটরের পুল রিকোয়েস্ট থেকে এসেছে যিনি আগে এটি একটি ফোর্ক হিসেবে পরিচালনা করতেন।
• listmonk-এ v4.0.0 ভার্সন থেকে ইউজার রোলের পাশাপাশি OIDC লগইন সুবিধা রয়েছে।

কোনো প্রজেক্টে কাজ শুরু করার আগেই এই বিষয়গুলো যাচাই করে নিন। একটি Planka kanban board এবং অন্যান্য self-hosted Trello alternatives সব ক্ষেত্রে একইভাবে আইডেন্টিটি ম্যানেজমেন্ট পরিচালনা করে না, যেমনটা করে না BookStack, Wiki.js and Outline। ফ্রি OIDC একটি ফিচার যা আপনি স্টোরেজ লিমিট বা মোবাইল ক্লায়েন্টের মতোই গুরুত্ব দিয়ে বিবেচনা করতে পারেন। আপনি যদি এখনও তালিকা তৈরি করে থাকেন, তবে what to self-host in 2026 একটি ভালো শুরুর পয়েন্ট হতে পারে, এবং the Paperless-ngx document manager ও Vaultwarden উভয়ই বর্তমানে আপনাকে ফ্রি OIDC সুবিধা দিচ্ছে।

কেন অ্যাপের সামনে থাকা reverse proxy কোনো single sign-on নয়

এর একটি প্রচলিত সমাধান হলো forward auth। আপনার reverse proxy প্রতিটি অনুরোধ আটকে রাখে, একটি authentication service-কে জিজ্ঞাসা করে যে এই ব্রাউজারটি সাইন-ইন করা আছে কি না, এবং শুধুমাত্র তখনই অনুরোধটি অ্যাপের কাছে পাঠায়। authentik একে proxy provider বলে, যার একটি forward auth মোড একক অ্যাপ্লিকেশনের জন্য এবং অন্যটি পুরো ডোমেইনের জন্য কাজ করে। Authelia এবং oauth2-proxy একই কাজ করে।

authentik-এর নিজস্ব উদাহরণ অনুসরণ করে একটি Caddy site block দেখতে এমন হয়:

app.example.com {
  forward_auth http://authentik-outpost:9000 {
    uri /outpost.goauthentik.io/auth/caddy
    copy_headers X-Authentik-Username X-Authentik-Email X-Authentik-Groups
    trusted_proxies private_ranges
  }
  reverse_proxy app:8000
}

Caddy-তে হেডার নামগুলোর বড় হাতের বা ছোট হাতের অক্ষর (capitalisation) গুরুত্বপূর্ণ, কারণ নামের অমিল থাকলে তা খালি হিসেবে পৌঁছায়। অনুমোদিত প্রতিটি অনুরোধে, outpost X-authentik-username, X-authentik-email, X-authentik-groups এবং আরও কিছু হেডার সেট করে।

এটি আপনাকে যা দেয় তা হলো: আপনার identity provider পার না হয়ে কেউ অ্যাপে পৌঁছাতে পারে না, তাই একটি unpatched login form আর ইন্টারনেটে উন্মুক্ত থাকে না এবং প্রক্সির পেছনের সবকিছুর ওপর MFA কার্যকর হয়।

এটি আপনাকে যা দেয় না তা হলো: অ্যাপের ভেতরে identity। অ্যাপের নিজস্ব অ্যাকাউন্ট এবং কে সাইন-ইন করেছে সে সম্পর্কে নিজস্ব ধারণা থাকে। যদি সবাই প্রক্সি পার হয়ে একটি শেয়ারড অ্যাডমিনিস্ট্রেটর অ্যাকাউন্টে প্রবেশ করে, তবে আপনার একটি শক্তিশালী প্রধান ফটক থাকলেও তার পেছনে একটি বেনামী সেশন থাকে। audit log-এ কেবল একটি নামই দেখা যায়। মানুষের মধ্যে অনুমতির পার্থক্য করা সম্ভব হয় না। এই ব্যবস্থাকে SSO বলা একটি নিরাপত্তা সংক্রান্ত ভুল, কারণ offboarding-এর বিষয়টি কেবল অর্ধেক সত্য: আপনার IdP থেকে ব্যক্তিকে সরিয়ে দিলে প্রধান ফটক বন্ধ হয়ে যায়, কিন্তু অ্যাপের ভেতরে তাদের তৈরি করা API token যে কেউ সরাসরি অ্যাপে পৌঁছাতে পারলে কাজ করতে থাকে।

হেডার অথেন্টিকেশন নিরাপদ করা

কিছু অ্যাপ প্রক্সির কাছ থেকে ইউজারনেম গ্রহণ করে, যা আপনাকে পেইড SSO ছাড়াই প্রতি-ব্যবহারকারী (per-user) পরিচিতি ব্যবহারের সুবিধা দেয়। প্রতিটি প্রজেক্টে এই সেটিংয়ের নাম ভিন্ন হয়।

Grafana একে auth proxy বলে এবং এটি ডিফল্টভাবে নিষ্ক্রিয় থাকে। হেডার নামটি ডিফল্টভাবে X-WEBAUTH-USER থাকে এবং আপনি আপনার প্রক্সিতে যে হেডার সেট করেছেন, সেটির দিকে একে নির্দেশ করে দিতে পারেন।

[auth.proxy]
enabled = true
header_name = X-authentik-username
header_property = username
auto_sign_up = true
whitelist = 10.0.0.5

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

[security]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER
REVERSE_PROXY_TRUSTED_PROXIES = 10.0.0.5/32
REVERSE_PROXY_LIMIT = 1

REVERSE_PROXY_TRUSTED_PROXIES ডিফল্টভাবে 127.0.0.0/8,::1/128 থাকে এবং REVERSE_PROXY_LIMIT হলো সেই সংখ্যা, যতগুলো প্রক্সিকে Gitea চেইন হিসেবে বিশ্বাস করবে। এই লিমিট শূন্য করে দিলে হেডার হ্যান্ডলিং পুরোপুরি বন্ধ হয়ে যায়।

Paperless-ngx-এ PAPERLESS_ENABLE_HTTP_REMOTE_USER এর সাথে PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME সুবিধা রয়েছে এবং এর ডকুমেন্টেশনে একটি সতর্কবার্তা দেওয়া আছে যা এই ধরনের সব সেটিংসের ক্ষেত্রেই প্রযোজ্য:

এটি অনুরোধের সাথে একটি Remote-User: <username> হেডার যোগ করে অথেন্টিকেশনের সুযোগ দেয়। সতর্কতার সাথে ব্যবহার করুন!

হেডার অথেন্টিকেশন নিরাপদ রাখতে দুটি নিয়ম মেনে চলতে হয় এবং উভয়ই রিচেবিলিটি বা অ্যাক্সেসযোগ্যতার সাথে সম্পর্কিত। প্রথমত, অ্যাপটি প্রক্সি ছাড়া অন্য কোনোভাবে অ্যাক্সেস করা যাবে না, কারণ যে কেউ অ্যাপটির সাথে সকেট সংযোগ স্থাপন করতে পারলে সে হেডার পাঠিয়ে যেকোনো ব্যবহারকারী হিসেবে লগইন করতে পারবে। Docker-এ ports: ["8000:8000"] প্রতিটি ইন্টারফেসে পাবলিশ হয়, তাই ports: ["127.0.0.1:8000:8000"] ব্যবহার করে একে লুপব্যাক অ্যাড্রেসে বাইন্ড করুন অথবা পাবলিশ করা পোর্টটি সরিয়ে প্রক্সিকে একই Docker নেটওয়ার্কে রাখুন। দ্বিতীয়ত, প্রক্সিকে অবশ্যই ক্লায়েন্টের কাছ থেকে আসা হেডারের যেকোনো কপি মুছে ফেলতে হবে, যাতে অ্যাপটি শুধুমাত্র সেই ভ্যালুই দেখতে পায় যা আপনার প্রক্সি অথেন্টিকেশনের পর সেট করেছে।

উভয়ই পরীক্ষা করুন। প্রথম কমান্ডটি আপনার VPS-এর বাইরের কোনো মেশিন থেকে এবং দ্বিতীয়টি সরাসরি সার্ভারে চালান।

curl -si -H "Remote-User: admin" http://203.0.113.10:8000/ | head -n 1
ss -ltnp | grep 8000

curl কমান্ডটি সংযোগ করতে ব্যর্থ হওয়া উচিত এবং ss-এর আউটপুট 0.0.0.0:8000-এর পরিবর্তে 127.0.0.1:8000 দেখানো উচিত। যদি প্রথম লাইনে HTTP/1.1 302 Found দেখায়, তার মানে অ্যাপটি সরাসরি পাবলিক ইন্টারনেটে সাড়া দিচ্ছে, ফলে যে কেউ হেডারে নাম লিখে যেকোনো ব্যবহারকারী হিসেবে সাইন ইন করতে পারবে।

বিনামূল্যে SSO না থাকলে অভিযোগ না করে সিদ্ধান্ত নিন

চারটি বিকল্প, আমি যেভাবে চেষ্টা করব সেই ক্রমানুসারে।

1. যে অ্যাপে OIDC অন্তর্ভুক্ত আছে সেটি বেছে নিন। যখন দুটি প্রজেক্ট একই কাজ করে এবং একটি আপনার identity provider-এর সাথে বিনামূল্যে কাজ করতে পারে, তখন সেটি পরিচালন ব্যয়ের ক্ষেত্রে একটি বড় পার্থক্য তৈরি করে।

1. সততার সাথে forward auth ব্যবহার করুন। একটি অ্যাকাউন্ট এবং একজন অপারেটর আছে এমন অ্যাডমিন টুলের ক্ষেত্রে, সামনে একটি proxy থাকাই যথেষ্ট, এবং অ্যাপের ভেতরে প্রতি-ব্যবহারকারী identity কোনো বাড়তি সুবিধা দেয় না।

1. অর্থ প্রদান করুন। যদি অ্যাপটি আপনার কাজের জন্য কেন্দ্রীয় হয় এবং প্রতি-ব্যবহারকারী মূল্য আপনার দলের আকারের সাথে সামঞ্জস্যপূর্ণ হয়, তবে এই অর্থ প্রজেক্টটিকে সচল রাখে। অন্যথায়, আপনাকে আপনার ব্যক্তিগত সময় ব্যয় করে এর বিকল্প খুঁজতে হবে।

1. issue tracker-এ খোঁজার পর upstream-এর কাছে অনুরোধ করুন। Vaultwarden-এর OIDC সাপোর্ট একজন কন্ট্রিবিউটরের fork এবং দীর্ঘস্থায়ী pull request-এর মাধ্যমে এসেছে, তাই কার্যকর ইমপ্লিমেন্টেশনসহ ফিচার রিকোয়েস্ট অনেক সময় ফ্রি সংস্করণে যুক্ত হয়।

আপনার নিজস্ব identity provider ছাড়া এর কোনোটিই কাজ করবে না, তাই এটিই সবার আগে তৈরি করতে হবে। VPS-এ authentik চালানো আপনাকে একটি OIDC এবং SAML প্রোভাইডার এবং উপরে উল্লিখিত forward auth আউটপোস্ট ব্যবহারের সুবিধা দেবে, এবং Keycloak, authentik এবং Zitadel-এর তুলনা আপনাকে সিদ্ধান্ত নিতে সাহায্য করবে যদি আপনি এখনই কোনো একটিতে প্রতিশ্রুতিবদ্ধ হতে না চান।

লাইসেন্সের ইতিহাস এবং কেন এটি চেকলিস্টে রাখা হয়েছে

শেষ চেকলিস্ট আইটেমটি ভবিষ্যৎ নিয়ে, কারণ আজকের টায়ার লেআউট কেবল একটি নির্দিষ্ট সময়ের চিত্র। দুটি সুপ্রমাণিত ঘটনা দেখায় যে পরিস্থিতি কত দ্রুত পরিবর্তিত হতে পারে। HashiCorp 10 আগস্ট 2023 তারিখে তাদের ভবিষ্যতের সব রিলিজের জন্য Business Source License 1.1 গ্রহণ করে, যেখানে আগের রিলিজগুলো MPL 2.0 (Mozilla Public License)-এর অধীনেই থেকে যায়। Redis 2024 সালের মার্চ মাসে SSPL (server side public license)-এ চলে যায়, এরপর 1 মে 2025 তারিখে ঘোষণা করে যে Redis 8 এখন AGPLv3 (GNU Affero General Public License)-এর অধীনে রিলিজ হবে।

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

কোনো প্রজেক্টের ওপর ভিত্তি করে কাজ শুরু করার আগে তার ইতিহাস নিজে যাচাই করে নিন।

git clone --filter=blob:none https://github.com/paperless-ngx/paperless-ngx.git
cd paperless-ngx
git log --follow --oneline -- LICENSE

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

FAQ

SSO tax কী?

SSO tax হলো এমন একটি চর্চা যেখানে পণ্যটি বিনামূল্যে বা কম মূল্যে পাওয়া গেলেও Single Sign-on (SSO) ফিচারের জন্য অতিরিক্ত মূল্য দাবি করা হয়। self-hosted সফটওয়্যারের ক্ষেত্রে এটি এমন একটি ওপেন সোর্স অ্যাপ্লিকেশনের মতো, যা আপনি লাইসেন্স কি ছাড়াই চালাতে পারেন, কিন্তু OIDC বা SAML লগইন ব্যবহারের জন্য প্রিমিয়াম টায়ারের প্রয়োজন হয়। এই নামটি এসেছে sso.tax-এর 'SSO Wall of Shame' থেকে, যা সেইসব ভেন্ডরদের তালিকাভুক্ত করে যারা এই ফিচারের জন্য বড় অংকের প্রিমিয়াম চার্জ করে। একজন self-hoster-এর জন্য এর ফলাফল হলো প্রতিটি অ্যাপের নিজস্ব ইউজার ডাটাবেস থাকে, ফলে অ্যাকাউন্টগুলো হাতে তৈরি এবং মুছে ফেলতে হয়।

Forward auth সহ একটি reverse proxy কি SSO-এর সমান?

না। Forward auth শুধুমাত্র মূল প্রবেশপথকে সুরক্ষিত করে: কোনো অনুরোধ অ্যাপে পৌঁছানোর আগেই আপনার প্রক্সি identity provider-এর সাথে যাচাই করে নেয়। এর পেছনের অ্যাপটি তখনও তার নিজস্ব অ্যাকাউন্ট ব্যবহার করে, তাই যদি সবাই একটি সাধারণ লগইন পেজে পৌঁছায়, তবে আপনি একটি একক anonymous session পাবেন এবং অডিট লগে কেবল একটি নামই দেখা যাবে। এটি তখনই প্রকৃত per-user identity হয়ে ওঠে যখন অ্যাপটি কোনো header থেকে ইউজারনেম পড়ে নিতে পারে, যা Grafana-এর auth proxy, Gitea-এর reverse proxy authentication এবং Paperless-ngx-এর PAPERLESS_ENABLE_HTTP_REMOTE_USER করতে পারে। এই সেটিংসগুলো তখনই নিরাপদ যখন অ্যাপটিকে প্রক্সি ছাড়া অন্য কোনোভাবে অ্যাক্সেস করা সম্ভব নয়, কারণ header একটি সাধারণ স্ট্রিং যা যেকোনো ক্লায়েন্ট পাঠাতে পারে।

কোন self-hosted অ্যাপগুলোর ফ্রি সংস্করণে OIDC অন্তর্ভুক্ত আছে?

আগস্ট 2026-এ প্রজেক্ট ডকুমেন্টেশন অনুযায়ী যাচাই করা হয়েছে: Paperless-ngx, Planka, BookStack, Gitea, listmonk এবং Vaultwarden—সবগুলোই তাদের ফ্রি বিল্ডে OIDC সমর্থন করে এবং GitLab Self-Managed তাদের Tier: Free-এর অধীনে SAML তালিকাভুক্ত করেছে। Grafana-এর ওপেন সোর্স বিল্ড আপনার নিজস্ব issuer-এর বিপরীতে generic OAuth হ্যান্ডেল করতে পারে, তবে সেখানে SAML একটি Enterprise ফিচার। ইনস্টল করার আগে প্রজেক্টের নিজস্ব authentication পেজে এটি নিশ্চিত করে নিন, কারণ নতুন releases-এর সাথে এই তালিকা পরিবর্তিত হতে পারে।

Single sign-on আনলক করার জন্য কি আমার প্রিমিয়াম টায়ারের মূল্য পরিশোধ করা উচিত?

দুটি বিষয়ের ওপর ভিত্তি করে সিদ্ধান্ত নিন: কতজন মানুষের অ্যাকাউন্টের প্রয়োজন এবং কতগুলো অ্যাপ আপনাকে হাতে পরিচালনা করতে হবে। একজন বা দুজন অ্যাডমিনিস্ট্রেটরের জন্য, লোকাল অ্যাকাউন্টের সামনে forward auth ব্যবহার করাই যথেষ্ট এবং প্রিমিয়াম টায়ার খুব একটা বাড়তি সুবিধা দেয় না। এমন একটি টিমের জন্য যেখানে মানুষ নিয়মিত যোগ দেয় বা ছেড়ে যায়, offboarding-এর সময় একটি অ্যাকাউন্ট বাদ পড়ে যাওয়া লাইসেন্স ফি-এর চেয়েও বেশি ব্যয়বহুল হতে পারে এবং আপনার দেওয়া অর্থ সেই রক্ষণাবেক্ষণ কাজে ব্যয় হয় যার ওপর আপনি নির্ভর করছেন। যদি মূল্য আপনার বাজেটের সাথে না মেলে, তবে এমন অ্যাপ বেছে নেওয়াই বুদ্ধিমানের কাজ যাতে OIDC অন্তর্ভুক্ত আছে, পরিবর্তে এমন অ্যাপ ব্যবহার করা যা এটি সমর্থন করে না।