Keycloak vs authentik vs Zitadel: எது சிறந்தது?

ஒரே VPS-க்கு எந்த SSO server பொருத்தமானது

Keycloak, authentik மற்றும் Zitadel ஆகியன, ஒரு server-ல் உள்ள அனைத்து application-களுக்கும் ஒரே login-ஐப் பயன்படுத்த விரும்பும் போது பொதுவாகப் பரிந்துரைக்கப்படும் self-hosted single sign-on (SSO) servers ஆகும். ஒரு சிறிய VPS-ல் இவை ஒவ்வொன்றும் வெவ்வேறு தேவைகளைக் கொண்டவை. மூன்று அல்லது நான்கு self-hosted apps இயங்கும் ஒரு server-க்கு authentik பாதுகாப்பான தேர்வாகும்; ஏனெனில், சொந்தமாக login வசதி இல்லாத application-களுக்கும் login screen-ஐ உருவாக்கக்கூடிய திறன் இந்த மூன்றில் இதற்கு மட்டுமே உண்டு. நீங்கள் பாதுகாக்கும் ஒவ்வொரு application-மும் ஏற்கனவே ஒரு standard protocol-ஐ ஆதரித்தால், Keycloak சரியான தேர்வாகும்; ஆனால், இதற்கு Java virtual machine (JVM)-க்குத் தேவையான memory-ஐ ஒதுக்க வேண்டியிருக்கும். Zitadel என்பது API மூலம் ஒரு product-ஐ வழங்கும் developers-க்காக உருவாக்கப்பட்டது; 4 GB RAM-க்குக் குறைவான சூழலில் இதை நான் முயற்சி செய்ய மாட்டேன்.

முதலில் ஒன்றைத் தேர்வு செய்யுங்கள், பிறகு நிறுவுங்கள். நீங்கள் தேர்வு செய்த பிறகு, VPS-ல் authentik நிறுவுவதற்கான செயல்முறை விளக்கம் படிப்படியாக setup செய்ய உதவும்.

ஒவ்வொரு சேவைக்கும் உண்மையில் எவ்வளவு RAM தேவை?

வளங்களின் அடிப்படைத் தேவையில் இருந்து தொடங்குங்கள், ஏனெனில் எந்தவொரு அம்சத்தையும் கருத்தில் கொள்வதற்கு முன்பே, இதுவே உங்கள் தேர்வுப் பட்டியலைத் தீர்மானிக்கிறது. கீழே உள்ள எண்கள் ஆகஸ்ட் 2026-ல் அந்தந்த திட்டங்களால் வெளியிடப்பட்ட அதிகாரப்பூர்வ புள்ளிவிவரங்கள் ஆகும். இவை விற்பனையாளரின் வழிகாட்டுதல்கள் மட்டுமே, சுமை சோதனை (load test) முடிவுகள் அல்ல.

[
  {
    "label": "authentik",
    "vendor_min_ram_mb": 2048,
    "base_containers": 3
  },
  {
    "label": "Keycloak",
    "vendor_min_ram_mb": 1250,
    "base_containers": 2
  },
  {
    "label": "Zitadel",
    "vendor_min_ram_mb": 2048,
    "base_containers": 4
  }
]

authentik-ன் Docker Compose நிறுவல் பக்கம் "குறைந்தது 2 CPU கோர்கள் மற்றும் 2 GB RAM கொண்ட host" தேவை என்று குறிப்பிடுகிறது. இது 2048 MB ஆகும். அதன் வெளியிடப்பட்ட compose கோப்பு 3 containers-ஐ இயக்குகிறது: PostgreSQL, server, மற்றும் worker.

Keycloak மிகவும் துல்லியமான 3 புள்ளிவிவரத்தை வெளியிடுகிறது. அதன் அளவு நிர்ணய வழிகாட்டி (sizing guide) கூறுவது: "Realm தரவு மற்றும் 10,000 sessions-ஐ உள்ளடக்கிய ஒரு Pod-ன் அடிப்படை நினைவகப் பயன்பாடு 1250 MB RAM ஆகும்". அந்த 1250 MB என்பது தரவுத்தளத்திற்கு முன்பாக, Java process-க்கு மட்டுமே தேவைப்படும் அளவு. container limit ஏன் முக்கியமானது என்பதை அதே பக்கம் விளக்குகிறது: Keycloak நினைவக வரம்பில் 70%-ஐ heap-ஆகவும், கூடுதலாக சுமார் 300 MB-ஐ non-heap நினைவகமாகவும் பயன்படுத்துகிறது. நீங்கள் container-க்கு 1 GB ஒதுக்கினால், அது சுமார் 717 MB-ஐ heap-ஆகக் கணக்கிடும், அதே சமயம் 300 MB non-heap நினைவகமும் தேவைப்படும். எனவே, எந்தவொரு session தரவும் cache-ல் சேமிக்கப்படுவதற்கு முன்பே ஒதுக்கப்பட்ட நினைவகம் தீர்ந்துவிடும்.

Zitadel-ன் compose பக்கமும் 2 GB தேவை என்று கேட்கிறது, இதுவும் அதே 2048 MB தான், ஆனால் அந்த அளவு முதல்முறை இயக்கும்போது மட்டுமே பொருந்தும். நீங்கள் அதன் production பக்கத்தைப் படிக்க வேண்டும். Zitadel process-க்கு மட்டும் "சுமார் 512 MB RAM தேவை மற்றும் ஒரு CPU core-க்கும் குறைவான அளவில் இயங்க முடியும்". தரவுத்தளம் தான் அதிக நினைவகத்தை எடுத்துக்கொள்ளும் பகுதி: "வினாடிக்கு 100 கோரிக்கைகள் (req/s) வீதம் ஒரு CPU core மற்றும் ஒரு core-க்கு 4 GB RAM தேவை". கடவுச்சொல் hashing (password hashing) செய்யும்போது "இதற்காக 4 CPU கோர்கள் கிடைக்க வேண்டும்", ஏனெனில் திடீரென அதிகப்படியான login கோரிக்கைகள் வரும்போது CPU பயன்பாடு அதிகரிக்கும். அதிகாரப்பூர்வ v4 compose, நீங்கள் எதையும் சேர்ப்பதற்கு முன்பே 4 containers-ஐ இயக்குகிறது: proxy-ஆக Traefik, Zitadel API, தனி Login UI container, மற்றும் PostgreSQL. Redis மற்றும் OpenTelemetry collector ஆகியவை விருப்பத்தேர்வு (optional) compose profiles-ல் உள்ளன.

எனவே, Keycloak மற்றும் authentik ஆகியவற்றை 4 GB VPS-ல், நீங்கள் பாதுகாக்கும் பிற பயன்பாடுகளுக்கும் இடம் விட்டு இயக்க முடியும். Zitadel 2 GB-ல் தொடங்கும், ஆனால் ஒவ்வொரு login-ன் போதும் அது தனது சொந்த PostgreSQL தரவுத்தளத்துடன் நினைவகத்திற்காகப் போட்டியிடும். நான் Zitadel-ஐ 4 GB-க்குக் குறைவான சூழலில் இயக்க மாட்டேன்; பிற பயன்பாடுகளையும் உள்ளடக்கிய server என்றால் 8 GB-ஐ பரிந்துரைக்கிறேன்.

உங்கள் கணினியில் ஒவ்வொன்றும் எவ்வாறு இயங்குகின்றன

authentik என்பது PostgreSQL மற்றும் ஒரே image-ன் இரண்டு பிரதிகள் (ஒரு server மற்றும் ஒரு worker) ஆகியவற்றைக் கொண்டது. server ஆனது HTTP கோரிக்கைகளுக்குப் பதிலளிப்பதோடு, ஒரு embedded outpost-ஐயும் கொண்டுள்ளது. worker ஆனது directory syncs மற்றும் email போன்ற பின்னணிப் பணிகளைச் செய்கிறது. வெளியிடப்பட்ட install கட்டளை சுருக்கமானது.

wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

server ஆனது 9000 மற்றும் 9443 ஆகிய ports-ஐ வெளியிடுகிறது. 9000 port-க்கு முதல்முறை செல்லும்போது, ஆரம்பகட்ட அமைப்பு (initial setup) தொடங்கும்; அங்கு நீங்கள் default akadmin பயனருக்கான கடவுச்சொல்லை அமைக்க வேண்டும். அந்த port இணையத்திலிருந்து அணுகக்கூடியதாக மாறுவதற்கு முன்பே, அதற்கு முன்னால் ஒரு உண்மையான certificate கொண்ட reverse proxy-ஐ அமைக்கவும்.

Keycloak என்பது ஒரு process மற்றும் நீங்கள் வழங்கும் ஒரு database ஆகியவற்றைக் கொண்டது. இதன் quickstart ஒரு single container-ஆகும்.

docker run -p 127.0.0.1:8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:26.7.1 start-dev

start-dev என்பது சோதனைகளுக்காகப் பயன்படுத்தப்படுகிறது. இது local development database-உடன் இயங்குகிறது மற்றும் இதில் TLS (transport layer security) கிடையாது; எனவே, இந்த முறையில் தொடங்கப்பட்டு பின்னர் நீக்கப்படும் container, உங்கள் realm தரவுகளையும் சேர்த்து நீக்கிவிடும். production பயன்பாட்டிற்கு start முறையைப் பயன்படுத்த வேண்டும்; இதில் KC_DB வழியாக உண்மையான PostgreSQL-உம், KC_HOSTNAME வழியாக ஒரு public hostname-உம் பயன்படுத்தப்படும். Keycloak-ன் production வழிகாட்டியின்படி, server-க்கு வரும் மற்றும் செல்லும் அனைத்துத் தொடர்புகளுக்கும் பாதுகாப்பான வழிமுறை தேவை, எனவே அங்கு HTTPS கட்டாயமானது.

Zitadel என்பது மேலே விவரிக்கப்பட்ட நான்கு-container stack-ஐக் கொண்டது.

mkdir zitadel-compose && cd zitadel-compose
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/docker-compose.yml
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/.env.example
cp .env.example .env
docker compose up -d --wait

முதல்முறை தொடங்குவதற்கு முன்பே .env கோப்பில் ZITADEL_MASTERKEY-ஐ அமைக்கவும். இது Zitadel தனது database-ல் உள்ள ரகசியங்களை encrypt செய்யப் பயன்படுத்தும் 32 எழுத்துகள் கொண்ட key ஆகும்; இதைத் தொலைத்துவிட்டால் அந்த ரகசியங்களை அணுக முடியாது. இது போன்ற stack-களை இயக்குவதில் நீங்கள் புதியவர் என்றால், VPS-க்கான Docker Compose அடிப்படைகள் பகுதியில் உள்ள volume மற்றும் restart-policy தேர்வுகள், உங்கள் identity provider reboot-க்குப் பிறகும் நீடிக்க வேண்டுமா என்பதைத் தீர்மானிக்க உதவும்.

ஒவ்வொன்றும் எந்தெந்த protocols-ஐ ஆதரிக்கின்றன?

இவை மூன்றுமே OpenID Connect (OIDC)-ஐ ஆதரிக்கின்றன. இது OAuth 2.0-க்கு மேல் இயங்கும் login layer ஆகும், இதைத்தான் நவீன applications பயன்படுத்துகின்றன. மேலும் இவை மூன்றுமே SAML 2.0 (security assertion markup language)-ஐயும் ஆதரிக்கின்றன; இது enterprise software-களில் இன்றும் பயன்படுத்தப்படும் பழைய standard ஆகும். இதில் முக்கிய வேறுபாடு LDAP (lightweight directory access protocol)-ல் உள்ளது, ஏனெனில் ஒரே சொல் இரண்டு வெவ்வேறு பணிகளைக் குறிக்கிறது.

LDAP-லிருந்து வாசித்தல் (Reading from LDAP) என்பது, நீங்கள் ஏற்கனவே இயக்கும் directory-ல் உள்ள passwords-ஐ SSO server சரிபார்ப்பதைக் குறிக்கும். Keycloak இதை user federation மூலம் செய்கிறது. Zitadel-லும் இதைச் செய்கிறது: "ZITADEL-ல் ஒரு identity provider-ஆக LDAP server-ஐ இணைப்பது எப்படி" என்பதை அதன் documentation விளக்குகிறது.

LDAP-ஐ வழங்குதல் (Serving LDAP) என்பது, LDAP-ஐ மட்டுமே ஆதரிக்கும் ஒரு application, உங்கள் SSO server-ஐ ஒரு directory போலக் கருதி அதனுடன் bind செய்வதைக் குறிக்கும். இதை authentik மட்டுமே செய்கிறது. அதன் LDAP provider, "authentik database-ல் உள்ள அனைத்து users மற்றும் groups-ஐயும் LDAP directory மூலம் தேடக்கூடியதாக" மாற்றுகிறது. இது ஒரு பிரத்யேக LDAP outpost மூலம் நடைபெறுகிறது, மேலும் 636 port-ல் LDAPS வசதி உள்ளது. இது read-only என்பதால், bind மற்றும் search செயல்பாடுகள் மட்டுமே நடக்கும், writes நடக்காது. password;123456-ல் உள்ளவாறு, password-உடன் ஒரு semicolon சேர்த்து ஒருமுறை பயன்படுத்தும் code (one-time code) உள்ளிடப்பட வேண்டும், மேலும் bind செய்யும்போது SMS authenticators ஆதரிக்கப்படாது.

உங்கள் பட்டியலில் உள்ள ஒரு application LDAP-ஐ மட்டுமே ஆதரித்தால், ஒப்பீடு அங்கேயே முடிந்துவிடுகிறது. Keycloak மற்றும் Zitadel-ஆல் அந்த bind கோரிக்கைக்குப் பதிலளிக்க முடியாது, எனவே நீங்கள் அவற்றுடன் கூடுதலாக ஒரு directory-ஐ இயக்கி, இரண்டு user lists-ஐயும் sync-ல் வைத்திருக்க வேண்டியிருக்கும்.

Login வசதி இல்லாத applications-க்கு என்ன செய்வது?

இதற்கு Forward auth ஒரு தீர்வாகும்; self-hosted server-களில் இது அடிக்கடி தேவைப்படும் ஒரு சூழலாகும். ஒரு request-ஐ upstream-க்கு அனுப்பும் முன், அது அனுமதிக்கப்பட்டதா என்பதை உங்கள் reverse proxy, SSO server-இடம் கேட்கும். இதன் பின்னால் உள்ள application-க்கு SSO பற்றி எதுவும் தெரியாது. Proxy ஏற்கனவே சரிபார்த்த request-களை மட்டுமே அது பெறும், பொதுவாக username ஒரு header-ஆக அதில் இணைக்கப்பட்டிருக்கும்.

authentik-ன் proxy provider இதை மூன்று முறைகளில் வழங்குகிறது. "Proxy" முறையில், authentik outpost traffic-ஐ நேரடியாக upstream application-க்கு அனுப்பும். "Forward auth (single application)" முறையில், traffic உங்கள் தற்போதைய reverse proxy-யிடமே இருக்கும்; authentik அங்கீகாரத்தை (authentication) சரிபார்க்க மட்டுமே பயன்படுத்தப்படும். "Forward auth (domain level)" முறையில், ஒரு parent domain-ன் கீழ் உள்ள அனைத்து application-களும் ஒரே provider மூலம் பாதுகாக்கப்படும். Domain level முறை வசதியானது, ஆனால் இதில் ஒரு வரம்பு உள்ளது: "ஒவ்வொரு application-க்கும் தனித்தனி authorization விதிகளை இதில் அமல்படுத்த முடியாது", எனவே அந்த domain-ன் கீழ் உள்ள அனைத்து application-களும் ஒரே policy-ஐப் பகிர்ந்து கொள்ளும்.

Keycloak-ல் இத்தகைய வசதி இல்லை. அதன் துணை proxy-யான Keycloak Gatekeeper, Louketo Proxy எனப் பெயர் மாற்றப்பட்டு, பின்னர் GitHub-ல் archived செய்யப்பட்டது; அதன் கடைசி commit ஆகஸ்ட் 2023-ல் நடந்தது. OIDC ஆதரவு இல்லாத ஒரு application-ஐப் பாதுகாக்க, அதற்கு முன்னால் ஒரு தனி component-ஐ, பொதுவாக oauth2-proxy-ஐ, Keycloak client-ஐ நோக்கி இயக்க வேண்டும். Zitadel-லும் சொந்தமாக forward auth வசதி இல்லை, எனவே இதற்கும் அதே கூடுதல் component-ஐ நிறுவி, monitor செய்து, upgrade செய்ய வேண்டும்.

இந்தக் கூடுதல் hop-தான் reverse proxy configuration-ஐச் சிக்கலாக்குகிறது, எனவே Traefik மூலம் பல Docker Compose apps-ஐ எவ்வாறு இயக்குவது என்பதைப் படித்துவிட்டு, அதில் auth middleware-ஐ இணைக்கவும்.

மேம்படுத்தல் பாதை (upgrade path) எவ்வளவு சிக்கலானது?

ஆகஸ்ட் 2026 நிலவரப்படி, தற்போதைய releases-கள் Keycloak 26.7.1, authentik 2026.5.6, மற்றும் Zitadel v4.16.3 ஆகும். இவை மூன்றுமே PostgreSQL-ல் schema migrations-ஐ இயக்குகின்றன, அதாவது ஒவ்வொரு மேம்படுத்தலும் ஒரு database மாற்றமாகும். ஒவ்வொரு முறையும் முதலில் database-ஐ backup எடுக்கவும். இந்த ஒரு பழக்கம், இந்த ஒப்பீட்டில் உள்ள எந்தவொரு வசதியை விடவும் முக்கியமானது.

authentik மிகக் கடுமையான விதியைக் கொண்டுள்ளது மற்றும் அதைத் தெளிவாகக் கூறுகிறது: "மேம்படுத்தல்கள் major releases வரிசையைப் பின்பற்ற வேண்டும்; பழைய major version-லிருந்து நேரடியாக மிக சமீபத்திய version-க்குத் தாவ வேண்டாம்." ஒவ்வொரு version-க்குள்ளும் உள்ள சமீபத்திய patch-க்கு மாறிய பின்னரே அடுத்த version-க்குச் செல்ல வேண்டும், மேலும் "authentik downgrading-ஐ ஆதரிக்காது". காலண்டர் அடிப்படையில் version பெயரிடப்பட்ட ஒரு திட்டத்தில் ஒரு வருடம் பின்தங்குவது, ஒரு மேம்படுத்தலைத் தொடர்ச்சியான பல மேம்படுத்தல்களாக மாற்றிவிடும், ஒவ்வொன்றிற்கும் தனித்தனி database migration தேவைப்படும்.

Keycloak-ன் மேம்படுத்தல் வழிகாட்டி பின்பற்ற வேண்டிய வரிசையைக் கொடுக்கிறது: முந்தைய version-லிருந்து migration மாற்றங்களை ஆய்வு செய்யவும், server-ஐ மேம்படுத்தவும், பின்னர் adapters-ஐ மேம்படுத்தவும். Database migration தானாகவே இயங்கும், அல்லது நீங்கள் அதை export செய்து கைமுறையாகப் பயன்படுத்தலாம்; இது மாற்றங்கள் நடைமுறைக்கு வருவதற்கு முன்பு அவற்றைப் படிக்க விரும்பும் போது பயனுள்ளதாக இருக்கும். Keycloak-ல் உள்ள செலவு அந்த வாசிப்புதான். அதன் release notes-ல் உள்ள deprecations மற்றும் செயல்பாட்டு மாற்றங்களைத் தவிர்ப்பது எளிது, ஆனால் அவற்றைத் தவறவிடுவது அதிக பாதிப்பை ஏற்படுத்தும்.

Zitadel அதன் init மற்றும் setup நிலைகளை இயங்கும் server-லிருந்து பிரிக்கிறது, மேலும் அதன் production வழிகாட்டுதல் அவற்றை தனித்தனியாக வைத்திருக்கப் பரிந்துரைக்கிறது, இதனால் scaling செய்யும்போது setup வேலை மீண்டும் நடக்காது. ஒரு single VPS-ல், API ஆரோக்கியமாக (healthy) இருப்பதாகத் தெரிவிக்கும் முன்பே setup படிநிலை முடிவடைய வேண்டும் என்பதே இதன் பொருள், அதனால்தான் compose file-ல் health checks வழங்கப்பட்டுள்ளன மற்றும் start command --wait-ஐப் பயன்படுத்துகிறது.

ஒவ்வொரு திட்டமும் யாருக்காக உருவாக்கப்பட்டது மற்றும் அவை எங்கு பின்தங்குகின்றன

Keycloak என்பது Red Hat-ன் identity server ஆகும். இது realms, groups, role mappings மற்றும் ஏற்கனவே உள்ள corporate directory ஆகியவற்றைக் கொண்ட நிறுவனங்களுக்காக உருவாக்கப்பட்டது. மூன்றில் இதுவே மிகவும் முழுமையான தரநிலை (standards) அமலாக்கத்தைக் கொண்டுள்ளது. நான்கு self-hosted applications இயங்கும் 2 GB VPS-ல் இது பின்தங்குகிறது; ஏனெனில் அவற்றில் பாதி applications-க்கு OIDC ஆதரவு இல்லை. JVM-க்காக நீங்கள் 1250 MB-ஐ ஒதுக்க வேண்டியுள்ளது, நிறுவனங்களுக்காக வடிவமைக்கப்பட்ட realm மாதிரியைக் கற்க வேண்டியுள்ளது, மேலும் நீங்கள் உண்மையில் பயன்படுத்த விரும்பும் applications-க்காக மீண்டும் oauth2-proxy-ஐ நிறுவ வேண்டியுள்ளது.

authentik என்பது self-hosting பயனர்களுக்காக உருவாக்கப்பட்டது, அதன் அம்சப் பட்டியலே இதை உணர்த்துகிறது. இது forward auth மற்றும் LDAP provider-ஐக் கொண்டுள்ளது, மேலும் login flows-ஐ ஒரு visual editor மூலம் உருவாக்க அனுமதிக்கிறது. உங்களுக்கு vendor support contract தேவைப்படும்போதோ அல்லது சில வாரங்களுக்கு ஒருமுறை மாறாத release train தேவைப்படும்போதோ இது பின்தங்குகிறது. downgrade வசதி மற்றும் version skipping இல்லாத calendar versioning என்பது நடைமுறையில் பெரும் பணிச்சுமையை உருவாக்குகிறது; மேலும், உங்கள் உண்மையான தேவை ஒரு OIDC client-ஐ அமைப்பது மட்டுமே என்ற நிலையில், flow editor-ஐக் கற்றுக்கொள்வது தேவையற்ற கூடுதல் சுமையாகும்.

Zitadel என்பது தாங்கள் வெளியிடும் தயாரிப்புகளில் authentication-ஐச் சேர்க்கும் developers-க்காக உருவாக்கப்பட்டது. இது வலுவான API மற்றும் multi-tenancy ஆகியவற்றை முதன்மை அம்சங்களாகக் கொண்டுள்ளது. சரியாக இந்தச் சூழலில் இது பின்தங்குகிறது. நான்கு containers, forward auth வசதி இல்லாமை மற்றும் ஒரு core-க்கு 4 GB database அளவு என இருப்பது, ஒரு password manager மற்றும் wiki-ஐப் பின்னால் கொண்ட ஒரு VPS-க்கு ஏற்றதல்ல.

ஒரே VPS-ல் நான் எதை, எப்படி இயக்குவேன்

மூன்று அல்லது நான்கு self-hosted applications கொண்ட ஒரு VPS-க்கு, authentik-ஐப் பயன்படுத்தவும். இவை மூன்றிலும் login திரை வசதி உள்ளது. உங்கள் applications சிலவற்றில் OIDC வசதி இருக்காது என்பதே முடிவெடுக்கும் காரணி; இதற்கு authentik, தனியாக மற்றொரு component-ஐச் சேர்க்காமல், உள்ளமைக்கப்பட்ட forward auth மூலம் தீர்வை வழங்குகிறது.

முடிந்தால் 4 GB RAM ஒதுக்கவும்; மற்ற applications சிறியதாக இருந்தால் மட்டும் 2 GB போதுமானது. port 9000-ஐ public internet-க்குத் திறக்க வேண்டாம்; அதற்கு முன்னால் உள்ள reverse proxy-ல் TLS termination செய்யவும். ஒவ்வொரு இரவும் PostgreSQL dumps எடுத்து அவற்றை server-க்கு வெளியே சேமிக்கவும்; ஏனெனில், backup இல்லாத identity provider, அதற்குப் பின்னால் உள்ள அனைத்து applications-க்கும் ஒரு single point of failure ஆகிவிடும். இந்த stack-ஐ root-ஆக இயக்காமல், பிரத்யேகமான unprivileged account மூலம் இயக்கவும்: VPS-ல் குறைந்தபட்ச அதிகாரங்கள் கொண்ட பயனர்களை அமைத்தல் பகுதியில் இதற்கான account மற்றும் file ownership விவரங்கள் உள்ளன.

நீங்கள் பாதுகாக்கும் அனைத்து applications-ம் ஏற்கனவே OIDC அல்லது SAML-ஐ ஆதரித்தால், அல்லது Keycloak realms வழங்கும் நுணுக்கமான role model தேவைப்பட்டால், Keycloak-ஐத் தேர்ந்தெடுக்கவும். மற்றவர்கள் sign up செய்யும் வகையில் ஒரு application-ஐ உருவாக்கி, அதன் API மற்றும் tenant model தேவைப்பட்டால் Zitadel-ஐத் தேர்ந்தெடுக்கவும். இந்த post-ல் விவரிக்கப்பட்டுள்ள ஒரே server-ல் மூன்று applications-ஐ இயக்கும் சூழலுக்கு இவை இரண்டும் பொருந்தாது.

நீங்கள் முதலில் சந்திக்கும் தோல்வி நிலைகள்

மறுதொடக்கம் செய்த பிறகு Keycloak-ல் தரவுகள் இல்லை. நீங்கள் start-dev மூலம் அதைத் தொடங்கியுள்ளீர்கள், இது உள்ளூர் மேம்பாட்டுத் தரவுத்தளத்தைப் (local development database) பயன்படுத்துகிறது. Volume இல்லாத ஒரு container-ல், container-ஐ நீக்கினால் realm-ம் நீக்கப்பட்டுவிடும். KC_DB=postgres-ஐ ஒரு உண்மையான தரவுத்தளத்துடன் இணைத்து start-க்கு மாறவும்.

சிறிய server-ல் authentik worker container மறைந்துவிடுகிறது. worker மற்றும் server ஆகிய இரண்டும் ஒரே image-ஐப் பயன்படுத்துகின்றன, இரண்டிலும் Python processes இயங்குகின்றன. 2 GB நினைவகம் கொண்ட host-ல் PostgreSQL-க்குத் தேவையான நினைவகத்தை அது கோருகிறது. எந்த service வெளியேறியது என்பதை உறுதிப்படுத்த docker compose ps-ஐ இயக்கவும், பின்னர் பயன்பாட்டில் பிழை உள்ளதா என்று தேடுவதற்கு முன்பு, நினைவகப் பற்றாக்குறையால் (out-of-memory) அது நிறுத்தப்பட்டதா என்பதைச் சரிபார்க்க dmesg-ஐப் பார்க்கவும்.

உங்கள் proxy-க்கு பின்னால் Zitadel Console வேலை செய்யவில்லை. Zitadel API gRPC-ஐப் பயன்படுத்துகிறது, இதற்கு upstream வரை HTTP/2 தேவைப்படுகிறது. தேவைகள் பக்கத்தில் (requirements page), HTTP/2 upstream இணைப்புகளை ஆதரிக்கும் reverse proxy தேவை என்று குறிப்பிடப்பட்டுள்ளது. மேலும் Traefik v3.x, NGINX v1.x, Caddy v2.x மற்றும் Apache httpd 2.4.x ஆகியவற்றின் சோதிக்கப்பட்ட பதிப்புகள் பட்டியலிடப்பட்டுள்ளன. upstream இணைப்பை HTTP/1.1-க்குக் குறைக்கும் ஒரு proxy-ஐப் பயன்படுத்தினால், login பக்கம் மட்டுமே ஏற்றப்படும், Console வேலை செய்யாது.

ஒவ்வொரு பயன்பாடும் உங்களை மீண்டும் login திரைக்கு அனுப்புகிறது. SSO server-ன் பொது URL (public URL) மற்றும் பயன்பாட்டில் உள்ளமைக்கப்பட்ட URL ஆகியவை scheme மற்றும் port உட்பட சரியாகப் பொருந்த வேண்டும். Keycloak இதை hostname setting என்று அழைக்கிறது, Zitadel இதை external domain என்று அழைக்கிறது. இவை பொருந்தவில்லை என்றால், பயன்பாடு ஒரு login பக்கத்திற்கு உங்களை வழிநடத்தும், ஆனால் அந்த server அதைத் தனது சொந்தமாக அங்கீகரிக்காது. இதனால் browser இரண்டுக்கும் இடையே மாறி மாறிச் சென்று கொண்டிருக்கும்.

FAQ

2 GB VPS-க்கு இந்த மூன்றில் எது பொருத்தமானது?

authentik மற்றும் Keycloak. authentik-ன் அதிகாரப்பூர்வ தேவை குறைந்தபட்சம் 2 CPU cores மற்றும் 2 GB RAM ஆகும். Keycloak-ன் வழிகாட்டுதலின்படி, அதன் database-க்கு முன்பாகவே server-க்கு 1250 MB memory தேவைப்படுகிறது. நீங்கள் பாதுகாக்கும் பிற application-களையும் சேர்த்தால் 2 GB என்பது மிகவும் குறைவு, எனவே 4 GB-ஐ அடிப்படைத் தேவையாகக் கொள்வது சிறந்தது. Zitadel தனது முதல் இயக்கத்திற்கு 2 GB தேவை என்று கூறினாலும், அதன் production வழிகாட்டுதலில் password hashing-க்கு 4 CPU cores மற்றும் ஒவ்வொரு database core-க்கும் 4 GB RAM தேவைப்படுகிறது. எனவே 2 GB என்பது நடைமுறைக்குச் சாத்தியமான deployment அல்ல.

சொந்தமாக login வசதி இல்லாத ஒரு application-ஐ Keycloak அல்லது Zitadel மூலம் பாதுகாக்க முடியுமா?

தனிப்பட்ட முறையில் முடியாது. இவை இரண்டிலும் forward auth வசதி இல்லை. Keycloak-ன் பழைய proxy-ஆன Louketo Proxy, ஆகஸ்ட் 2023-ல் கடைசியாகப் புதுப்பிக்கப்பட்டு தற்போது GitHub-ல் ஆவணப்படுத்தப்பட்டுள்ளது (archived), எனவே அதை நம்பி புதிய கட்டமைப்புகளை உருவாக்க வேண்டாம். உங்கள் reverse proxy-க்கும் application-க்கும் இடையில் oauth2-proxy போன்ற ஒரு கருவியை நிறுவி, அதை SSO server-ல் உள்ள OIDC client-க்கு இணைக்க வேண்டும். authentik இதைத் தனது proxy provider மூலம் "Forward auth (single application)" அல்லது "Forward auth (domain level)" முறையில் நேரடியாகச் செய்கிறது.

LDAP மூலம் மட்டுமே இயங்கும் ஒரு application-க்கு, LDAP server-ஆகச் செயல்படக்கூடியது எது?

authentik. இதன் LDAP provider ஒரு outpost-ல் இயங்குகிறது. இது authentik-ல் உள்ள பயனர்கள் மற்றும் குழுக்களை LDAP மூலம் தேட அனுமதிக்கிறது, மேலும் port 636-ல் LDAPS வசதியும் உள்ளது. இது read-only முறையில் செயல்படும், எனவே bind மற்றும் search வசதிகள் வேலை செய்யும், ஆனால் தரவுகளை எழுத (write) முடியாது. Keycloak மற்றும் Zitadel இதற்கு நேர்மாறாகச் செயல்படுகின்றன: இவை ஏற்கனவே உள்ள LDAP directory-யிலிருந்து பயனர்களைப் பெற்றுக்கொள்ளுமே தவிர, ஒரு application-லிருந்து வரும் LDAP bind கோரிக்கைகளுக்குப் பதிலளிக்காது.

authentik-ஐ upgrade செய்யும்போது பதிப்புகளை (versions) தவிர்க்க முடியுமா?

முடியாது. ஆவணங்களின்படி, upgrade செய்யும்போது ஒவ்வொரு major release வரிசையையும் பின்பற்ற வேண்டும். பழைய major version-லிருந்து நேரடியாகச் சமீபத்திய பதிப்பிற்குச் செல்லக்கூடாது. முதலில் ஒவ்வொரு பதிப்பிலும் உள்ள சமீபத்திய patch release-க்குச் செல்ல வேண்டும், அதன் பிறகு ஒவ்வொரு பதிப்பாக உயர்த்த வேண்டும். ஒவ்வொரு படிநிலைக்கு முன்பும் PostgreSQL-ஐ backup எடுக்கவும், ஏனெனில் authentik-ல் downgrade வசதி இல்லை மற்றும் migrations முன்னோக்கி மட்டுமே செயல்படும்.