Self-hosted மென்பொருட்களில் SSO வரி என்றால் என்ன?

SSO வரி என்றால் என்ன

Self-hosted மென்பொருட்களில் SSO வரி என்பது, மென்பொருள் இலவசமாகக் கிடைப்பதும், ஆனால் Single Sign-On (SSO) வசதிக்கு மட்டும் பணம் செலுத்த வேண்டிய கட்டாயமும் கொண்ட ஒரு நடைமுறையாகும். நீங்கள் எந்தவிதமான licence key அல்லது seat count கட்டுப்பாடும் இன்றி, உங்கள் சொந்த VPS-ல் முழு மென்பொருளையும் இயக்க முடியும். ஆனால், ஆவணங்களில் (documentation) உள்ள authentication பக்கத்திற்குச் செல்லும்போது, OpenID Connect (OIDC) அல்லது SAML (security assertion markup language) போன்ற வசதிகள் கட்டணத் திட்டத்தின் கீழ் இருப்பதை நீங்கள் காண்பீர்கள்.

இது சாதாரணமான ஒரு கட்டண வசதியை விட முக்கியமானது. ஏனெனில், பல self-hosted சேவைகளை ஒரே அமைப்பாகச் செயல்பட வைப்பது SSO தான். ஒரு Identity Provider (IdP) மூலம் ஒவ்வொரு நபருக்கும் ஒரு கணக்கு, ஒரு கடவுச்சொல் கொள்கை (password policy), Multi-Factor Authentication (MFA)-ஐ செயல்படுத்த ஒரு இடம் மற்றும் ஒருவரை நீக்குவதற்கு ஒரே ஒரு இடம் என அனைத்தையும் நிர்வகிக்க முடியும். இது இல்லையென்றால், ஒவ்வொரு செயலியும் தனக்கென ஒரு பயனர் தரவுத்தளத்தை வைத்திருக்கும், நீங்கள் ஒவ்வொன்றையும் தனித்தனியாகக் கையால் நிர்வகிக்க வேண்டியிருக்கும்.

இந்த நடைமுறை நீண்ட காலமாக இருப்பதால், இதற்கென ஒரு பொதுவான தரவரிசைப் பட்டியல் உள்ளது. sso.tax-ல் உள்ள 'SSO Wall of Shame', SSO வசதிக்காக அதிக கட்டணம் வசூலிக்கும் விற்பனையாளர்களைப் பட்டியலிடுகிறது. 2018 முதல் இதற்கான பதிவுகள் உள்ளன. இதன் ஆசிரியர் ஒரு நியாயமான அளவுகோலை வைத்துள்ளார்: "உங்கள் SSO ஆதரவுக்காக 10% கூடுதல் கட்டணம் வசூலித்தால், நீங்கள் இந்தப் பட்டியலில் இருக்க மாட்டீர்கள்." அந்தப் பட்டியலில் உள்ள பெரும்பாலானவை closed software-கள் ஆகும். அதே விலை நிர்ணய தர்க்கம் இப்போது நீங்கள் நீங்களே host செய்யும் open source திட்டங்களிலும் காணப்படுகிறது.

ஏன் பராமரிப்பாளர்கள் single sign-on வசதியை கட்டணத் திட்டத்தில் வைக்கிறார்கள்

இதற்கு இரண்டு காரணங்கள் உள்ளன, இரண்டுமே உண்மையானவை. SSO-வை பராமரிப்பது செலவு மிக்கது, மேலும் பெரிய நிறுவனங்கள் பணம் செலுத்திப் பெறக்கூடிய மிகச் சில அம்சங்களில் இதுவும் ஒன்று.

அடையாள ஒருங்கிணைப்பு (identity integration) என்பது ஒருபோதும் முடிவடையாத ஒன்று என்பதால், இதற்கான பராமரிப்புச் செலவு உண்மையானது. ஒவ்வொரு IdP-ம் அதன் claims-ஐச் சற்று வித்தியாசமாக வடிவமைக்கும். Group mapping, session lifetime, redirect URLs மற்றும் clock skew ஆகிய ஒவ்வொன்றும் login பிழைகளை உருவாக்குகின்றன. ஒரு login பிழை அனைத்து பயனர்களையும் ஒரே நேரத்தில் வெளியேற்றிவிடும் என்பதால், அந்த tickets மிக அவசரமானவை. அதன் பிறகு, nested groups, role mapping, SCIM (system for cross-domain identity management) மூலம் தானியங்கி provisioning மற்றும் compliance குழுவினர் ஆய்வு செய்யும் audit logs போன்ற கூடுதல் கோரிக்கைகள் வருகின்றன.

வருவாய் பக்கம் என்பது தீய எண்ணம் கொண்டதல்ல, அது ஒரு கணக்கீடு மட்டுமே. ஒரு நிறுவனத்தால் தனது சொந்த IdP-உடன் அந்த application-ஐ இணைக்க முடியவில்லை என்றால், அவர்கள் அதை பயன்படுத்தவே மாட்டார்கள். எனவே, பணம் செலுத்தும் பயனருக்கும் செலுத்தாத பயனருக்கும் இடையே SSO ஒரு தெளிவான கோட்டை வகுக்கிறது. ஒரு open core project அந்த கோட்டை எங்காவது ஒரு இடத்தில் வைக்க வேண்டும். மற்ற எந்த அம்சத்தை விடவும் SSO அந்த இடத்தில் சரியாகப் பொருந்துவதால், பல திட்டங்கள் இதைத் தேர்ந்தெடுக்கின்றன.

பொதுவான புகாரில் ஒரு திருத்தம்: ஒரு அம்சம் நீக்கப்பட்டுவிட்டது என்று கருதும் முன் changelog-ஐச் சரிபார்க்கவும், ஏனெனில் ஒரு நீக்கம் release notes-ல் காட்டப்படும். இந்தப் பதிவிற்காக நான் சரிபார்த்த திட்டங்களில், கட்டண SSO அம்சங்கள் ஆரம்பத்திலிருந்தே கட்டணத் திட்டத்திற்காகவே உருவாக்கப்பட்டவை. இலவசமாகச் செயல்பட்டு வந்த SSO நீக்கப்பட்ட எந்த ஒரு நிகழ்வையும் நான் காணவில்லை. Grafana இதற்கு ஒரு சிறந்த உதாரணம். அதன் SAML பக்கத்தில் "Available in Grafana Enterprise and Grafana Cloud" என்ற ஒரு வரி குறிப்பு உள்ளது, அதே சமயம் உங்கள் சொந்த issuer-க்கு எதிரான பொதுவான OAuth, open source build-ல் வேலை செய்கிறது.

SSO வரியினால் உங்களுக்கு ஏற்படும் உண்மையான இழப்பு

பணம் என்பது இதில் சிறிய பாதிப்பு மட்டுமே. கட்டணத் திட்டங்கள் (paid tiers) பயனர் எண்ணிக்கையின் அடிப்படையில் விற்கப்படுகின்றன. எனவே, ஹோஸ்டிங் மற்றும் மேம்படுத்தல்களை (upgrades) நீங்களே கவனித்துக்கொள்ளும் சூழலில், உங்கள் குழு வளர வளர கட்டணமும் அதிகரிக்கிறது.

இதன் பெரிய இழப்பு என்பது கையேடு அடையாள மேலாண்மை (manual identity work) ஆகும். இது நான்கு இடங்களில் பாதிப்பை ஏற்படுத்துகிறது.

• ஒவ்வொரு செயலிக்கும் ஒரு கடவுச்சொல் சேமிப்பகம் (password store) தேவைப்படுகிறது. இதனால், மீண்டும் பயன்படுத்தப்படும் ஒரு கடவுச்சொல், அதைப் பகிரும் அனைத்து செயலிகளிலும் ஒரு பாதுகாப்பு ஓட்டையை உருவாக்குகிறது.
• பணியாளர் வெளியேறும்போது (offboarding) நினைவாற்றலைச் சார்ந்திருத்தல். ஒரு நபர் எந்தெந்த சேவைகளைப் பயன்படுத்தினார் என்பதை நீங்கள் நினைவில் வைத்திருக்க வேண்டும். நீங்கள் மறந்துவிடும் ஒரு சேவைதான் மிக முக்கியமானதாக இருக்கும்.
• ஒவ்வொரு செயலியிலும் தனித்தனியாக MFA-வை உள்ளமைத்தல் (அச்செயலி அதை ஆதரிக்கும் பட்சத்தில்).
• பகிரப்பட்ட உள்நுழைவுகள் (shared logins). இந்த அழுத்தத்தின் கீழ் சிறிய குழுக்களில் உண்மையில் நடப்பது இதுதான்.

கடைசிப் புள்ளிக்குத் தனியாக ஒரு விளக்கம் தேவை. ஒரு ஆவண மேலாண்மைச் செயலியில் ஒரு குழு ஒரே நிர்வாகி கணக்கைப் பகிரும்போது, தணிக்கைப் பாதை (audit trail) அனைத்திற்கும் ஒரே பெயரைப் பதிவு செய்கிறது. இதனால், விலைப்பட்டியலை (invoice) நீக்கியது யார் என்று உங்களால் கண்டறிய முடியாது. ஒரே ஒரு பயனர் மட்டுமே இருப்பதால், பயனர் வாரியான அனுமதிகளும் (per-user permissions) வேலை செய்யாது. இதுவே SSO வரியினால் ஏற்படும் உண்மையான பாதிப்பு: இது சிறிய குழுக்களை ஒரே பகிரப்பட்ட கணக்கைப் பயன்படுத்தத் தூண்டுகிறது. இது மற்ற அனைத்து மாற்றுகளை விடவும் மோசமானது.

எந்தவொரு மென்பொருளையும் பயன்படுத்துவதற்கு முன் சரிபார்க்க வேண்டியவை

இதை docker compose up-க்கு முன்பே செய்துவிடவும்; பயன்பாட்டில் 400 ஆவணங்கள் சேர்ந்த பிறகு செய்வது கடினம்.

1. ஆவணங்களில் உள்ள authentication பக்கத்தைத் திறந்து, மேலே உள்ள tier குறிப்பைப் படிக்கவும். கட்டண வசதிகள் ஒரு badge அல்லது ஒரு வரி விளக்கத்தைக் கொண்டிருக்கும்.
2. குறிப்பிட்ட பொதுவான providers-க்கு மட்டும் கட்டுப்படாமல், உங்கள் சொந்த issuer-உடன் OIDC அல்லது SAML மூலம் அந்த app இணைகிறதா என்பதை உறுதிப்படுத்தவும்.
3. Role மற்றும் group mapping-ஐச் சரிபார்க்கவும். பயனரை உருவாக்குவது பாதி வேலைதான்; பத்து வெவ்வேறு app-களில் கைமுறையாக அனுமதி (permissions) வழங்குவதுதான் கடினமான பகுதி.
4. நம்பகமான proxy-யிலிருந்து வரும் header-ல் உள்ள authenticated username-ஐ அந்த app ஏற்றுக்கொள்கிறதா என்பதையும், எந்த proxy-யை அது நம்புகிறது என்பதை உங்களால் வரையறுக்க முடியுமா என்பதையும் சரிபார்க்கவும்.
5. Git-ல் உள்ள licence வரலாற்றைப் படித்து, பங்களிப்பாளர்கள் CLA (contributor licence agreement) கையெழுத்திடுகிறார்களா என்று பார்க்கவும்.
6. Offboarding முறையைச் சரிபார்க்கவும். IdP கணக்கு முடக்கப்பட்ட பிறகு, API (application programming interface) tokens மற்றும் நேரடி அமர்வுகள் (live sessions) என்னவாகும் என்பதைக் கண்டறியவும்.

பிரிவு 2-ல் தான் பெரும்பாலான ஏமாற்றங்கள் ஏற்படுகின்றன. "Sign in with Google" பொத்தான் என்பது உங்கள் identity provider-உடன் இணைந்த OIDC அல்ல; அது ஒரு குறிப்பிட்ட vendor-உடன் செய்யப்பட்ட நிலையான ஒருங்கிணைப்பு (fixed integration). உண்மையான ஆதரவு (real support) உங்களிடம் issuer URL-ஐக் கேட்கும், மற்றவை அனைத்தும் discovery மூலம் தானாகவே அமையும். உங்கள் provider-ன் பக்கத்தை ஒரே கட்டளை மூலம் உறுதிப்படுத்தலாம்.

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

சரியாகச் செயல்படும் provider-லிருந்து மூன்று URL-கள் கிடைக்கும். முடிவு காலியாக இருந்தாலோ அல்லது 404 பிழை வந்தாலோ, discovery path தவறாக உள்ளது என்று பொருள்; அந்தப் பாதை provider-க்கு ஏற்ப மாறுபடும்: Keycloak அதை /realms/<realm>/.well-known/openid-configuration-ன் கீழ் வெளியிடுகிறது. அந்த app-ல் issuer URL-ஐ உள்ளிட எந்தப் புலமும் (field) இல்லை என்றால், அதன் அம்சப் பட்டியலில் என்ன இருந்தாலும், அது உங்கள் IdP-உடன் தொடர்பு கொள்ள முடியாது.

பிரிவு 6, ஒருவர் வேலையை விட்டுச் சென்ற சில வாரங்களுக்குப் பிறகு சிக்கலை ஏற்படுத்தும். IdP-ல் கணக்கை முடக்குவது புதிய login-களை மட்டுமே தடுக்கும். அது ஏற்கனவே வழங்கப்பட்ட API token-ஐ ரத்து செய்யாது, ஏனெனில் அந்த app அந்த token-ஐத் தானே சரிபார்க்கிறது, IdP-யிடம் கேட்பதில்லை. எனவே, offboarding-ல் இரண்டு நிலைகள் உள்ளன: IdP-ல் கணக்கை முடக்குவது, பின்னர் ஒவ்வொரு app-க்குள்ளும் அந்தப் பயனரையோ அல்லது அதன் token-களையோ நீக்குவது.

Tier பேட்ஜ்கள் உண்மையில் எதைக் குறிக்கின்றன

இவை ஆகஸ்ட் 2026-ல் ஒவ்வொரு திட்டத்தின் சொந்த ஆவணங்களுடன் சரிபார்க்கப்பட்டன. கட்டணப் பதிப்புகளிலிருந்து தொடங்குவோம்.

Grafana, SAML வசதியை "Grafana Enterprise மற்றும் Grafana Cloud-ல் கிடைக்கும்" என்று குறிப்பிடுகிறது, இதனுடன் team sync மற்றும் SCIM provisioning வசதிகளும் உள்ளன. Generic OAuth, GitHub OAuth, LDAP (lightweight directory access protocol) மற்றும் auth proxy ஆகியவை open source பதிப்பிலேயே இருப்பதால், சிறிய அளவில் self-host செய்பவர்கள் தங்கள் சொந்த provider மூலம் உள்நுழைய முடியும். ஒட்டுமொத்தமாக single sign-on வசதிக்கு பதிலாக, SAML வசதியிலேயே கட்டணப் பதிப்பு பிரிகிறது; "SSO tax" என்ற சொல் இந்த நுணுக்கத்தை மறைத்துவிடுகிறது.

Metabase இன்னும் நேரடியாக உள்ளது. அதன் ஆவணங்கள், "SAML authentication ஆனது Pro மற்றும் Enterprise திட்டங்களில் மட்டுமே கிடைக்கும் (self-hosted மற்றும் Metabase Cloud இரண்டிற்கும்)" என்று கூறுகிறது. Open source பதிப்பில் password login மற்றும் LDAP மட்டுமே உள்ளன.

Passbolt தனது SSO ஆவணங்களை Pro மற்றும் Cloud பதிப்புகளுக்கு மட்டுமே என்று குறிக்கிறது, எனவே community பதிப்பில் இந்த வசதி இல்லை. ஆவணப்படுத்தப்பட்ட provider-களில் Keycloak மற்றும் Entra ID ஆகியவை அடங்கும்.

இப்போது மறுபக்கத்தைப் பார்ப்போம், ஏனெனில் இந்த முறை எல்லா இடங்களிலும் பின்பற்றப்படுவதில்லை.

• GitLab Self-Managed தனது SAML பக்கத்தில் "Tier: Free, Premium, Ultimate" என்று குறிப்பிடுகிறது, எனவே உங்கள் சொந்த GitLab-ல் SAML பயன்படுத்துவதற்கு எந்தக் கட்டணமும் இல்லை.
• Paperless-ngx, PAPERLESS_SOCIALACCOUNT_PROVIDERS மூலம் OIDC-ஐ உள்ளமைக்கிறது, PAPERLESS_DISABLE_REGULAR_LOGIN மூலம் local login படிவத்தை மறைக்கிறது, மற்றும் PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS மூலம் claims-ஐ groups-ஆக மாற்றுகிறது.
• Planka, OIDC_ISSUER, OIDC_CLIENT_ID மற்றும் OIDC_CLIENT_SECRET ஆகியவற்றை எடுத்துக்கொள்கிறது, அதன் scopes-ஐ openid profile email என முன்னிருப்பாகக் கொள்கிறது, மற்றும் role claim மூலம் நிர்வாகிகளை (administrators) உருவாக்குகிறது OIDC_ADMIN_ROLES.
• BookStack, AUTH_METHOD=oidc மூலம் மாறுகிறது, பின்னர் provider groups-ஐ அதன் சொந்த roles-ஆக OIDC_USER_TO_GROUPS=true மற்றும் OIDC_GROUPS_CLAIM மூலம் மாற்றுகிறது.
• Vaultwarden, 27 டிசம்பர் 2025 அன்று 1.35.0 பதிப்பில் "support for SSO with OpenID Connect" வசதியை வெளியிட்டது. இது ஒரு fork-ல் இந்த வசதியை வைத்திருந்த ஒரு பங்களிப்பாளரின் pull request மூலம் கொண்டுவரப்பட்டது.
• listmonk, v4.0.0 பதிப்பிலிருந்து பயனர் roles-உடன் OIDC login வசதியைக் கொண்டுள்ளது.

நீங்கள் ஒரு திட்டத்தைத் தேர்ந்தெடுக்கும்போது இதைக் கவனத்தில் கொள்ளுங்கள். ஒரு Planka kanban board மற்றும் பிற self-hosted Trello மாற்றுகள் அனைத்தும் அடையாளத்தை (identity) ஒரே மாதிரியாகக் கையாளுவதில்லை, அதேபோல் BookStack, Wiki.js மற்றும் Outline ஆகியவையும் இல்லை. இலவச OIDC என்பது சேமிப்பக வரம்புகள் அல்லது mobile clients போன்ற ஒரு வசதியாகும். நீங்கள் இன்னும் பட்டியலைத் தயாரித்துக்கொண்டிருந்தால், 2026-ல் எதை self-host செய்வது என்பது ஒரு நல்ல தொடக்கப் புள்ளியாக இருக்கும், மேலும் Paperless-ngx document manager மற்றும் Vaultwarden ஆகிய இரண்டுமே இன்று இலவச OIDC வசதியை வழங்குகின்றன.

ஏன் reverse proxy-ஐ app-க்கு முன்னால் வைப்பது single sign-on ஆகாது

இதற்கான பொதுவான தீர்வு forward auth ஆகும். உங்கள் reverse proxy ஒவ்வொரு கோரிக்கையையும் (request) நிறுத்தி வைத்து, இந்த browser உள்நுழைந்துள்ளதா என்று ஒரு authentication service-இடம் கேட்கும். அதன் பிறகு மட்டுமே கோரிக்கையை app-க்கு அனுப்பும். authentik இதை proxy provider என்று அழைக்கிறது; இதில் ஒரு application-க்கு ஒரு forward auth முறையும், முழு domain-க்கும் வேறொரு முறையும் உள்ளது. 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 பெயர்களின் எழுத்து வடிவம் (capitalisation) முக்கியமானது, ஏனெனில் பெயர் தவறாக இருந்தால் அது காலியாகவே வரும். அது அனுமதிக்கும் ஒவ்வொரு கோரிக்கையிலும், outpost X-authentik-username, X-authentik-email, X-authentik-groups மற்றும் சிலவற்றை அமைக்கும்.

இதன் மூலம் உங்களுக்குக் கிடைப்பது இதுதான்: உங்கள் identity provider-ஐக் கடக்காமல் யாரும் app-ஐ அடைய முடியாது. எனவே, patch செய்யப்படாத login form இணையத்தில் வெளிப்படாது, மேலும் proxy-க்கு பின்னால் உள்ள அனைத்திற்கும் MFA ஒரே நேரத்தில் பொருந்தும்.

இதன் மூலம் உங்களுக்குக் கிடைக்காதது இதுதான்: app-க்குள் இருக்கும் identity. அந்த app-க்கு என்று தனிப்பட்ட கணக்குகளும், யார் உள்நுழைந்துள்ளனர் என்பது குறித்த அதன் சொந்த புரிதலும் இருக்கும். அனைவரும் proxy-ஐக் கடந்து ஒரே ஒரு shared administrator கணக்கிற்குள் சென்றால், உங்களுக்கு வலுவான முன்வாசல் இருக்கும், ஆனால் அதற்குப் பின்னால் ஒரு அநாமதேய session மட்டுமே இருக்கும். audit log-ல் ஒரே ஒரு பெயர் மட்டுமே தெரியும். நபர்களுக்கு இடையே அனுமதிகளை (permissions) வேறுபடுத்த முடியாது. இந்த அமைப்பை SSO என்று அழைப்பது ஒரு பாதுகாப்புத் தவறு, ஏனெனில் பணியாளர் நீக்கம் (offboarding) என்பது பாதி மட்டுமே உண்மை: உங்கள் IdP-லிருந்து அந்த நபரை நீக்குவது முன்வாசலை மூடிவிடும், ஆனால் அவர்கள் app-க்குள் உருவாக்கிய API token, app-ஐ நேரடியாக அணுகக்கூடிய எவருக்கும் தொடர்ந்து வேலை செய்யும்.

Header authentication-ஐ பாதுகாப்பாக வைத்திருத்தல்

சில applications proxy-விடமிருந்து username-ஐ ஏற்றுக்கொள்கின்றன. இது கட்டண SSO இல்லாமலேயே ஒவ்வொரு பயனருக்கும் தனித்தனி அடையாளத்தை வழங்குகிறது. இந்த அமைப்பிற்கான பெயர் ஒவ்வொரு project-லும் மாறுபடும்.

Grafana இதை auth proxy என்று அழைக்கிறது, இது இயல்பாகவே disabled நிலையில் இருக்கும். Header பெயர் இயல்பாக X-WEBAUTH-USER என்று இருக்கும், உங்கள் proxy எந்த header-ஐ அமைக்கிறதோ அதை நீங்கள் குறிப்பிடலாம்.

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

whitelist என்பது மக்கள் கவனிக்கத் தவறும் ஒரு வரியாகும். பயனர்கள் header-ஐ போலியாக உருவாக்காமல் (spoofing) தடுக்கவே இது இருப்பதாக Grafana-வின் ஆவணங்கள் தெளிவாகக் கூறுகின்றன. எனவே, இதில் உங்கள் proxy-ன் முகவரியை மட்டுமே குறிப்பிட வேண்டும். 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 நம்பக்கூடிய proxy-களின் எண்ணிக்கையைக் குறிக்கும். இந்த வரம்பை பூஜ்ஜியமாக (zero) அமைத்தால், header கையாளுதல் முற்றிலும் முடக்கப்படும்.

Paperless-ngx, PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME உடன் PAPERLESS_ENABLE_HTTP_REMOTE_USER-ஐ வழங்குகிறது. இந்த அமைப்புகள் அனைத்திற்கும் பொருந்தும் எச்சரிக்கையை அதன் ஆவணங்கள் இவ்வாறு கூறுகின்றன:

இது ஒரு request-ல் Remote-User: <username> header-ஐச் சேர்ப்பதன் மூலம் authentication-ஐ அனுமதிக்கும். கவனமாகப் பயன்படுத்தவும்!

Header authentication-ஐப் பாதுகாப்பாக வைத்திருக்க இரண்டு விதிகள் உள்ளன, இவை இரண்டும் அணுகல்தன்மை (reachability) சார்ந்தவை. முதலாவதாக, application-ஐ proxy வழியாக மட்டுமே அணுக முடியும் என்பதை உறுதிப்படுத்த வேண்டும். ஏனெனில், அதனுடன் socket இணைப்பை ஏற்படுத்தக்கூடிய எவரும் அந்த header-ஐ அனுப்பி எந்த பயனராகவும் மாற முடியும். Docker-ல், ports: ["8000:8000"] அனைத்து interface-களிலும் publish செய்யும். எனவே, அதை ports: ["127.0.0.1:8000:8000"] மூலம் loopback முகவரிக்கு bind செய்யவும் அல்லது publish செய்யப்பட்ட port-ஐ நீக்கிவிட்டு, proxy-ஐ அதே Docker network-ல் வைக்கவும். இரண்டாவதாக, client-விடமிருந்து வரும் அந்த header-ன் நகல்களை proxy நீக்க வேண்டும். அப்போதுதான், authentication-க்கு பிறகு உங்கள் proxy அமைக்கும் மதிப்பை மட்டுமே application பார்க்கும்.

இவ்விரண்டையும் சரிபார்க்கவும். முதல் கட்டளையை உங்கள் VPS-க்கு வெளியேயுள்ள ஒரு machine-லிருந்து இயக்கவும், இரண்டாவது கட்டளையை server-லேயே இயக்கவும்.

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 என்று வந்தால், அந்த application பொது இணையத்திற்கு நேரடியாகப் பதிலளிக்கிறது என்று பொருள். எனவே, எவரும் header-ல் ஒரு பெயரைச் சேர்ப்பதன் மூலம் அந்த பயனராக உள்நுழைய முடியும்.

இலவச SSO இல்லாதபோது, புகார் செய்வதற்குப் பதிலாக முடிவெடுங்கள்

நான் முயற்சிக்கும் வரிசையில் நான்கு தேர்வுகள் இங்கே உள்ளன.

1. OIDC வசதி கொண்ட application-ஐத் தேர்வு செய்யுங்கள். இரண்டு திட்டங்கள் ஒரே வேலையைச் செய்து, அதில் ஒன்று உங்கள் identity provider-உடன் இலவசமாக இணைந்தால், அது செயல்பாட்டுச் செலவில் பெரிய மாற்றத்தை ஏற்படுத்தும்.
2. Forward auth-ஐ முறையாகப் பயன்படுத்துங்கள். ஒரே கணக்கு மற்றும் ஒரு பயனர் மட்டுமே கொண்ட நிர்வாகக் கருவிக்கு, முன்னால் ஒரு proxy இருப்பது போதுமானது; application-க்குள் ஒவ்வொரு பயனருக்கும் தனித்தனி identity இருப்பது எந்தப் பயனும் தராது.
3. கட்டணம் செலுத்துங்கள். அந்த application உங்கள் பணிக்கு மிக முக்கியமானது மற்றும் அதன் தனிநபர் கட்டணம் உங்கள் குழுவிற்கு ஏற்றதாக இருந்தால், அந்தப் பணம் திட்டத்தைப் பராமரிக்க உதவும். இல்லையெனில், உங்கள் ஓய்வு நேரத்தை இதற்காகச் செலவிட வேண்டியிருக்கும்.
4. Issue tracker-ல் தேடிய பிறகு, upstream-ல் கேளுங்கள். Vaultwarden-ன் OIDC ஆதரவு, ஒரு பங்களிப்பாளரின் fork மற்றும் நீண்டகாலமாக நிலுவையில் இருந்த pull request மூலமே கிடைத்தது. எனவே, ஒரு செயல்பாட்டிற்கான கோரிக்கையைச் சரியான implementation-உடன் சமர்ப்பிக்கும்போது, அது சில நேரங்களில் இலவசப் பதிப்பிலும் சேர்க்கப்படலாம்.

உங்களுக்கென ஒரு identity provider இல்லாமல் இவை எதுவும் வேலை செய்யாது; எனவே முதலில் அதைத்தான் உருவாக்க வேண்டும். VPS-ல் authentik-ஐ இயக்குவது உங்களுக்கு OIDC மற்றும் SAML provider-ஐயும், மேலே குறிப்பிட்ட forward auth outpost-ஐயும் வழங்கும். நீங்கள் இன்னும் முடிவெடுக்கவில்லை என்றால், Keycloak, authentik மற்றும் Zitadel ஒப்பீடு அவற்றின் சாதக பாதகங்களை விளக்குகிறது.

உரிம வரலாறு மற்றும் சரிபார்ப்புப் பட்டியலில் அது ஏன் உள்ளது

கடைசி சரிபார்ப்புப் பட்டியல் உருப்படி எதிர்காலத்தைப் பற்றியது, ஏனெனில் இன்றைய அடுக்கு அமைப்பு (tier layout) ஒரு தற்காலிக நிலை மட்டுமே. இரண்டு நன்கு ஆவணப்படுத்தப்பட்ட நிகழ்வுகள், சூழல் எவ்வளவு விரைவாக மாறுகிறது என்பதைக் காட்டுகின்றன. 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)-ன் கீழ் வெளியிடப்படும் என்று அறிவித்தது.

இவற்றை நோக்கம் சார்ந்ததாகப் பார்க்காமல், செயல்முறை சார்ந்த சான்றுகளாகப் பார்க்கவும். நீங்கள் இன்று படிக்கும் உரிமம், நீங்கள் இன்று நிறுவும் பதிப்பிற்கு மட்டுமே பொருந்தும். அனைத்து பதிப்புரிமையையும் (copyright) தன்வசம் வைத்திருக்கும் ஒரு திட்டம், அதன் அடுத்த வெளியீட்டின் நிபந்தனைகளைத் தானாகவே மாற்ற முடியும். இதனால்தான் CLA கேள்வி சரிபார்ப்புப் பட்டியலில் உள்ளது, ஏனெனில் பரந்த பதிப்புரிமை ஒப்படைப்புதான் ஒருதலைப்பட்சமான உரிம மாற்றத்தை சாத்தியமாக்குகிறது.

ஒரு திட்டத்தின் மீது நீங்கள் கட்டமைப்பை உருவாக்குவதற்கு முன், அதன் வரலாற்றை நீங்களே சரிபார்க்கவும்.

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

பெரும்பாலும் முதல் இறக்குமதியிலிருந்து (import) பெறப்பட்ட சில commits-களைக் கொண்ட பட்டியல் ஒரு நல்ல அறிகுறியாகும். உரிமக் கோப்பு பலமுறை மாற்றியமைக்கப்பட்டிருந்தால், தற்போதைய நிபந்தனைகளைச் சார்ந்த திட்டங்களை வகுக்கும் முன், ஒவ்வொரு commit செய்தியையும் நீங்கள் படிக்க வேண்டும்.

FAQ

SSO tax என்றால் என்ன?

SSO tax என்பது, ஒரு மென்பொருளின் பிற அம்சங்கள் இலவசமாகவோ அல்லது மலிவாகவோ இருக்கும்போது, Single Sign-On (SSO) வசதியை மட்டும் பிரீமியம் அம்சமாக விற்பனை செய்யும் முறையாகும். சுய-ஹோஸ்ட் (self-hosted) மென்பொருட்களில், உரிமக் குறியீடு (licence key) இன்றி இயங்கும் ஒரு திறந்தநிலை மென்பொருளில், OIDC அல்லது SAML லாகின் வசதி மட்டும் கட்டணப் பிரிவில் இருப்பது இதற்கு உதாரணம். இந்த பெயர் sso.tax தளத்தில் உள்ள 'SSO Wall of Shame' என்பதிலிருந்து வந்தது; இது SSO-க்கு அதிக கட்டணம் வசூலிக்கும் விற்பனையாளர்களைப் பட்டியலிடுகிறது. சுய-ஹோஸ்ட் செய்பவர்களுக்கு இதனால் ஏற்படும் விளைவு என்னவென்றால், ஒவ்வொரு செயலியும் அதன் சொந்த பயனர் தரவுத்தளத்தைப் பராமரிக்க வேண்டியிருக்கும், எனவே கணக்குகளை கைமுறையாகவே உருவாக்கவும் நீக்கவும் வேண்டியிருக்கும்.

Forward auth கொண்ட reverse proxy-யும் SSO-வும் ஒன்றா?

இல்லை. Forward auth என்பது நுழைவாயிலைப் பாதுகாக்கிறது: ஒரு கோரிக்கை (request) செயலிக்குச் செல்லும் முன்பே, உங்கள் proxy அடையாள வழங்குநரிடம் (identity provider) சரிபார்க்கும். அதன் பின்னால் உள்ள செயலி இன்னும் அதன் சொந்த கணக்குகளையே பயன்படுத்துகிறது. எனவே, அனைவரும் ஒரே பொதுவான லாகின் பக்கத்திற்குச் சென்றால், உங்களுக்கு ஒரு அநாமதேய அமர்வும் (anonymous session), ஒரே பெயரைக் கொண்ட தணிக்கைப் பதிவும் (audit log) மட்டுமே கிடைக்கும். செயலி ஒரு header-லிருந்து பயனர் பெயரை வாசிக்கும்போது மட்டுமே இது உண்மையான தனிநபர் அடையாளமாக மாறுகிறது. Grafana-வின் auth proxy, Gitea-வின் reverse proxy authentication மற்றும் Paperless-ngx-ன் PAPERLESS_ENABLE_HTTP_REMOTE_USER ஆகியவை இதைச் செய்யக்கூடியவை. இந்த அமைப்புகள் proxy வழியாக மட்டுமே செயலியை அணுக முடியும் என்ற நிலையில் மட்டுமே பாதுகாப்பானவை; ஏனெனில் header என்பது எந்தவொரு client-ம் அனுப்பக்கூடிய ஒரு சாதாரண string ஆகும்.

எந்தெந்த சுய-ஹோஸ்ட் செயலிகள் இலவசப் பதிப்பில் OIDC-ஐ உள்ளடக்கியுள்ளன?

ஆகஸ்ட் 2026-ல் திட்ட ஆவணங்களின்படி சரிபார்க்கப்பட்டது: Paperless-ngx, Planka, BookStack, Gitea, listmonk மற்றும் Vaultwarden ஆகிய அனைத்தும் அவற்றின் இலவசப் பதிப்புகளில் OIDC-ஐ ஆதரிக்கின்றன. GitLab Self-Managed அதன் Tier: Free பிரிவில் SAML-ஐக் கொண்டுள்ளது. Grafana-வின் திறந்தநிலை மென்பொருள் உங்கள் சொந்த issuer-க்கு எதிராக பொதுவான OAuth-ஐக் கையாளுகிறது, ஆனால் SAML அங்கு ஒரு Enterprise அம்சமாகும். நீங்கள் நிறுவும் முன் அந்தந்த திட்டத்தின் அதிகாரப்பூர்வ authentication பக்கத்தில் உறுதிப்படுத்தவும், ஏனெனில் மென்பொருள் releases-க்கு ஏற்ப இந்த விவரங்கள் மாறக்கூடும்.

Single sign-on வசதியைத் திறக்கும் கட்டணப் பிரிவிற்கு நான் பணம் செலுத்த வேண்டுமா?

இரண்டு எண்களைக் கொண்டு இதை முடிவு செய்யுங்கள்: எத்தனை பேருக்கு கணக்குகள் தேவை, மற்றும் எத்தனை செயலிகளை நீங்கள் கைமுறையாகப் பராமரிக்க வேண்டியிருக்கும். ஒன்று அல்லது இரண்டு நிர்வாகிகளுக்கு, உள்ளூர் கணக்கிற்கு முன்னால் forward auth பயன்படுத்துவதே போதுமானது, அங்கு கட்டணப் பிரிவு பெரிய பயனைத் தராது. ஆட்கள் வந்து செல்லும் ஒரு குழுவிற்கு, பணியிலிருந்து விலகும்போது ஒரு கணக்கை நீக்கத் தவறினால் ஏற்படும் இழப்பு, உரிமக் கட்டணத்தை விட அதிகமாக இருக்கும். மேலும், நீங்கள் செலுத்தும் கட்டணம் நீங்கள் சார்ந்திருக்கும் மென்பொருளின் பராமரிப்பிற்கு உதவும். விலை உங்கள் பட்ஜெட்டிற்குள் இல்லை என்றால், OIDC வசதி இல்லாத செயலியைச் சுற்றி வேலை செய்வதை விட, OIDC வசதி கொண்ட செயலியைத் தேர்ந்தெடுப்பதே நடைமுறைக்குச் சிறந்ததாகும்.