Self-hosted software-এ SSO tax কেন দিতে হয়

SSO tax কী

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

এটি সাধারণ paywalled feature-এর চেয়ে বেশি গুরুত্বপূর্ণ। কারণ SSO-ই একাধিক self-hosted service-কে একটি সমন্বিত system হিসেবে কাজ করায়। একটি identity provider (IdP) প্রত্যেক ব্যক্তির জন্য একটি account, একটি password policy, multi-factor authentication (MFA) সক্রিয় করার একটি কেন্দ্রীয় স্থান এবং কারও access বন্ধ করার একটি কেন্দ্রীয় ব্যবস্থা দেয়। এটি না থাকলে প্রতিটি app নিজস্ব ছোট user database বজায় রাখে, এবং আপনাকে প্রতিটি database হাতে পরিচালনা করতে হয়।

এই প্যাটার্নটি এত পুরোনো যে এর একটি public scoreboard-ও আছে। sso.tax-এর SSO Wall of Shame এমন vendor-দের তালিকাভুক্ত করে, যারা single sign-on-এর জন্য বড় অতিরিক্ত মূল্য নেয়। তালিকায় 2018 পর্যন্ত পুরোনো entry রয়েছে। এর লেখক একটি যুক্তিসঙ্গত সীমা নির্ধারণ করেছেন: "আপনার SSO support-এর জন্য মূল্য 10% বাড়ালে আপনি এই তালিকায় নেই।" তালিকার অধিকাংশ software closed source। একই pricing logic এখন self-hosted open source project-গুলিতেও দেখা যাচ্ছে।

Maintainer-রা কেন single sign-on-কে paid tier-এর আড়ালে রাখেন

এর দুটি কারণ আছে, এবং দুটিই বাস্তব। SSO support করা ব্যয়বহুল, আর এটি এমন কয়েকটি feature-এর একটি, যার জন্য বড় প্রতিষ্ঠান অর্থ দিতে রাজি থাকে।

Support-এর খরচ সত্যিই বেশি, কারণ identity integration কখনো পুরোপুরি শেষ হয় না। প্রতিটি IdP তার claims সামান্য ভিন্নভাবে format করে। Group mapping, session lifetime, redirect URL এবং clock skew—প্রতিটি বিষয় login bug তৈরি করতে পারে। একটি login bug একসঙ্গে সব user-কে access থেকে বঞ্চিত করে, তাই এই ticket-গুলো জরুরি। এরপর আসে পরবর্তী request: nested group, role mapping, SCIM (system for cross-domain identity management) ব্যবহার করে automatic provisioning, এবং compliance team যে audit log পরীক্ষা করবে।

Revenue-এর বিষয়টি malice নয়, সরল হিসাব। কোনো company নিজের IdP-এর সঙ্গে app-টি connect করতে না পারলে সেটি একেবারেই deploy করবে না। তাই SSO এমন একটি স্পষ্ট সীমারেখা তৈরি করে, যার এক পাশে অর্থ প্রদানকারী user এবং অন্য পাশে অর্থ প্রদান না করা user থাকে। একটি open core project-কে এই সীমারেখা কোথাও স্থাপন করতেই হয়। প্রায় অন্য যেকোনো feature-এর তুলনায় SSO এই কাজের জন্য বেশি উপযুক্ত। তাই এত project এটি বেছে নেয়।

প্রচলিত অভিযোগটি নিয়ে একটি সংশোধন: কোনো feature সরিয়ে নেওয়া হয়েছে ধরে নেওয়ার আগে changelog পরীক্ষা করুন, কারণ removal release notes-এ দেখা যায়। এই post-এর জন্য আমি যেসব project পরীক্ষা করেছি, সেগুলোর paid SSO feature শুরু থেকেই paid tier-এর জন্য তৈরি ছিল। কার্যকর free SSO পরে প্রত্যাহার করা হয়েছে—এমন কোনো উদাহরণ আমি পাইনি। Grafana এখানে একটি সাধারণ উদাহরণ। এর SAML page-এ এক লাইনের নোট আছে, "Available in Grafana Enterprise and Grafana Cloud"; অন্যদিকে নিজের issuer-এর বিরুদ্ধে generic OAuth open source build-এ কাজ করে।

SSO-এর প্রকৃত খরচ

অর্থের অংশটি তুলনামূলকভাবে ছোট। Paid tier-এ user-প্রতি মূল্য নেওয়া হয়, তাই আপনার team বড় হলে bill-ও বাড়ে; কিন্তু hosting এবং upgrade-এর দায়িত্ব আপনারই থাকে।

বড় খরচটি manual identity management-এর, এবং এটি চারটি জায়গায় দেখা দেয়।

• প্রতি app-এর জন্য আলাদা password store রাখতে হয়। ফলে একই password একাধিক app-এ ব্যবহার করলে, একটি password ফাঁস হলেই সেই password ব্যবহার করা প্রতিটি app ঝুঁকিতে পড়ে।
• স্মৃতিনির্ভর offboarding। কোনো ব্যক্তি কোন কোন service ব্যবহার করেছেন, তার প্রতিটি মনে রাখতে হয়। যে service-টি ভুলে যাবেন, সেটিই পরে গুরুত্বপূর্ণ হয়ে দাঁড়াতে পারে।
• প্রতিটি app-এ আলাদাভাবে MFA configure করতে হয়, যদি app-টি আদৌ তা support করে।
• Shared login ব্যবহার করতে হয়। এই চাপের মধ্যে ছোট team-এ বাস্তবে এটাই ঘটে।

শেষের বিষয়টির জন্য আলাদা করে একটি কথা বলা দরকার। কোনো team document manager-এ একটি administrator account ভাগ করে ব্যবহার করলে audit trail-এ সব কাজের জন্য একই নাম দেখা যায়। তাই invoice কে delete করেছে, তা বোঝা যায় না। Per-user permission-ও আর কার্যকর থাকে না, কারণ user আসলে একজনই। SSO tax-এর প্রকৃত ক্ষতি এখানেই: এটি ছোট team-গুলোকে একটি shared account ব্যবহারের দিকে ঠেলে দেয়, যা অন্য যেকোনো বিকল্পের চেয়ে খারাপ।

গ্রহণ করার আগে চালানোর checklist

docker compose up চালানোর আগে এটি পরীক্ষা করুন, অ্যাপে 400টি নথি জমা হওয়ার পরে নয়।

1. ডকুমেন্টেশনে authentication page খুলে উপরের tier note পড়ুন। Paid feature-এর পাশে একটি badge বা availability সম্পর্কিত এক লাইনের বাক্য থাকে।
2. নিশ্চিত করুন, অ্যাপটি নির্দিষ্ট public provider-এর তালিকার পরিবর্তে আপনার নিজের issuer-এর সঙ্গে OIDC বা SAML ব্যবহার করে।
3. role ও group mapping পরীক্ষা করুন। user তৈরি করা কাজের অর্ধেক, আর 10টি অ্যাপে হাতে permission দেওয়া বাকি অর্ধেক—যেটি সবচেয়ে বেশি সমস্যার।
4. পরীক্ষা করুন, trusted proxy থেকে header-এ আসা authenticated username অ্যাপটি গ্রহণ করে কি না এবং কোন proxy-কে এটি বিশ্বাস করবে তা নির্দিষ্ট করে দেওয়া যায় কি না।
5. git-এ licence history পড়ুন এবং contributors-রা CLA (contributor licence agreement) স্বাক্ষর করেন কি না পরীক্ষা করুন।
6. offboarding পরীক্ষা করুন। IdP account disabled হলে API (application programming interface) token এবং সক্রিয় session-এর কী হয়, তা জানুন।

বেশিরভাগ হতাশা Item 2-এ দেখা দেয়। "Sign in with Google" button আপনার identity provider-এর সঙ্গে OIDC নয়; এটি একটি নির্দিষ্ট vendor-এর fixed integration। প্রকৃত support-এর ক্ষেত্রে আপনাকে একটি issuer URL দিতে হয়, আর বাকি সব তথ্য discovery থেকে আসে। একটি command-এ আপনার provider-এর দিকের configuration যাচাই করতে পারেন।

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

সঠিকভাবে কাজ করা provider থেকে 3টি URL ফেরত আসে। ফলাফল খালি হলে বা 404 পাওয়া গেলে সাধারণত discovery path ভুল থাকে। এই path provider অনুযায়ী আলাদা: Keycloak এটি /realms/<realm>/.well-known/openid-configuration-এর অধীনে প্রকাশ করে। অ্যাপে issuer URL দেওয়ার কোনো field না থাকলে feature list-এ যা-ই বলা থাকুক, এটি আপনার IdP-এর সঙ্গে যোগাযোগ করতে পারবে না।

কেউ চলে যাওয়ার কয়েক সপ্তাহ পরে Item 6-এর সমস্যা ধরা পড়ে। IdP-তে account disabled করলে নতুন login বন্ধ হয়। কিন্তু আগে অ্যাপ যে API token জারি করেছে, তা revoke হয় না। কারণ অ্যাপ নিজেই সেই token validate করে এবং IdP-কে আর জিজ্ঞাসা করে না। তাই offboarding-এর 2টি ধাপ আছে: IdP-তে account disabled করুন, তারপর প্রতিটি অ্যাপের ভিতরে user বা তার token মুছে দিন।

টিয়ার ব্যাজে আসলে কী লেখা আছে

2026 সালের August-এ প্রতিটি প্রকল্পের নিজস্ব documentation-এর সঙ্গে এগুলো যাচাই করা হয়েছে। প্রথমে paid দিকটি দেখুন।

Grafana SAML-কে "Available in Grafana Enterprise and Grafana Cloud" হিসেবে প্রকাশ করে। এর সঙ্গে team sync এবং SCIM provisioning-ও রয়েছে। Generic OAuth, GitHub OAuth, LDAP (lightweight directory access protocol) এবং auth proxy—সবই open source build-এ রয়েছে। তাই ছোট self-hoster-ও নিজস্ব provider-এর মাধ্যমে login করতে পারে। Paid সীমাটি single sign-on পুরো বিষয়টির ক্ষেত্রে নয়, SAML-এর ক্ষেত্রে প্রযোজ্য। "SSO tax" কথাটি সাধারণত এই পার্থক্যটি আড়াল করে।

Metabase আরও সরাসরি বলেছে। তাদের documentation-এ লেখা আছে, "SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud)." Open source edition-এ password login এবং LDAP রয়েছে।

Passbolt তার SSO documentation-কে Pro এবং Cloud-এর জন্য চিহ্নিত করে। তাই community edition-এ এটি নেই। Documentation-এ উল্লিখিত provider-এর মধ্যে Keycloak এবং Entra ID রয়েছে।

n8n-এও একই ধরনের ব্যবস্থা রয়েছে। self-hosted community edition fair-code licence-এর অধীনে বিনামূল্যে পাওয়া যায়। কিন্তু SAML এবং LDAP login enterprise key-এর আড়ালে থাকে। এটি free n8n edition-এ কী কী নেই—এই দীর্ঘ তালিকার একটি বিষয়।

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

• GitLab Self-Managed-এর SAML page-এ "Tier: Free, Premium, Ultimate" লেখা আছে। তাই নিজের GitLab-এর বিরুদ্ধে SAML ব্যবহার করতে কোনো খরচ হয় না।
• Paperless-ngx `PAPERLESS_SOCIALACCOUNT_PROVIDERS ব্যবহার করে django-allauth-এর মাধ্যমে OIDC configure করে, PAPERLESS_DISABLE_REGULAR_LOGIN দিয়ে local login form আড়াল করে, এবং PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS` দিয়ে claims-কে groups-এর সঙ্গে map করে।
• Planka `OIDC_ISSUER, OIDC_CLIENT_ID এবং OIDC_CLIENT_SECRET গ্রহণ করে, scope-এর default হিসেবে openid profile email ব্যবহার করে, এবং OIDC_ADMIN_ROLES` দিয়ে role claim থেকে administrator নির্ধারণ করে।
• BookStack `AUTH_METHOD=oidc দিয়ে provider পরিবর্তন করে। এরপর OIDC_USER_TO_GROUPS=true এবং OIDC_GROUPS_CLAIM` দিয়ে provider group-গুলোকে নিজস্ব role-এর সঙ্গে map করে।
• Vaultwarden 1.35.0 সংস্করণে 27 December 2025 তারিখে "support for SSO with OpenID Connect" প্রকাশ করে। একজন contributor একটি fork-এ এই feature চালু রেখেছিলেন এবং তাঁর pull request থেকে এটি যুক্ত হয়।
• listmonk v4.0.0 থেকে user role-এর পাশাপাশি OIDC login-ও সমর্থন করে।

আপনি কোনো পণ্য বেছে নেওয়ার সময় এই তথ্য ব্যবহার করুন, পছন্দ চূড়ান্ত করার পরে নয়। একটি Planka kanban board এবং অন্যান্য self-hosted Trello alternatives identity-কে একইভাবে পরিচালনা করে না। একই কথা BookStack, Wiki.js এবং Outline-এর ক্ষেত্রেও প্রযোজ্য। Free OIDC-কে storage limit বা mobile client-এর মতোই একটি বৈশিষ্ট্য হিসেবে বিবেচনা করতে পারেন। আপনি যদি এখনও তালিকা তৈরি করেন, 2026 সালে কী self-host করবেন একটি যুক্তিসংগত সূচনা হতে পারে। Paperless-ngx document manager এবং Vaultwarden—উভয়ই বর্তমানে বিনামূল্যে OIDC দেয়।

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

সাধারণ সমাধান হলো forward auth। আপনার reverse proxy প্রতিটি অনুরোধ আটকে authentication service-কে জিজ্ঞেস করে, এই browser-এ ব্যবহারকারী sign in করে আছে কি না। অনুমোদন পাওয়ার পরেই এটি অনুরোধটি অ্যাপে পাঠায়। authentik এটিকে proxy provider বলে। একটি নির্দিষ্ট অ্যাপের জন্য এর একটি forward auth mode আছে এবং পুরো domain-এর জন্য আরেকটি mode আছে। 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-তে এই header name-গুলোর capitalization গুরুত্বপূর্ণ। নাম না মিললে header-টি খালি অবস্থায় পৌঁছায়। অনুমোদিত প্রতিটি অনুরোধে outpost X-authentik-username, X-authentik-email, X-authentik-groups এবং আরও কয়েকটি header সেট করে।

এতে যে সুবিধা পাওয়া যায় তা হলো, আপনার identity provider পেরিয়ে না গেলে কেউ অ্যাপে পৌঁছাতে পারে না। ফলে patch না করা login form আর Internet-এ সরাসরি exposed থাকে না। Proxy-এর পেছনের সবকিছুর জন্য একসঙ্গে MFA প্রয়োগ করা যায়।

তবে এর মাধ্যমে অ্যাপের ভেতরের identity পাওয়া যায় না। অ্যাপের নিজস্ব account থাকে এবং কে sign in করে আছে সে বিষয়ে অ্যাপের নিজস্ব ধারণা থাকে। সবাই proxy পেরিয়ে একটি shared administrator account-এ গেলে আপনার সামনে শক্তিশালী প্রবেশদ্বার থাকে, কিন্তু তার পেছনে থাকে একটি anonymous session। Audit log-এ এখনও একটি মাত্র নাম দেখা যায়। ব্যবহারকারীদের মধ্যে permission আলাদা করা যায় না। এই ব্যবস্থাকে SSO বলা security mistake, কারণ offboarding-এর বিষয়টি কেবল আংশিকভাবে সত্য: আপনার IdP থেকে কাউকে সরালে প্রবেশদ্বার বন্ধ হয়, কিন্তু ওই ব্যক্তি অ্যাপের ভেতরে তৈরি করা API token ব্যবহার করতে থাকে, যদি কেউ সরাসরি অ্যাপে পৌঁছাতে পারে।

হেডার-ভিত্তিক authentication নিরাপদ করা

কিছু অ্যাপ proxy থেকে username গ্রহণ করে। এর ফলে paid SSO ছাড়াই প্রতি-user identity পাওয়া যায়। প্রতিটি project-এ এই setting-এর নাম আলাদা।

Grafana এটিকে auth proxy বলে এবং এটি disabled অবস্থায় release করা হয়। Header name-এর default হলো X-WEBAUTH-USER। আপনার proxy যে header set করে, সেটি ব্যবহার করার জন্য এটি পরিবর্তন করতে পারেন।

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

whitelist হলো সেই line, যা অনেকে বাদ দেন। Grafana-এর documentation স্পষ্টভাবে বলে যে এটি users-কে header spoof করা থেকে আটকাতে ব্যবহৃত হয়। তাই এখানে শুধু আপনার proxy-এর address রাখা উচিত।

Gitea-তে একই feature ভিন্ন নামে রয়েছে। এটি আরও নিরাপদ default-সহ release করা হয়।

[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-এর default হলো 127.0.0.0/8,::1/128। আর REVERSE_PROXY_LIMIT নির্ধারণ করে Gitea chain-এ কতগুলো proxy-কে trust করবে। এই limit শূন্য করলে header handling সম্পূর্ণ বন্ধ হয়ে যায়।

Paperless-ngx-এ PAPERLESS_ENABLE_HTTP_REMOTE_USER, PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME-এর মাধ্যমে দেওয়া হয়। এর documentation-এ এই setting-গুলোর জন্য প্রযোজ্য সতর্কবার্তাটি রয়েছে:

একটি request-এ শুধু Remote-User: <username> header যোগ করলেই authentication করা যাবে। সতর্কতার সঙ্গে ব্যবহার করুন!

Header authentication নিরাপদ রাখতে দুটি নিয়ম মানতে হবে। দুটিই reachability নিয়ে।

প্রথমত, proxy ছাড়া অ্যাপটি অন্য কোনোভাবে reachable হওয়া যাবে না। কারণ যে কেউ অ্যাপটির socket-এ সংযোগ করতে পারলে ওই header পাঠিয়ে যেকোনো user হিসেবে authentication করতে পারবে। Docker-এ ports: ["8000:8000"] প্রতিটি interface-এ publish করে। তাই ports: ["127.0.0.1:8000:8000"] দিয়ে এটিকে loopback address-এ bind করুন। অথবা published port সরিয়ে proxy-কে একই Docker network-এ রাখুন।

দ্বিতীয়ত, client থেকে আসা header-এর যেকোনো copy proxy-কে মুছে ফেলতে হবে। ফলে authentication-এর পরে proxy যে value set করে, অ্যাপটি কেবল সেটিই দেখতে পাবে।

দুটিই পরীক্ষা করুন। প্রথম command-টি আপনার VPS-এর বাইরের একটি machine থেকে চালান। দ্বিতীয়টি server-এ চালান।

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

curl সংযোগ করতে ব্যর্থ হওয়া উচিত। আর ss-এর output হওয়া উচিত 127.0.0.1:8000, 0.0.0.0:8000 নয়। প্রথম line যদি HTTP/1.1 302 Found হয়, তাহলে অ্যাপটি সরাসরি public internet-এ response দিচ্ছে। সেক্ষেত্রে header-এ যেকোনো user-এর নাম দিয়ে যে কেউ সেই user হিসেবে sign in করতে পারে।

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

আমি যে ক্রমে চারটি বিকল্প চেষ্টা করব:

1. OIDC সমর্থন করে এমন অ্যাপ বেছে নিন। দুটি প্রকল্প একই কাজ করলে এবং একটি বিনামূল্যে আপনার identity provider-এর সঙ্গে সংযোগ করতে পারলে, পরিচালন ব্যয়ের দিক থেকে এটি একটি বাস্তব পার্থক্য।
2. Forward auth সঠিকভাবে ব্যবহার করুন। একটি account ও একজন operator-সহ admin tool-এর জন্য সামনে একটি proxy যথেষ্ট; অ্যাপের ভেতরে per-user identity যোগ করলে কোনো সুবিধা হয় না।
3. মূল্য পরিশোধ করুন। অ্যাপটি আপনার কাজের কেন্দ্রে থাকলে এবং per-seat মূল্য আপনার team size-এর সঙ্গে সামঞ্জস্যপূর্ণ হলে, সেই অর্থ প্রকল্পটির রক্ষণাবেক্ষণ চালিয়ে যেতে সহায়তা করে। অন্যথায় খরচটি আপনাকে নিজের অবসর সময়ে বহন করতে হবে।
4. Issue tracker খুঁজে দেখার পর upstream-এ অনুরোধ জানান। Vaultwarden-এর OIDC support একজন contributor-এর fork এবং দীর্ঘদিন চলা pull request-এর মাধ্যমে এসেছে। তাই কার্যকর implementation-সহ feature request কখনো কখনো free edition-এ যুক্ত হয়।

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

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

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

উভয় ঘটনাকে উদ্দেশ্য নয়, প্রক্রিয়ার প্রমাণ হিসেবে দেখুন। আপনি আজ যে লাইসেন্স পড়ছেন, তা আজ যে version install করছেন তার ক্ষেত্রে প্রযোজ্য। কোনো project তার সব copyright-এর মালিক হলে, সেটি নিজের সিদ্ধান্তে পরবর্তী release-এর শর্ত পরিবর্তন করতে পারে। তাই CLA-সংক্রান্ত প্রশ্নটি চেকলিস্টে রাখা হয়েছে। বিস্তৃত copyright assignment-ই একতরফাভাবে relicence করার সম্ভাবনা তৈরি করে।

কোনো project-এর ওপর নির্ভর করে কাজ শুরু করার আগে নিজে তার ইতিহাস পরীক্ষা করুন।

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

প্রথম import থেকে নেওয়া, বেশিরভাগ commit-সম্বলিত একটি সংক্ষিপ্ত তালিকা ভালো লক্ষণ। licence file একাধিকবার rewrite করা হলে বর্তমান শর্তের ভিত্তিতে পরিকল্পনা করার আগে প্রতিটি commit message পড়ুন।

FAQ

SSO tax কী?

SSO tax হলো এমন একটি পদ্ধতি, যেখানে single sign-on-কে premium feature হিসেবে বিক্রি করা হয়, কিন্তু product-এর বাকি অংশ বিনামূল্যে বা কম দামে পাওয়া যায়। self-hosted software-এ এর অর্থ হলো এমন একটি open source application, যা licence key ছাড়াই চালানো যায়, কিন্তু OIDC বা SAML ব্যবহারের জন্য paid tier প্রয়োজন। নামটি এসেছে sso.tax-এর SSO Wall of Shame থেকে, যেখানে এর জন্য বড় অঙ্কের অতিরিক্ত মূল্য নেওয়া vendor-দের তালিকা রাখা হয়। self-hoster-এর জন্য এর ফল হলো, প্রতিটি app নিজস্ব user database চালিয়ে যায়। তাই account হাতে তৈরি ও মুছে ফেলতে হয়।

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

না। Forward auth প্রবেশদ্বার সুরক্ষিত করে। আপনার proxy কোনো request app-এ পৌঁছানোর আগে identity provider-এর সঙ্গে যাচাই করে। এর পেছনের app তখনও নিজস্ব account ব্যবহার করে। তাই সবাই যদি একটি shared login-এ যায়, তাহলে একটি anonymous session তৈরি হয় এবং audit log-এ একটি মাত্র নাম দেখা যায়। app header থেকে username পড়লে তবেই প্রকৃত per-user identity তৈরি হয়। Grafana-এর auth proxy, Gitea-এর reverse proxy authentication এবং Paperless-ngx-এর PAPERLESS_ENABLE_HTTP_REMOTE_USER এটি করতে পারে। এই settings তখনই নিরাপদ, যখন proxy ছাড়া app-এ পৌঁছানো যায় না। কারণ header-টি সাধারণ একটি string, যা যেকোনো client পাঠাতে পারে।

কোন self-hosted app বিনামূল্যের edition-এ OIDC অন্তর্ভুক্ত করে?

August 2026-এ project documentation যাচাই করে দেখা গেছে: Paperless-ngx, Planka, BookStack, Gitea, listmonk এবং Vaultwarden—সবগুলোই তাদের free build-এ OIDC সমর্থন করে। GitLab Self-Managed-এ Tier: Free-এর অধীনে SAML তালিকাভুক্ত আছে। Grafana-এর open source build আপনার নিজস্ব issuer-এর বিরুদ্ধে generic OAuth পরিচালনা করে। সেখানে SAML একটি Enterprise feature। install করার আগে project-এর নিজস্ব authentication page-এ নিশ্চিত হন, কারণ release-এর সঙ্গে এই তালিকা পরিবর্তিত হয়।

single sign-on চালু করে এমন tier-এর জন্য কি অর্থ দেওয়া উচিত?

দুটি সংখ্যা দিয়ে সিদ্ধান্ত নিন: কতজনের account প্রয়োজন এবং অন্যথায় কতগুলো app আপনাকে হাতে পরিচালনা করতে হবে। এক বা দুইজন administrator-এর ক্ষেত্রে local account-এর সামনে forward auth যথেষ্ট। তাই paid tier থেকে খুব বেশি সুবিধা পাওয়া যায় না। এমন একটি team-এ, যেখানে মানুষ যোগ দেয় এবং চলে যায়, offboarding-এর সময় একটি account বাদ পড়ার খরচ licence-এর চেয়ে বেশি হতে পারে। আপনি যে maintenance-এর ওপর নির্ভর করছেন, সেই অর্থও payment-এর মাধ্যমে দেওয়া হয়। মূল্যসীমা উপযোগী না হলে, OIDC-সহ একটি app বেছে নেওয়াই বাস্তবসম্মত। OIDC সমর্থন করে না এমন app-কে workaround দিয়ে চালানোর চেষ্টা করবেন না।