SSD Nodes Learn Hosting plans →
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-08-30

Self-hosted software मधील SSO कर म्हणजे काय?

Open source अॅपमध्ये OIDC आणि SAML paid tier मध्ये का ठेवले जातात? Maintainer चे कारण, SSO कराचा परिणाम आणि install करण्यापूर्वीची checklist जाणून घ्या.

SSO कर काय आहे

self-hosted software मधील SSO कर म्हणजे असा नमुना, ज्यात अॅप्लिकेशन विनामूल्य असते; परंतु single sign-on (SSO) हे एकमेव वैशिष्ट्य खरेदी करावे लागते. तुम्ही संपूर्ण सॉफ्टवेअर तुमच्या स्वतःच्या VPS वर licence key किंवा seat count शिवाय चालवू शकता. त्यानंतर documentation मधील authentication पृष्ठ उघडल्यावर OpenID Connect (OIDC) किंवा SAML (security assertion markup language) हे paid plan अंतर्गत असल्याचे दिसते.

हे सामान्यपणे शुल्क लावलेल्या एखाद्या वैशिष्ट्यापेक्षा अधिक महत्त्वाचे आहे, कारण SSO मुळे self-hosted सेवांचा समूह एका प्रणालीप्रमाणे कार्य करतो. identity provider (IdP) प्रत्येक व्यक्तीसाठी एक account, एक password policy, multi-factor authentication (MFA) सुरू करण्यासाठी एक ठिकाण आणि एखाद्याचा access बंद करण्यासाठी एक ठिकाण उपलब्ध करून देतो. IdP नसल्यास प्रत्येक अॅप स्वतःचा छोटा user database ठेवते आणि तुम्हाला प्रत्येक database स्वतंत्रपणे हाताळावा लागतो.

हा नमुना इतका जुना आहे की त्यासाठी सार्वजनिक यादी उपलब्ध आहे. sso.tax वरील SSO Wall of Shame मध्ये single sign-on साठी मोठा अतिरिक्त शुल्क आकारणाऱ्या vendors ची यादी आहे. त्यातील नोंदी 2018 पासूनच्या आहेत. त्याचा लेखक एक वाजवी निकष सांगतो: "तुमच्या SSO support मुळे किंमत 10% वाढत असेल, तर तुमचे नाव या यादीत नाही." या यादीतील बहुतेक software closed software आहे. आता स्वतः host केलेल्या open source projects मध्येही हीच pricing logic दिसू लागली आहे.

देखभाल करणारे SSO सशुल्क स्तरामागे का ठेवतात

यामागे दोन कारणे आहेत आणि दोन्ही प्रामाणिक आहेत. SSO साठी समर्थन देणे खर्चिक असते. तसेच मोठी संस्था ज्या मोजक्या सुविधांसाठी पैसे देईल, त्यापैकी ही एक आहे.

समर्थनाचा खर्च खरा आहे, कारण identity integration कधीही पूर्ण होत नाही. प्रत्येक IdP claims चे स्वरूप थोडे वेगळे ठेवतो. Group mapping, session lifetime, redirect URLs आणि clock skew यांपैकी प्रत्येकामुळे login bugs निर्माण होऊ शकतात. Login bug मुळे सर्व वापरकर्ते एकाच वेळी प्रवेशाबाहेर होतात. त्यामुळे अशी support tickets तातडीची असतात. त्यानंतर पुढील विनंत्या येतात: nested groups, role mapping, SCIM (system for cross-domain identity management) वापरून automatic provisioning आणि compliance team तपासणार असलेले audit logs.

महसुलाचा मुद्दा दुष्ट हेतूचा नसून सरळ गणिताचा आहे. एखादी कंपनी अॅपला स्वतःच्या IdP शी जोडू शकत नसेल, तर ती अॅप deploy करणारच नाही. त्यामुळे SSO मुळे पैसे देणारा वापरकर्ता आणि पैसे न देणारा वापरकर्ता यांच्यात स्पष्ट सीमा आखता येते. Open core प्रकल्पाला ही सीमा कुठेतरी आखावीच लागते. जवळजवळ इतर कोणत्याही सुविधेपेक्षा SSO या सीमेसाठी अधिक योग्य ठरते. म्हणूनच अनेक प्रकल्प ते निवडतात.

नेहमीच्या तक्रारीबाबत एक दुरुस्ती: एखादी सुविधा काढून घेतली असे गृहीत धरण्यापूर्वी changelog तपासा, कारण सुविधा काढल्याची नोंद release notes मध्ये दिसते. या लेखासाठी मी तपासलेल्या प्रकल्पांमध्ये paid SSO features सुरुवातीपासूनच paid tier साठी तयार करण्यात आली होती. कार्यरत free SSO नंतर काढून घेतल्याचे एकही उदाहरण मला आढळले नाही. Grafana याचे नेहमीचे उदाहरण आहे. त्याच्या SAML पृष्ठावर एक ओळीची नोंद आहे, "Available in Grafana Enterprise and Grafana Cloud". मात्र स्वतःच्या issuer विरुद्ध generic OAuth open source build मध्ये कार्यरत असते.

SSO च्या अतिरिक्त खर्चाची वास्तविक किंमत

पैशांचा खर्च हा यातील लहान भाग आहे. सशुल्क स्तराची किंमत प्रति वापरकर्ता आकारली जाते. त्यामुळे तुमच्या टीमसोबत बिल वाढते, तर hosting आणि upgrades ची जबाबदारी तुमचीच राहते.

मोठा खर्च manual identity work मुळे होतो. तो चार ठिकाणी दिसून येतो.

  • प्रत्येक अॅपसाठी स्वतंत्र password store ठेवावा लागतो. त्यामुळे एकच password पुन्हा वापरला असल्यास तो password वापरणाऱ्या प्रत्येक अॅपमध्ये सुरक्षा भेद्यता निर्माण होते.
  • Offboarding स्मरणशक्तीवर अवलंबून राहते. एखाद्या व्यक्तीने वापरलेल्या प्रत्येक सेवेची नोंद तुम्हाला लक्षात ठेवावी लागते. आणि जी सेवा विसरली जाते, तीच नंतर महत्त्वाची ठरते.
  • MFA प्रत्येक अॅपमध्ये स्वतंत्रपणे configure करावे लागते. ते अॅप MFA ला support करत असेल तरच.
  • या दबावामुळे छोट्या टीममध्ये प्रत्यक्षात shared logins वापरले जातात.

शेवटच्या मुद्द्यासाठी स्वतंत्रपणे सांगणे आवश्यक आहे. एखादी टीम document manager मध्ये एकच administrator account share करत असेल, तर audit trail मध्ये प्रत्येक कृतीसाठी एकच नाव नोंदवले जाते. त्यामुळे invoice कोणी delete केले हे समजत नाही. Per-user permissions देखील कार्य करत नाहीत, कारण user एकच असतो. SSO च्या अतिरिक्त खर्चामुळे होणारी खरी हानी हीच आहे: तो छोट्या टीमना एकच shared account वापरण्याकडे ढकलतो. हा पर्याय इतर कोणत्याही पर्यायापेक्षा अधिक धोकादायक आहे.

स्वीकारण्यापूर्वी चालवायची तपासणीसूची

docker compose up करण्यापूर्वी ही तपासणी चालवा. अॅपमध्ये 400 दस्तऐवज साठल्यानंतर नाही.

  1. दस्तऐवजांमधील authentication पृष्ठ उघडा आणि वरची tier note वाचा. Paid features साठी badge किंवा उपलब्धतेबाबत एक ओळीचे विधान दिलेले असते.
  2. अॅप तुमच्या स्वतःच्या issuer शी OIDC किंवा SAML द्वारे संवाद साधते का ते तपासा. ते सार्वजनिक providers च्या fixed list शी जोडलेले नसावे.
  3. role आणि group mapping तपासा. user तयार करणे हे कामाचे अर्धेच पाऊल आहे. दहा अॅप्समध्ये permissions manually देणे हे त्रासदायक अर्धे पाऊल आहे.
  4. trusted proxy कडून header मध्ये authenticated username अॅप स्वीकारते का ते तपासा. तसेच ते कोणत्या proxy वर विश्वास ठेवते हे निश्चित करता येते का ते पाहा.
  5. git मधील licence history वाचा. contributors CLA (contributor licence agreement) वर स्वाक्षरी करतात का ते तपासा.
  6. offboarding तपासा. IdP account disable केल्यावर API (application programming interface) tokens आणि live sessions यांचे काय होते ते शोधा.

बहुतेक निराशा Item 2 मध्ये होते. "Sign in with Google" button म्हणजे तुमच्या identity provider सोबत OIDC नाही. ते एका vendor सोबतचे fixed integration आहे. वास्तविक support साठी issuer URL द्यावा लागतो. त्यानंतरची सर्व माहिती discovery मधून मिळते. एका command ने तुमच्या provider च्या बाजूची ही रचना पडताळता येते.

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

यशस्वी provider कडून तीन URLs परत येतात. रिकामा result किंवा 404 आल्यास discovery path चुकीचा असतो. हा path provider नुसार बदलतो: Keycloak तो /realms/<realm>/.well-known/openid-configuration अंतर्गत प्रकाशित करते. अॅपमध्ये issuer URL साठी कोणतेही field नसेल, तर feature list मध्ये काहीही लिहिलेले असले तरी ते तुमच्या IdP शी संवाद साधू शकत नाही.

एखादी व्यक्ती संस्था सोडल्यानंतर काही आठवड्यांनी Item 6 मुळे समस्या लक्षात येते. IdP मध्ये account disable केल्याने नवीन logins थांबतात. मात्र अॅपने आधी issue केलेला API token revoke होत नाही. कारण अॅप त्या token चे validation स्वतः करते आणि त्याबाबत IdP ला कधीही विचारत नाही. त्यामुळे offboarding साठी दोन पावले आवश्यक आहेत: IdP मध्ये account disable करा आणि नंतर प्रत्येक अॅपमध्ये user किंवा त्याचे tokens delete करा.

टियर बॅज प्रत्यक्षात काय सांगतात

ऑगस्ट 2026 मध्ये प्रत्येक प्रकल्पाच्या स्वतःच्या दस्तऐवजीकरणाच्या आधारे ही माहिती पडताळली आहे. प्रथम सशुल्क बाजू पाहूया.

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 मार्फत लॉग इन करू शकतो. संपूर्ण single sign-on ऐवजी SAML पासून सशुल्क स्तर सुरू होतो. "SSO tax" या वाक्यप्रचारात ही सूक्ष्म बाब सहसा स्पष्ट होत नाही.

Metabase याबाबत अधिक स्पष्ट आहे. त्याच्या दस्तऐवजीकरणात असे म्हटले आहे: "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 दस्तऐवजीकरणाला Pro आणि Cloud असे चिन्हांकित केले आहे. त्यामुळे community edition मध्ये ही सुविधा नाही. दस्तऐवजीकरणात नमूद केलेल्या providers मध्ये Keycloak आणि Entra ID यांचा समावेश आहे.

n8n मध्येही अशीच रचना आहे. self-hosted community edition fair-code licence अंतर्गत विनामूल्य आहे; परंतु SAML आणि LDAP login enterprise key मागे ठेवले आहेत. विनामूल्य n8n edition मध्ये उपलब्ध नसलेल्या इतर सुविधांच्या मोठ्या यादीतील ही एक नोंद आहे.

आता दुसरी बाजू पाहूया, कारण ही पद्धत सर्वत्र लागू होत नाही.

  • GitLab Self-Managed च्या SAML पृष्ठावर "Tier: Free, Premium, Ultimate" असे नमूद आहे. त्यामुळे आपल्या स्वतःच्या GitLab विरुद्ध SAML वापरण्यासाठी शुल्क लागत नाही.
  • Paperless-ngx मध्ये django-allauth द्वारे OIDC configure करण्यासाठी PAPERLESS_SOCIALACCOUNT_PROVIDERS वापरले जाते, PAPERLESS_DISABLE_REGULAR_LOGIN द्वारे स्थानिक login form लपवता येतो आणि PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS द्वारे claims चे groups मध्ये mapping करता येते.
  • Planka मध्ये OIDC_ISSUER, OIDC_CLIENT_ID आणि OIDC_CLIENT_SECRET स्वीकारले जातात. त्याचे scopes डीफॉल्टने openid profile email असतात आणि OIDC_ADMIN_ROLES मधील role claim द्वारे administrators ना administrator भूमिका दिली जाते.
  • BookStack मध्ये AUTH_METHOD=oidc द्वारे provider बदलता येतो. त्यानंतर OIDC_USER_TO_GROUPS=true आणि OIDC_GROUPS_CLAIM द्वारे provider groups चे स्वतःच्या roles मध्ये mapping केले जाते.
  • Vaultwarden मध्ये 27 December 2025 रोजी प्रसिद्ध झालेल्या 1.35.0 आवृत्तीत "support for SSO with OpenID Connect" समाविष्ट करण्यात आले. ही सुविधा एका contributor ने fork मध्ये आधीपासून राखली होती आणि त्याच्या pull request मधून ती समाविष्ट झाली.
  • listmonk मध्ये v4.0.0 पासून user roles सोबत OIDC login उपलब्ध आहे.

तुम्ही निवड करताना ही माहिती वापरा; निवड निश्चित केल्यानंतर नाही. Planka kanban board आणि इतर self-hosted Trello alternatives identity बाबत एकसारखी वागणूक देत नाहीत. BookStack, Wiki.js आणि Outline यांच्यातही फरक आहे. विनामूल्य OIDC कडे storage limits किंवा mobile clients प्रमाणेच विचारात घेता येणारी सुविधा म्हणून पाहता येते. तुम्ही अद्याप यादी तयार करत असाल, तर 2026 मध्ये काय self-host करावे हा योग्य प्रारंभबिंदू आहे. तसेच Paperless-ngx document manager आणि Vaultwarden दोन्हीमध्ये आज विनामूल्य OIDC उपलब्ध आहे.

अॅपच्या पुढे reverse proxy ठेवणे हे single sign-on का नाही

सामान्य उपाय म्हणजे forward auth. reverse proxy प्रत्येक विनंती थांबवतो, हा browser authentication service मध्ये 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 names चे Capitalisation महत्त्वाचे असते, कारण name जुळला नाही तर तो रिकामा पोहोचतो. ती विनंती मंजूर करताना outpost X-authentik-username, X-authentik-email, X-authentik-groups आणि आणखी काही headers सेट करतो.

यातून काय मिळते ते पाहू. प्रथम identity provider मधून पडताळणी न करता कोणीही अॅपपर्यंत पोहोचू शकत नाही. त्यामुळे unpatched login form आता इंटरनेटवर उघडा राहत नाही. तसेच proxy मागील सर्व अॅप्सवर MFA एकाच वेळी लागू होते.

यातून काय मिळत नाही ते म्हणजे अॅपमधील identity. अॅपमध्ये अजूनही स्वतःची accounts आणि कोण sign in आहे याबद्दलची स्वतःची संकल्पना असते. प्रत्येक जण proxy पार करून एका shared administrator account मध्ये पोहोचत असेल, तर तुमच्याकडे मजबूत front door आणि त्यामागे एक anonymous session असते. Audit log मध्ये अजूनही एकच name दिसतो. लोकांनुसार permissions वेगळ्या ठेवता येत नाहीत. या रचनेला SSO म्हणणे ही security mistake आहे. कारण offboarding ची प्रक्रिया केवळ अंशतःच कार्य करते: तुमच्या IdP मधून व्यक्ती काढल्यास front door बंद होते, परंतु त्या व्यक्तीने अॅपमध्ये तयार केलेला API token अॅपपर्यंत थेट पोहोचू शकणाऱ्या कोणासाठीही कार्यरत राहतो.

Header authentication सुरक्षित करणे

काही अॅप्स proxy कडून username स्वीकारतात. त्यामुळे सशुल्क SSO शिवाय प्रत्येक वापरकर्त्याची ओळख मिळते. प्रत्येक प्रोजेक्टमध्ये या setting चे नाव वेगळे असते.

Grafana मध्ये याला auth proxy म्हणतात आणि ते default ने disabled असते. Header चे नाव default ने X-WEBAUTH-USER असते. तुमचा proxy ज्या header मध्ये मूल्य ठेवतो, तो header वापरण्यासाठी तुम्ही ते बदलू शकता.

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

whitelist ही अशी line आहे जी लोक वगळतात. Header ची बनावट value देऊन वापरकर्ता spoofing करू नये, यासाठी ती आहे, असे Grafana च्या documentation मध्ये स्पष्ट सांगितले आहे. त्यामुळे त्यात तुमच्या proxy चा address आणि केवळ तोच असावा. Gitea मध्येही हेच feature वेगवेगळ्या नावांनी उपलब्ध आहे आणि त्याचा default अधिक सुरक्षित आहे.

[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 असते. Chain मध्ये Gitea किती proxy वर विश्वास ठेवेल, हे REVERSE_PROXY_LIMIT ठरवते. ही मर्यादा zero वर सेट केल्यास header handling पूर्णपणे बंद होते.

Paperless-ngx मध्ये PAPERLESS_ENABLE_HTTP_REMOTE_USER हे PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME सह उपलब्ध आहे. या सर्व settings साठी लागू होणारी warning त्याच्या documentation मध्ये स्पष्टपणे दिली आहे:

Request मध्ये Remote-User: <username> header जोडून authentication करता येईल. काळजीपूर्वक वापरा!

Header authentication सुरक्षित ठेवण्यासाठी दोन नियम पाळा. दोन्ही नियम reachability शी संबंधित आहेत. पहिला, proxy शिवाय अॅपपर्यंत पोहोचता कामा नये. अॅपशी socket उघडू शकणारा कोणताही वापरकर्ता हा header पाठवून कोणत्याही user म्हणून प्रवेश करू शकतो. 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 ने delete केली पाहिजे. त्यामुळे authentication नंतर proxy ने set केलेली value एवढीच app ला दिसेल.

दोन्ही बाबी तपासा. पहिली command तुमच्या VPS च्या बाहेरील machine वरून चालवा आणि दुसरी server वरच चालवा.

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

curl ला connect होता कामा नये. तसेच ss ने 0.0.0.0:8000 ऐवजी 127.0.0.1:8000 print केले पाहिजे. पहिली line HTTP/1.1 302 Found असल्यास app थेट public internet ला उत्तर देत आहे. अशा स्थितीत header मध्ये user चे नाव देऊन कोणताही वापरकर्ता कोणत्याही user म्हणून sign in करू शकतो.

मुक्त SSO उपलब्ध नसेल, तर तक्रार करण्याऐवजी निर्णय घ्या

मी खालील चार पर्याय याच क्रमाने वापरेन.

  1. OIDC समाविष्ट असलेले अॅप निवडा. दोन प्रकल्प समान काम करत असतील आणि त्यांपैकी एक तुमच्या identity provider शी विनामूल्य संवाद साधत असेल, तर चालवण्याच्या खर्चाच्या दृष्टीने हा वास्तविक फरक आहे.
  2. forward auth प्रामाणिकपणे वापरा. एका खात्याचे आणि एका ऑपरेटरचे admin tool असल्यास, त्याच्या पुढे ठेवलेला proxy पुरेसा असतो. अॅपमध्ये प्रत्येक वापरकर्त्याची identity ठेवण्याने कोणताही अतिरिक्त लाभ मिळत नाही.
  3. पैसे द्या. अॅप तुमच्या कामासाठी मध्यवर्ती असेल आणि per-seat किंमत तुमच्या टीमच्या आकाराला परवडत असेल, तर त्या पैशामुळे प्रकल्पाची देखभाल सुरू राहते. अन्यथा तो खर्च तुमच्या मोकळ्या वेळेत करावा लागतो.
  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 यांची तुलना विविध पर्यायांमधील तडजोडी स्पष्ट करते.

परवान्याचा इतिहास आणि तो तपासणी यादीत का आहे

शेवटचा तपासणी यादीतील मुद्दा भविष्यासंदर्भात आहे, कारण आजची tier रचना ही फक्त एका क्षणाचे चित्र आहे. दोन चांगल्या प्रकारे दस्तऐवजीकरण केलेली उदाहरणे परिस्थिती दोन्ही दिशांनी किती वेगाने बदलते हे दाखवतात. HashiCorp ने 10 August 2023 रोजी भविष्यातील सर्व releases साठी Business Source License 1.1 स्वीकारला; त्यापूर्वीचे releases 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) अंतर्गतही उपलब्ध होईल, अशी घोषणा केली.

याकडे हेतूऐवजी कार्यपद्धतीच्या पुराव्याप्रमाणे पाहा. तुम्ही आज वाचत असलेला परवाना तुम्ही आज install करत असलेल्या version ला लागू होतो. एखाद्या प्रकल्पाकडे त्याच्या सर्व copyright चे मालकीहक्क असल्यास, तो पुढील release च्या अटी स्वतःहून बदलू शकतो. म्हणून CLA चा प्रश्न तपासणी यादीत आहे. व्यापक copyright assignment मुळे एकतर्फी relicence करणे शक्य होते.

एखाद्या प्रकल्पावर आधारित काम सुरू करण्यापूर्वी त्याचा इतिहास स्वतः तपासा.

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

बहुतेक वेळा पहिल्या import मधील commits ची छोटी यादी असणे हे चांगले लक्षण आहे. Licence file मध्ये अनेकदा rewrite झालेले असल्यास, सध्याच्या अटींवर आधारित नियोजन करण्यापूर्वी प्रत्येक commit message वाचा.

FAQ

SSO कर म्हणजे काय?

SSO कर म्हणजे single sign-on साठी premium feature म्हणून शुल्क आकारण्याची पद्धत. उत्पादनाचा उर्वरित भाग free किंवा स्वस्त असतो. Self-hosted software मध्ये हे असे दिसते: licence key शिवाय चालवता येणारे open source application असते, पण OIDC किंवा SAML login paid tier मध्ये उपलब्ध असतो. हे नाव sso.tax वरील SSO Wall of Shame वरून आले आहे. या संकेतस्थळावर त्यासाठी मोठे premium आकारणाऱ्या vendors ची नोंद ठेवली जाते. Self-hoster साठी याचा परिणाम असा होतो की प्रत्येक app स्वतःचा user database ठेवतो. त्यामुळे accounts हाताने तयार आणि काढावे लागतात.

Forward auth असलेला reverse proxy म्हणजे SSOच आहे का?

नाही. Forward auth प्रवेशद्वाराचे संरक्षण करते. कोणतीही request app पर्यंत पोहोचण्यापूर्वी तुमचा proxy identity provider कडे पडताळणी करतो. त्यामागील app स्वतःची accounts वापरत राहतो. त्यामुळे सर्वजण एका shared login वर गेल्यास एकच anonymous session तयार होते आणि audit log मध्ये एकच नाव दिसते. App header मधून username वाचू लागल्यावरच प्रत्येक user ची खरी identity उपलब्ध होते. Grafana's auth proxy, Gitea's reverse proxy authentication आणि Paperless-ngx's PAPERLESS_ENABLE_HTTP_REMOTE_USER हे करू शकतात. App पर्यंत proxy शिवाय पोहोचता येत नसतानाच ही settings सुरक्षित असतात. कारण header हा साधा string असतो आणि कोणताही client तो पाठवू शकतो.

कोणत्या self-hosted apps मध्ये free edition मध्ये OIDC समाविष्ट आहे?

August 2026 मध्ये project documentation तपासल्यानुसार, Paperless-ngx, Planka, BookStack, Gitea, listmonk आणि Vaultwarden या सर्वांच्या free builds मध्ये OIDC support आहे. GitLab Self-Managed मध्ये SAML ची नोंद Tier: Free अंतर्गत आहे. Grafana's open source build तुमच्या स्वतःच्या issuer विरुद्ध generic OAuth हाताळते. मात्र त्यामधील SAML हे Enterprise feature आहे. Install करण्यापूर्वी project च्या स्वतःच्या authentication page वर खात्री करा. कारण releases नुसार या याद्या बदलतात.

Single sign-on unlock करणाऱ्या tier साठी पैसे द्यावेत का?

दोन संख्यांच्या आधारे निर्णय घ्या: किती लोकांना accounts आवश्यक आहेत आणि अन्यथा किती apps तुम्हाला हाताने manage करावे लागतील. एक किंवा दोन administrators साठी local account च्या पुढे forward auth पुरेसे असते. अशा वेळी paid tier मुळे फारसा लाभ मिळत नाही. लोक team मध्ये येत-जात असतील, तर offboarding वेळी एखादे account काढायचे राहणे licence पेक्षा महाग ठरू शकते. अशा वेळी तुम्ही ज्या maintenance वर अवलंबून आहात त्यासाठी payment केला जातो. किंमत परवडत नसेल, तर OIDC समाविष्ट असलेले app निवडणे हा व्यावहारिक पर्याय आहे. OIDC नसलेल्या app भोवती workaround तयार करण्यापेक्षा हा पर्याय चांगला आहे.

#sso#oidc#saml#licensing#self-hosting#authentik