ตั้งค่า Keycloak SSO ด้วย Docker Compose และ nginx

 (du.nkel.dev)
3 คะแนน โดย GN⁺ 2024-02-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ขั้นตอนการติดตั้งใช้งาน SSO โดยรัน Keycloak แบบแยกส่วนบน Linux VM เดียวด้วย rootless Docker และให้ nginx ของระบบทำหน้าที่ terminate TLS และ reverse proxy
  • ข้อกำหนดเบื้องต้นคือมีการเข้าถึงผ่าน SSH, มีโดเมนหรือซับโดเมนสำหรับ Keycloak, มี A record, มีผู้ใช้ keycloak แบบไม่ต้องใช้รหัสผ่าน, มีโฮมไดเรกทอรี /srv/keycloak และติดตั้ง Docker rootless แล้ว
  • docker-compose.yml ใช้ postgres:16 และ quay.io/keycloak/keycloak:25.0.1 โดยให้ Keycloak bind เฉพาะที่ 127.0.0.1:8080 และจัดการรหัสผ่านกับ KC_HOSTNAME ใน .env
  • nginx จะ redirect คำขอ HTTP ของ your.tld.com ไปยัง HTTPS และส่งต่อด้วย proxy_pass จากนั้นหลังออกใบรับรองด้วย Certbot ให้เปิดใช้ KC_PROXY_HEADERS: xforwarded
  • หากต้องการ custom theme หรือรันแบบ --optimized สามารถสร้างอิมเมจเองด้วย Dockerfile แบบ multi-stage และในสภาพแวดล้อม production ยังสามารถปรับค่าเพิ่มเติมเรื่องขนาดบัฟเฟอร์ของ JGroups และการกู้คืนทรานแซกชันของ Quarkus ได้

โครงสร้างการติดตั้งและข้อกำหนดเบื้องต้น

  • Keycloak เป็นตัวเลือก IAM แบบโอเพนซอร์ส สำหรับกรณีที่การทำระบบจัดการผู้ใช้และ SSO ภายในเว็บแอปโดยตรงทำได้ยาก
  • ทำงานร่วมกับโปรโตคอล SSO หลักอย่าง OpenID Connect (OIDC), OAuth 2.0, SAML ได้
  • การตั้งค่านี้เขียนอ้างอิงจาก Keycloak 23.0.6 และทดสอบถึง 25.0.5
  • โครงสร้างโดยรวมคือใช้งาน nginx เป็น reverse proxy กลาง แล้วส่งทราฟฟิกไปยัง localhost ของแต่ละ service namespace ที่รันด้วย rootless Docker
    • เว็บทราฟฟิกเข้ามาที่ 0.0.0.0:80 และ 0.0.0.0:443 แล้ว nginx ส่งต่อไปยัง Keycloak ที่ 127.0.0.1:8080
    • เป้าหมายคือให้เป็นการตั้งค่าที่ประหยัด โดยแชร์ทรัพยากรของโฮสต์เดียว แต่แยกสภาพแวดล้อมของแต่ละบริการออกจากกัน

การเตรียมระบบ

  • สภาพแวดล้อมพื้นฐานต้องมี Linux VM, การเข้าถึงจากระยะไกลผ่าน SSH, และโดเมนหรือซับโดเมนสำหรับบริการ Keycloak
    • โดเมนต้องมี A record และจะเพิ่ม AAAA record ด้วยก็ได้
  • การตั้งค่า Docker rootless พื้นฐานให้ทำตามขั้นตอนจากโพสต์ Mastodon แยกต่างหาก
    • สร้างผู้ใช้ non-root ใหม่ชื่อ keycloak แบบไม่ต้องใช้รหัสผ่าน
    • ตั้งค่าโฮมไดเรกทอรีเป็น /srv/keycloak
    • เพิ่มช่วงของผู้ใช้ keycloak ใน /etc/subuid และ /etc/subgid
    • ติดตั้ง Docker rootless ด้วย dockerd-rootless-setuptool.sh
    • ตั้งค่าให้บริการของผู้ใช้ keycloak เริ่มทำงานอัตโนมัติ

รัน Keycloak ด้วย Docker Compose

  • เมื่อต้องการเข้าใช้งานในผู้ใช้ keycloak ที่สร้างใหม่ ให้ใช้ machinectl shell keycloak@
    • ควรหลีกเลี่ยงวิธี sudo -u keycloak -H bash เพราะตัวแปรสภาพแวดล้อม XDG_RUNTIME_DIR จะยังไม่ถูกเตรียมไว้
  • สร้างไดเรกทอรีสำหรับข้อมูลถาวรและไฟล์ Docker ก่อน
    • พาธข้อมูล PostgreSQL คือ /srv/keycloak/data/postgres16
    • วางไฟล์ Docker ไว้ที่ ~/docker
  • docker-compose.yml ใช้อิมเมจ Keycloak ทางการและ PostgreSQL โดยตรง
    • อิมเมจ PostgreSQL คือ postgres:16
    • อิมเมจ Keycloak คือ quay.io/keycloak/keycloak:25.0.1
    • สำหรับ production แนะนำให้ใช้แท็กอิมเมจแบบระบุเวอร์ชันแทน :latest
  • การตั้งค่าหลักของคอนเทนเนอร์ Keycloak มีดังนี้
    • KC_DB: postgres
    • KC_DB_URL: jdbc:postgresql://postgres_db/keycloak
    • KC_HOSTNAME: ${KC_HOSTNAME:-your.tld.com}
    • KC_HTTP_ENABLED: true
    • HTTP_ADDRESS_FORWARDING: true
    • KEYCLOAK_ADMIN: admin
    • พอร์ตจะ bind เฉพาะ localhost ด้วย '127.0.0.1:8080:8080'
  • ใน .env ให้เก็บค่าที่เป็นความลับหรือแตกต่างกันตามสภาพแวดล้อม
    • POSTGRES_PASSWORD
    • KEYCLOAK_ADMIN_PASSWORD
    • KC_HOSTNAME
  • ไวยากรณ์ ${KC_HOSTNAME:-your.tld.com} หมายความว่าหากมี KC_HOSTNAME ใน .env ก็จะใช้ค่านั้น และถ้าไม่มีจะใช้ your.tld.com เป็นค่าเริ่มต้น
  • /srv/keycloak/data/postgres16 ใช้เก็บ ข้อมูลถาวร ของ PostgreSQL จึงควรเป็นเป้าหมายของการสำรองข้อมูลเป็นประจำ
    • หากต้องการล้างค่าเริ่มต้นทั้งหมด สามารถลบโฟลเดอร์ PostgreSQL นี้แล้วสร้างใหม่ได้ และระบบจะสร้างกลับมาอีกครั้งเมื่อเริ่มรันครั้งถัดไป
  • ถ้าจัดการ ~/docker เป็น Git repository ให้เพิ่ม .env ลงใน .gitignore และ commit เฉพาะ docker-compose.yml ได้

การทดสอบในเครื่อง

  • เริ่ม Docker Compose stack และตรวจสอบ log
docker compose up -d && docker compose logs --follow
  • หากต้องการเข้าถึงพอร์ต local ของ Keycloak บน VM ให้สร้าง reverse SSH tunnel
ssh you@111.11.11.11 -L :8080:127.0.0.1:8080 -p 22 -N -v
  • เปิด 127.0.0.1:8080 ในเบราว์เซอร์เพื่อตรวจสอบหน้าต้อนรับของ Keycloak

nginx reverse proxy และ TLS

  • ออกจากผู้ใช้ keycloak แล้วจึงเริ่มตั้งค่า nginx ของระบบ
  • เปลี่ยน your.tld.com เป็นโดเมนจริง และเพิ่ม A record ที่ผู้ให้บริการจดทะเบียนโดเมนเพื่อให้ DNS query ชี้ไปยัง IP ของ VM
  • สร้างและเปิดใช้งานไฟล์ตั้งค่าไซต์ของ nginx
nano /etc/nginx/sites-available/your.tld.com.conf
ln -s /etc/nginx/sites-available/your.tld.com.conf /etc/nginx/sites-enabled/
  • การตั้งค่า nginx จะ redirect คำขอ HTTP ไปยัง HTTPS และ proxy ไปยัง Keycloak ใน server block ของ HTTPS
    • proxy_set_header Host $host
    • proxy_set_header X-Real-IP $remote_addr
    • proxy_set_header X-Forwarded-For $remote_addr
    • proxy_set_header X-Forwarded-Proto $scheme
    • proxy_pass http://127.0.0.1:8080
  • แนะนำให้ใช้ Mozilla SSL configurator for nginx เพื่อสร้างค่าเริ่มต้นที่เหมาะกับเวอร์ชัน nginx สำหรับการตั้งค่า SSL
  • ทดสอบการตั้งค่าแล้ว reload nginx
nginx -t
systemctl reload nginx
  • เมื่อออกใบรับรองด้วย Certbot แล้ว บรรทัดที่จำเป็นใน your.tld.com.conf จะถูกอัปเดตให้อัตโนมัติ
certbot --nginx -d your.tld.com
  • จากนั้นเปิดใช้ ssl_trusted_certificate /etc/letsencrypt/live/your.tld.com/chain.pem; แล้ว reload nginx อีกครั้ง
  • เพื่อให้ทำงานหลัง nginx ได้ ให้เปิดใช้ KC_PROXY_HEADERS: xforwarded ใน docker-compose.yml แล้วรีสตาร์ต Docker stack
docker compose down && docker compose up -d && docker compose logs --follow

เส้นทางการดีบัก

  • หลังตั้งค่าแล้ว ให้เข้า your.tld.com และตรวจสอบว่าสามารถล็อกอินผู้ใช้ admin ด้วยรหัสผ่านจาก .env ได้
  • จุดแรกที่ควรตรวจสอบคือ log ของ Docker Compose
docker compose logs --follow
  • สำหรับ nginx access log และ error log ให้ติดตามไฟล์ต่อไปนี้
tail -f /var/log/nginx/your.tld.com-access.log
tail -f /var/log/nginx/your.tld.com-error.log
  • หากจำเป็นต้องตรวจสอบฐานข้อมูล Keycloak โดยตรง ให้เข้าเป็นผู้ใช้ keycloak แล้วรัน psql ภายในคอนเทนเนอร์ PostgreSQL
machinectl shell keycloak@
cd ~/docker
docker compose exec postgres_db /bin/bash
psql -h localhost -p 5432 -U keycloak keycloak

อิมเมจแบบกำหนดเองและการรันแบบ optimized

  • การตั้งค่าพื้นฐานใช้อิมเมจที่ build มาแล้วจาก quay.io
  • หากต้องการปรับแต่งธีมหรือรันในโหมด --optimized ให้ build อิมเมจเอง
  • Dockerfile ใช้อิมเมจ Keycloak ทางการเป็นฐานและใช้ multi-stage build
    • ในขั้น builder ให้ตั้ง ENV KC_DB=postgres
    • รัน /opt/keycloak/bin/kc.sh build
    • คัดลอก /opt/keycloak/ ไปยังอิมเมจสุดท้าย
    • กำหนด ENTRYPOINT ["/opt/keycloak/bin/kc.sh"]
  • ใน docker-compose.yml ให้เปลี่ยนดังนี้
    • ลบหรือคอมเมนต์บรรทัด image:
    • เปิดใช้ build: .
    • เพิ่ม command: start --optimized
  • จากนั้นหยุด Docker stack, จะสั่ง build แบบชัดเจนเพิ่มเติมก็ได้ แล้วเริ่มใหม่
docker compose down
docker compose build
docker compose up -d && docker compose logs --follow

รายการที่ปรับเพิ่มเติมในสภาพแวดล้อม production

  • คำเตือนเรื่องบัฟเฟอร์รับของ MulticastSocket ที่เกี่ยวข้องกับ JGroups แก้ได้โดยเพิ่มค่าบัฟเฟอร์ใน /etc/sysctl.conf ของโฮสต์
net.core.rmem_max = 26214400
net.core.wmem_max = 1048576
  • ใช้ sysctl -p เพื่อให้การตั้งค่ามีผล
  • คำเตือนเรื่องการกู้คืน XA transaction ของ Quarkus แก้ได้โดยเพิ่ม volume mount และตัวแปรสภาพแวดล้อมให้บริการ Keycloak
    • volume: /srv/keycloak/data/keycloak/ObjectStore/:/ObjectStore/
    • ตัวแปรสภาพแวดล้อม: QUARKUS_TRANSACTION_MANAGER_ENABLE_RECOVERY: true
  • ก่อนเริ่มระบบ ให้สร้างไดเรกทอรี ObjectStore บนโฮสต์ และเปลี่ยน owner ของ /ObjectStore ภายในคอนเทนเนอร์เป็น user ID 1000

ขั้นตอนหลังการตั้งค่า

  • สถานะสุดท้ายคือบริการ Keycloak ที่รันใน rootless Docker อยู่หลัง system nginx reverse proxy โดย nginx รับหน้าที่ SSL termination
  • การอัปเดตคอนเทนเนอร์อัตโนมัติให้อ้างอิงขั้นตอน auto-update จากโพสต์ Mastodon แยกต่างหาก
  • ขั้นตอนตั้งค่าถัดไปคือเพิ่มอีเมลในคอนโซลผู้ดูแล Keycloak
  • หลังจากนั้นสามารถเพิ่ม realm และตั้งค่าธีมได้
    • สำหรับธีมสามารถใช้ keycloakify และ keycloakify-starter
    • ใน Dockerfile มีบรรทัดที่ถูกคอมเมนต์ไว้สำหรับคัดลอก theme JAR ของ keycloakify ไปยัง /opt/keycloak/providers/

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-12
ความคิดเห็นจาก Hacker News

  • ช่วงหลังผมเพิ่มระบบยืนยันตัวตนให้โฮมแล็บ แล้วเลือกใช้ Authelia
    Keycloak ก็ใช้งานได้ แต่ใหญ่เกินไปมาก และถ้าจะใช้ร่วมกับ traefik forward auth ก็ต้องมีบริการเพิ่มเติมอีก
    Authelia ไม่มี UI สำหรับแก้ไขผู้ใช้ และไม่ได้ซิงก์สองทางกับเซิร์ฟเวอร์ LDAP ฝั่งแบ็กเอนด์ แต่ตั้งค่าได้ด้วยไฟล์แบบ static และ environment variables เท่านั้น จึงเหมาะกับหลายกรณี
    ถ้าแค่ต้องการเพิ่มการยืนยันตัวตนให้บางบริการ และใส่ SSO ให้บริการที่รองรับ ก็ถือว่าน่าเริ่มจาก Authelia

    • ผมทำงานที่ FusionAuth
      ถ้าต้องการ SSO, การตั้งค่าง่าย ๆ และ UI สำหรับผู้ดูแล FusionAuth ก็น่าดูเช่นกัน แม้ UI/UX จะให้ความรู้สึกเหมือนช่วงกลางทศวรรษ 2000 แต่สามารถดาวน์โหลดมารันเองได้[0], เป็นมิตรกับ Docker[1], และมีวิธีตั้งค่าหลายแบบ[2] เช่น จัดการ OIDC หรือการตั้งค่าอื่น ๆ ด้วย Terraform[3]
      ใช้งานฟรีได้ แต่ ไม่ใช่โอเพนซอร์ส[4]
      0: https://fusionauth.io/download
      1: https://fusionauth.io/docs/get-started/download-and-install/...
      2: https://fusionauth.io/docs/operate/deploy/configuration-mana...
      3: https://fusionauth.io/docs/operate/deploy/terraform
      4: https://fusionauth.io/license-faq#28
    • ใช้ Authelia มานานกว่า 2 ปีแล้ว และตั้งค่าการเชื่อมต่อ LDAP ด้วย LLDAP[0] ซึ่งเป็น implementation ของ LDAP แบบเบา
      ใช้ Caddy เป็น reverse proxy และผสานกับ Authelia[1] แล้วทำงานได้ดี
      ใส่การยืนยันตัวตนสองขั้นตอนที่แข็งแรงให้ทุกบริการ และรู้สึกว่าถึงจะเข้าถึงแอปที่โฮสต์เองโดยไม่ใช้ VPN ก็ปลอดภัยเพียงพอ
      แต่ Authelia ไม่มี release ใหม่มานานกว่า 1 ปีแล้ว เลยกังวลในแง่ความปลอดภัย
      [0] https://github.com/lldap/lldap
      [1] https://www.authelia.com/integration/proxies/caddy/
    • ช่วงหลังผมก็เดินทางเดียวกัน และโดยส่วนตัวเลือก caddy-security[1] ซึ่งเป็นปลั๊กอินของ Caddy
      [1] https://github.com/greenpau/caddy-security
    • Authelia มีจุดเด่นที่เฉพาะตัวมากคือ ขนาดการติดตั้งที่เล็ก ส่วน Keycloak หรือ authentik มักจะเข้ากับพื้นที่นี้ได้ยาก
      เป็น use case ที่ดีมากสำหรับสภาพแวดล้อมโฮมแล็บ และเหมาะเป็นพิเศษถ้าไม่ต้องการหรือไม่จำเป็นต้องใช้ฟีเจอร์ของโซลูชันที่ใหญ่กว่า
    • นอกเรื่องนิดหนึ่ง แต่สงสัยว่าช่วงนี้มี ทางเลือกแทน LDAP ไหม
      ลองหาดูแล้วก็ไม่เจอรูปแบบอย่าง schema ง่าย ๆ, JSON, HTTP และไม่น่าเชื่อว่าคนที่สร้างทุกอย่างขึ้นมาใหม่แทบทั้งหมดกลับไม่ได้สร้าง LDAP ขึ้นมาใหม่
      เท่าที่รู้ มาตรฐานอื่นที่มีอยู่จริงก็คือ Active Directory เท่านั้น
      อีกอย่าง สงสัยว่ามีมาตรฐานหรือโปรโตคอลสำหรับส่งต่อ access control ออกไปข้างนอกหรือไม่
      Authelia ควบคุมการเข้าถึงด้วยรูปแบบ URL ได้ แต่ถ้าเป็นไฟล์เซิร์ฟเวอร์ ตัวอย่างเช่น ผมคงคาดหวังรูปแบบที่ตรวจสอบสิทธิ์กับเซิร์ฟเวอร์ LDAP โดยอิงจาก ID ผู้ใช้ที่ยืนยันตัวตนแล้วและ key ในฐานข้อมูล
      สิ่งนี้ดูเหมือนจะเป็นทิศทางตรงข้ามกับ OAuth2 ที่เซิร์ฟเวอร์ได้รับสิทธิ์เข้าถึงบริการของบุคคลที่สาม

  • ช่วงหลังได้ลองมองหาวิธีตั้งค่า SSO ที่ค่อนข้างเรียบง่ายในโฮมแล็บ และเป้าหมายหลักคือให้ล็อกอินได้ง่าย ๆ ด้วยการยืนยันตัวตนผ่าน Google หรือ GitHub
    ที่ทำงานเก่าเคยใช้ทั้ง JetBrains Hub[1] และ Keycloak ซึ่งทั้งคู่ตั้งค่าค่อนข้างน่ารำคาญ
    JetBrains Hub เริ่มใช้งานได้ง่ายมาก และจากประสบการณ์ก่อนหน้าก็เป็นแบบนั้น แต่จุดที่ไม่สะดวกคือใน Docker registry ไม่มีแท็ก latest
    รู้ดีว่าการตรึงเวอร์ชันเป็นเรื่องดี แต่สำหรับการใช้งานส่วนตัว ปกติก็อยากอัปเดต Docker container ทั้งหมดทีเดียว
    ในทางกลับกัน Keycloak เริ่มต้นใช้งานยุ่งยากมาก แม้ในโหมดพัฒนาจะง่าย แต่การตั้งค่าโปรดักชันกลับติดขัด
    เท่าที่จำได้เกี่ยวข้องกับ wildcard Let's Encrypt certificate และหลังจากผ่านไปไม่กี่ชั่วโมงก็ยอมแพ้
    สุดท้ายเลือก Dex[2] ถึงจะเลื่อนมันไว้ก่อนเพราะเอกสารมีน้อย แต่การตั้งค่าจริงกลับง่ายมาก แค่มี YAML พื้นฐาน, ฐานข้อมูล SQLite และซับโดเมนหนึ่งตัวก็พอ
    ผมเอา Dex มารวมกับ OAuth2 Proxy[3] ที่ยอดเยี่ยมและเทมเพลต Nginx Proxy Manager แบบกำหนดเอง ทำให้แต่ละบริการภายในตั้งค่า SSO ได้ด้วยสองบรรทัด และยังทำ Dex Docker template[4] สำหรับ unRAID ด้วย
    นอกจากนี้ยังเสริมความปลอดภัยจากนอกบ้านด้วย Cloudflare Access และ WAF และอยากเพิ่มแค่ CrowdSec เพื่อให้ได้ insight เพิ่มขึ้นอีกเล็กน้อย

    1. https://www.jetbrains.com/hub/
    2. https://dexidp.io/
    3. https://github.com/oauth2-proxy/oauth2-proxy
    4. https://github.com/alex3305/unraid-docker-templates
    • ใช้ obligator เป็นที่เก็บข้อมูลชั่วคราว ไม่มีฐานข้อมูล และตั้งค่าแบบอิงโค้ด 100%
      ส่วนตัวคิดว่านี่เป็นตัวเลือกที่เรียบง่ายที่สุด
      https://github.com/lastlogin-io/obligator
    • อยากรู้ว่า oauth2-proxy มีฟีเจอร์อะไรที่ Dex ไม่มี

  • ผมทำตารางเปรียบเทียบที่ยังไม่เสร็จของ OpenID Connect server หลายตัวที่โฮสต์เองได้ไว้[0]
    หนึ่งในสิ่งที่น่าประหลาดใจคือ codebase ของ Keycloak ใหญ่มากจริง ๆ
    [0]: https://github.com/lastlogin-io/obligator?tab=readme-ov-file...

  • ความคิดที่ว่า Keycloak ช่วยแก้ปัญหาด้านความปลอดภัยให้นั้นน่าขำ
    ดู รายการ CVE ก็จะเข้าใจว่าหมายถึงอะไร

  • อย่างน้อยการที่บทความนั้นพูดถึง https://www.keycloakify.dev/ ก็มีประโยชน์มาก
    ดูเหมือนเป็นทางเลือกที่ยอดเยี่ยมแทนแนวทางทำธีมแบบมาตรฐาน

    • เป็นโปรเจกต์ที่ยอดเยี่ยม
      ใช้มาปีที่สองแล้ว และมีแต่เรื่องดี ๆ จะพูดถึง
      ผู้ดูแลตอบสนองรวดเร็วมาก และเมื่อไม่นานมานี้ก็มีการเปลี่ยนแปลงทั้งใน Keycloak และ keycloakify เพื่อเพิ่มความเข้ากันได้ในอนาคตของวิธีทำธีม
      ตอนนี้อย่างเป็นทางการรองรับเฉพาะแอปที่สร้างด้วย create-react-app แต่ vite branch กำลังพัฒนาอยู่ และส่วนตัวก็ใช้ร่วมกับ vite มาพักใหญ่แล้ว
    • ผมทำงานอยู่กับคู่แข่ง และกำลังปรับปรุงระบบธีมใหม่ โปรเจกต์นี้เลยดูเหมาะมากสำหรับนำมาศึกษาและใช้เป็นโมเดลในการปรับปรุง

  • กำลังจับตาดู authentik[1] และ authelia[2] อยู่
    Authelia ดูดีมาก แต่ Keycloak มี connector สำหรับ Angular ในขณะที่ Authelia ต้องตั้งค่าเอง เช่น OIDC Angular plugin เลยยังค่อนข้างระวัง
    ถึงอย่างนั้น ถ้ามีการตั้งค่าสำหรับ Keycloak ก็น่าจะเริ่มต้นได้ง่ายขึ้น
    [1] https://goauthentik.io/
    [2] https://www.authelia.com/

    • ถ้าใครกำลังพิจารณา authentik ผมอยากเตือนว่า “ตรงนี้มีมังกรซ่อนอยู่”
      ตอนนี้ปกป้องบริการมากกว่า 10 รายการทั้งบน Docker และ Kubernetes อยู่ตลอด ถ้าไม่ได้ชอบตั้งค่าการป้องกันแยกกันสำหรับแต่ละบริการ คุณจะลำบากกับ authentik
      authentik มีบั๊กร้ายแรง[0] เมื่อปกป้องหลาย subdomain (เช่น app1.example.com, app2.example.com ฯลฯ) ด้วยการตั้งค่าเดียว แล้วหลัง session หมดอายุและยืนยันตัวตนใหม่ ผู้ใช้จะถูก redirect ไปยังบริการอื่นแบบสุ่ม
      [0]: https://github.com/goauthentik/authentik/issues/6886
    • Authentik ทำ implementation ของ OAuth client credentials grant พังอย่างสิ้นเชิง
      แก้ไม่ได้หากไม่มี breaking change และใช้งานกับเครื่องมือจำนวนมากที่ใช้ cc grant ไม่ได้
      พอเห็นแบบนี้ก็ถอดออกจากรายชื่อผู้สมัครไปเลย
      https://github.com/goauthentik/authentik/issues/6139
    • ผมเป็นหนึ่งใน core maintainer ของ Authelia
      ถ้ามีอะไรที่ช่วยเรื่องการตั้งค่า Angular ได้ ยินดีช่วยผ่าน GitHub Discussions
    • ตอนนี้ก็กำลังจะตัดสินใจแบบเดียวกันอยู่
      Authentik ดูดีกว่า แต่บั๊กที่พูดถึงในคำตอบอื่นดูค่อนข้างแย่

  • ปัญหาของ Keycloak คือเป็นโปรเจกต์เก่า เลยผ่านการเปลี่ยนแปลงมาเยอะมาก
    มันเริ่มจากโปรเจกต์ JBOSS และประโยชน์ในฐานะ IdP จะโดดเด่นกับการยืนยันตัวตนของคลัสเตอร์ on-premises แต่ผมมองว่าก็แค่นั้น
    เคย implement Keycloak ขนาดใหญ่บน AWS ECS ในแผนกของบริษัท Fortune 500 และขั้นตอนทำให้ clustering ทำงานได้ถูกต้องเหมือนสงครามพันปี
    DNS discovery ทำงานไม่ถูกต้อง และ cluster discovery เป็นแบบ UDP จึงใช้ไม่ได้ในสภาพแวดล้อม cloud
    login ที่มี state บน server หนึ่งไม่มีอยู่บนอีก server ทำให้ทำ load balancing แบบง่าย ๆ ไม่ได้ และมีแค่ sticky session เป็นตัวเลือก
    การรัน Keycloak ด้วย docker run แล้วเสียบใช้งานเหมือน Auth0 นั้นง่าย แต่ให้ความรู้สึกเหมือนซื้อ Ford F-150 ปี 1996 ที่วิ่งมาแล้ว 250,000 ไมล์
    มันยังวิ่งได้และใช้งานได้ แต่การดูแลรักษานี่เลวร้ายจริง ๆ

    • เคยลองในระดับเล็กกว่าบน Docker Swarm แบบ on-premises และเจ็บปวดจริง ๆ
      เท่าที่จำได้ วิธี discovery เริ่มต้นใช้ multicast ซึ่งโดยทั่วไปไม่ได้เปิดในเครือข่าย cloud หรือ overlay network ของ Swarm/Kubernetes
      เคยเห็น database ping ที่ใช้ RDBMS เป็นเหมือนกลไก quorum แต่ดูเปราะมาก และให้ความรู้สึกเหมือนเป็นทางเลือกสุดท้าย
      สุดท้ายใช้ Kubernetes cluster driver ที่ค้นหา node ด้วย DNS ของ Swarm cluster ได้
      กว่าจะทำให้มันทำงานได้ก็เหนื่อยพอสมควร แต่หลังจากนั้นเท่าที่รู้ก็เสถียร
      ทุกวันนี้ดูเหมือนจะมี EC2 networking driver แบบ native ด้วย แต่ยังไม่ได้ลองสำรวจเอง
    • ได้ยินว่าหลังย้ายไป Quarkus เต็มตัวแล้วมีการปรับปรุงดีขึ้น
      อยากรู้ว่า deployment บน ECS นั้นทำเมื่อไหร่
    • OAuth กับ OpenID Connect และความสามารถในการเพิ่ม app กับ client เข้าไปใน realm คือสิ่งที่ช่วยชีวิต Keycloak ไว้ และเป็นเหตุผลเดียวที่ยังคงใช้ต่อ
    • ฟังแล้วเจ็บที่ cluster discovery เป็น UDP
      ของเราอนุญาต UDP เฉพาะสำหรับ DNS เท่านั้น

  • Keycloak ยอดเยี่ยม แต่สำหรับมือใหม่อาจสับสนพอสมควร
    ฟีเจอร์เยอะ และเอกสารก็ไม่ใช่ดีที่สุด
    ช่วงหลังได้ลองใช้ Zitadel แล้วใช้ง่ายกว่ามาก
    แต่ไม่สามารถรันด้วย database ในตัวได้ ทำให้ self-host ยากขึ้นเล็กน้อย

    • ใช่ ต้องมี database ของตัวเอง
      ต่อไปจะมุ่งไปทางใช้ Postgres เป็น database เลยหวังว่าจะ deploy ร่วมกับเครื่องมืออื่น ๆ ได้ง่ายขึ้น

  • เมื่อเร็ว ๆ นี้หัวหน้าเรียก Keycloak ว่า “ของที่ให้ของขวัญไม่หยุด” แต่ความจริงหมายถึงมี Jira ticket ใหม่ ๆ โผล่มาเรื่อย ๆ เพื่อหาว่าต้องทำอะไรยังไง
    ถึงอย่างนั้น เราก็มี Terraform ที่สร้าง EKS cluster และ deploy Keycloak, สร้าง SAML/OIDC client, เพิ่ม identity provider ภายนอก และตั้งค่า AWS IAM Identity Provider ด้วย
    พอรู้แล้วว่ามันทำอะไรได้บ้าง ทำใน UI อย่างไร และจะ automate ด้วย mrparkers Terraform provider อย่างไร การใช้งานเองก็ง่ายมาก

    • อยากรู้ว่า Terraform นั้นเปิดเป็นโอเพนซอร์สไว้ที่ไหนหรือเปล่า
      เพื่อนต้องการใช้อยู่ :)

  • หลังใช้ Keycloak มาหลายปี พูดตรง ๆ ว่าเริ่มเบื่อพฤติกรรมแปลก ๆ สารพัดแบบ เลยเริ่มมองหาทางเลือกอื่น
    หลายตัวเลือกอย่าง Authentik ก็ดูโอเค แต่ Zitadel[1] เตะตา และหลังจากนั้นก็ไม่หันกลับไปอีกเลย
    [1] https://zitadel.com/blog/zitadel-vs-keycloak

    • ดีใจที่ชอบ
      อยากรู้ว่าส่วนไหนคือจุดที่ดึงดูดใจแบบ निर्णायक