Launch HN: SSOReady (YC W24) - เทคโนโลยีที่ทำให้ SAML SSO เป็นเรื่องง่ายและเป็นโอเพนซอร์ส

 (github.com/ssoready)
2 คะแนน โดย GN⁺ 2024-08-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • SSOReady เป็นเครื่องมือโอเพนซอร์สสำหรับเพิ่ม Enterprise SSO ที่ใช้ SAML และ Enterprise Directory Sync ที่ใช้ SCIM ให้กับผลิตภัณฑ์ พร้อมมีโฮสต์ตั้งค่า UI ที่ให้ลูกค้า onboarding ได้ด้วยตัวเอง
  • ออกแบบโดยยึด HTTP API เป็นแกนหลักเพื่อให้ใช้งานได้กับทุก application stack และมี SDK สำหรับ TypeScript, Python, Go, Java, C#, Ruby และ PHP ในรูป thin wrapper
  • การล็อกอินด้วย SAML ประกอบด้วยการสร้าง redirect URL และการแลก access code ส่วน SCIM ทำให้ ขั้นตอนการติดตั้งใช้งาน ง่ายขึ้นด้วยการดึงรายชื่อผู้ใช้ผ่าน external ID ขององค์กร
  • SSOReady ทำงานเป็นชั้น authentication middleware โดยไม่ครอบครองผู้ใช้และไม่บังคับให้แก้ไข ฐานข้อมูลผู้ใช้ เดิม อีกทั้งเลือกได้ว่าจะใช้ cloud hosting หรือ self-hosting
  • แผน Enterprise มี custom domain, branding, Management API และการรองรับแบบ SLA ส่วนไลเซนส์ MIT เปิดทางให้ fork ได้เพื่อเป็นกลไกถ่วงดุลต่อการขึ้นราคา

ฟีเจอร์ที่ SSOReady มอบให้

  • SSOReady เป็นโปรเจกต์โอเพนซอร์สสำหรับเพิ่มการรองรับ SAML และ SCIM ให้กับผลิตภัณฑ์
  • องค์ประกอบหลักมี 3 ส่วน
    • SSOReady SAML: ความสามารถที่จำเป็นสำหรับเพิ่ม SAML หรือ Enterprise SSO ให้กับผลิตภัณฑ์
    • SSOReady SCIM: ความสามารถที่จำเป็นสำหรับเพิ่ม SCIM หรือ Enterprise Directory Sync ให้กับผลิตภัณฑ์
    • Self-serve Setup UI: โฮสต์ UI สำหรับให้ลูกค้าทำ onboarding การตั้งค่า SAML หรือ SCIM ได้ด้วยตัวเอง
  • เอกสารเริ่มต้นใช้งานแบบรวดเร็วแยกเป็น SAML Quickstart และ SCIM Quickstart
  • README อธิบายว่าผู้ใช้ส่วนใหญ่สามารถติดตั้งใช้งาน SAML และ SCIM ได้ภายใน ครึ่งวันบ่าย และต้องใช้โค้ดเพียงสองบรรทัด

ความเป็นอิสระจากสแตกและตัวเลือกการดีพลอย

  • SSOReady ไม่ผูกติดกับ application stack ใดโดยเฉพาะ และ SDK รายภาษาที่ให้มาจะเป็น thin wrapper บน HTTP API ที่เข้าใจง่าย
  • SDK ที่มีให้ได้แก่
  • SSOReady ทำงานเป็นชั้น authentication middleware โดยไม่เป็นเจ้าของผู้ใช้และไม่บังคับให้แก้ไขฐานข้อมูลผู้ใช้เดิม
  • รูปแบบการดีพลอยเลือกได้ระหว่างใช้อินสแตนซ์แบบ cloud hosting หรือ self-hosting
  • แผน Enterprise มี การรองรับแบบ SLA ให้ทั้งสำหรับ cloud และ self-hosting

ขั้นตอนการติดตั้งใช้งาน SAML

  • SAML หรือ Enterprise SSO ประกอบด้วย 2 ขั้นตอน
    • ขั้นเริ่มต้นที่ redirect ผู้ใช้ไปยัง Identity Provider ของบริษัท
    • ขั้นประมวลผลที่ตรวจสอบว่าผู้ใช้คือใครแล้วจึงล็อกอินให้
  • การเริ่มล็อกอินใช้ endpoint Get SAML Redirect URL
    • ใน organizationExternalId สามารถใส่ ID ใดก็ได้ที่ผลิตภัณฑ์ใช้ เช่น องค์กร เวิร์กสเปซ หรือทีม
    • ID นี้จะถูกตั้งค่าไว้ใน SSOReady และ SSOReady จะดูแลการติดตามการตั้งค่า SAML และ SCIM ขององค์กรนั้น
  • การประมวลผลล็อกอินใช้ endpoint Redeem SAML Access Code
    • ใน handler ของ /ssoready-callback ให้แลก samlAccessCode เพื่อรับ email และ organizationExternalId
    • จากนั้นผลิตภัณฑ์ก็เพียงล็อกอินด้วยอีเมลที่ส่งกลับมาภายในองค์กรนั้น
  • URL ของ endpoint /ssoready-callback ถูกตั้งค่าใน SSOReady

ขั้นตอนการติดตั้งใช้งาน SCIM

  • SCIM หรือ Enterprise Directory Sync ถูกอธิบายว่าเป็นวิธีดึงรายชื่อพนักงานของลูกค้าแบบออฟไลน์
  • เมื่อดึงพนักงานของลูกค้า ให้ใช้ endpoint List SCIM Users
  • ในคำขอจะใช้ organizationExternalId และในคำตอบจะมี scimUsers กับ nextPageToken
  • ผู้ใช้ SCIM แต่ละรายจะมีค่าอย่าง email, deleted, attributes และผลิตภัณฑ์สามารถใช้ข้อมูลเหล่านี้เพื่อสร้างหรือจัดการผู้ใช้ได้

ความสามารถระดับ Enterprise และแนวคิดของโปรเจกต์

  • สามารถใช้ความสามารถเพิ่มเติมได้ในแผน Enterprise
    • Custom Domains & Branding: รัน SSOReady บนโดเมนที่ผู้ใช้ควบคุมเอง และปรับประสบการณ์ SAML และ SCIM ให้เข้ากับแบรนด์
    • Management API: ทำงานที่เกี่ยวข้องกับ SAML และ SCIM แบบอัตโนมัติในระดับขนาดใหญ่ผ่านโปรแกรม
    • Enterprise Support: การรองรับแบบ SLA รวมถึงสำหรับดีพลอยแบบ self-hosting
  • สมมติฐานของโปรเจกต์คือ ทุกผลิตภัณฑ์ที่ขายซอฟต์แวร์ให้ภาคธุรกิจควรรองรับ Enterprise SSO เพราะสิ่งนี้ให้ประโยชน์ด้านความปลอดภัยอย่างมากแก่ลูกค้า
  • มีมุมมองว่าคลังไลบรารี SAML แบบโอเพนซอร์สที่มีอยู่เดิมมักมีปัญหาเรื่องเอกสารไม่ดีและชวนสับสน และ SSOReady ตั้งเป้ามอบประสบการณ์การติดตั้งใช้งานที่ชัดเจนและปลอดภัยเป็นค่าเริ่มต้น
  • ด้วยจุดยืนที่ว่าไม่อาจยอมรับการขึ้นราคาซอฟต์แวร์ความปลอดภัยอย่างมากตามอำเภอใจ SSOReady จึงเผยแพร่ภายใต้ MIT license
  • แนะนำให้รายงานประเด็นด้านความปลอดภัยไปที่ security@ssoready.com

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

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

 
GN⁺ 2024-08-01
ความคิดเห็นบน Hacker News

  • คงต้องขออวยพรให้โชคดีเท่านั้น ก่อนหน้านี้ผมเคยสร้าง IdP เอง และทำฟีเจอร์ต่าง ๆ อย่าง single login, single logout, user provisioning ฯลฯ พอมันทำงานได้จริงก็รู้สึกเหมือนเวทมนตร์จนอดหัวเราะไม่ได้
    เราเชื่อมต่อกับ service provider หลายเจ้าและ IdP อื่น ๆ อีกสารพัด ฟีเจอร์ก็ดี แต่มีข้อแม้อย่างหนึ่งคือมันไม่เคยเป็น งานที่ไร้ความเจ็บปวด เลย
    ต่อให้สร้าง IdP ที่ดีที่สุดในโลก อีกฝั่งก็ยังเป็นกล่องดำ บ่อยครั้งที่ส่ง payload ออกไปแล้วไม่รู้ว่าทำไมมันถึงถูก consume
    แถมคู่เชื่อมต่อก็มักไม่รู้ flow ของ SAML, payload หรือแม้แต่ฟีเจอร์ SAML ใน stack ของตัวเอง ทำให้ต้องสอนอีกฝ่ายไปพร้อม ๆ กับเรียนรู้ระบบนั้นไปด้วย
    ส่วนใหญ่ไม่ใช่เรื่องต้องกังวลอย่าง signature หรือ format แต่เป็นการวินิจฉัยกล่องดำ และหลุมดำของการจัดการ certificate ที่ไม่มีวันจบ

    • น่าเสียดายที่เรื่องแบบนี้เกิดขึ้นกับ โปรโตคอลจำนวนมาก ผมเคยเจอใน IPSec, HL7v2 แม้กระทั่ง CSV
      โดยเฉพาะ IPSec นี่บาดแผลลึกมาก ตอนทำงานกับ “network engineer” ที่แม้แต่จะเปิด TCP connection สักอันเพื่อเช็กว่า VPN tunnel ยังอยู่ไหมก็ทำไม่ได้ ผมนี่ร้อนใจตลอดว่า “จะเชื่อมกับฝั่งนั้นได้จริงหรือเปล่า?”
      สุดท้ายก็ต้องเรียนรู้ระบบของอีกฝ่ายให้เร็วที่สุดเพื่อ判断ว่าคอนฟิกถูกไหม และค้นหาปัญหาการเชื่อมต่อที่หลีกเลี่ยงไม่ได้ แทบทุกครั้งต้นเหตุมักเป็น ไฟร์วอลล์ สักแห่ง
      อีกปัญหาคืออุปกรณ์ enterprise ชอบเปลี่ยนคำศัพท์มาตรฐานให้เป็นคำใหม่เฉพาะของตัวเอง การเรียนรู้ส่วนใหญ่เลยกลายเป็นการสร้าง Rosetta Stone ในหัวว่า “appliance” ของอีกฝ่ายเรียกคำนี้คำนั้นว่าอะไร
    • คล้ายกับการรัน เมลเซิร์ฟเวอร์ ของตัวเอง ต่อให้ตั้งค่า SPF, DMARC, DKIM ถูกต้อง ทำให้ระเบียน A/AAAA/TXT/MX กระจายไปทั่วโลกแล้ว และทดสอบด้วยเครื่องมือภายนอกอย่าง mail-tester.com เสร็จแล้ว โลกใหม่ที่ชื่อว่า “เมลเซิร์ฟเวอร์อื่น ๆ” ก็เปิดขึ้น
      เมลเซิร์ฟเวอร์บางเจ้ารับได้ดี แต่บางที่มี policy แปลก ๆ กับ blocklist ที่เข้มงวด และยังจัดการ reputation แยกตามโดเมนหรือผู้ส่งอีก
    • ถ้าพูดว่า “พอมันทำงานได้ก็เหมือนเวทมนตร์และทำให้หัวเราะ” แล้วต่อด้วย “ไม่เคยมีครั้งไหนที่ไม่เจ็บปวด และเหมือนถอนฟันตลอด” ถึงจะมีข้อแม้คั่นกลางก็อาจทำให้คนเข้าใจผิดได้
      น่าจะตั้งใจสร้างยอดขาย ซึ่งตัวมันเองก็โอเค แต่ครั้งหน้าควรขัดเกลาถ้อยคำอีกหน่อย

  • ดูเจ๋งดี ในฐานะคนที่เคย implement SAML มาก่อน มันเจ็บปวดจริง ๆ แต่เครื่องมือนี้ดู ง่ายกว่ามาก
    แต่ราคาทำให้กังวลนิดหน่อย เพราะเราต้องสร้างระบบของเราบนเครื่องมือนี้ ถ้าต่อมาบริษัทปิดตัวหรือเปลี่ยน pricing policy จนไม่เป็นผลดีกับเรา งานวิศวกรรมใหญ่ในการเขียน SSO ใหม่ก็จะโผล่มาทันที
    ถ้าให้ผลิตภัณฑ์แบบ hosted ฟรี สุดท้ายก็ดูมีโอกาสค่อนข้างสูงว่าจะปิดตัวหรือเปลี่ยนราคา
    ในฐานะคนที่ต้องใส่ SSO ให้โปรเจกต์ปัจจุบันภายใน 6–12 เดือนข้างหน้า ถ้ามี แพ็กเกจแบบเสียเงิน ที่ดูยั่งยืนได้ นอกเหนือจาก “ตอนนี้ฟรี” กับ “ยังไม่แน่ใจ ส่งอีเมลมาหาเรา” ก็จะอธิบายให้ทีมยอมรับได้ง่ายขึ้นมาก

    • เห็นด้วย 100% SAML เป็น ประตูทางเข้า ของแอปพลิเคชัน ผมไม่ชอบโครงสร้างที่คาดหวัง premium support จากผลิตภัณฑ์ฟรี ทั้งที่ภายหลังไม่ได้ตั้งใจจะซื้อผลิตภัณฑ์เสียเงินของบริษัทนี้
      และอย่าลืมว่าหนึ่งในตัวเลือกคือ “โทรหาผู้ก่อตั้ง”
    • ภาษี SSO[1] มีอยู่แล้ว การกั้นฟีเจอร์ด้านความปลอดภัย best practices และ automation ไม่ให้คนที่เป็นลูกค้าอยู่แล้วใช้นั้นแย่มาก แต่นั่นก็ใกล้เคียงกับมาตรฐานในปัจจุบัน
      ในความเป็นจริงแบบนั้น ถ้าบริษัทของคุณต้องใช้ SAML การจ่ายประมาณครึ่งหนึ่งของค่าใช้จ่ายที่ต้องจ่ายให้ SaaS app เดียวเพื่อฟีเจอร์นี้เพียงอย่างเดียวก็อาจสมเหตุสมผล
      [1]: https://sso.tax/
    • จากประสบการณ์ 10 ปีที่ผ่านมา ผมคิดว่าคงจะไม่สร้างอะไรบน โปรเจกต์โอเพนซอร์สที่รับเงิน VC อีกแล้ว สองอย่างนี้ไปด้วยกันยาก
      ไม่ได้หมายความว่าสร้างธุรกิจที่แข็งแรงด้วยโอเพนซอร์สไม่ได้ Red Hat ทำได้ แต่ควรไปตามโมเดลนั้น ไม่ใช่โมเดลเงินทุน VC ระยะ seed
    • เข้าใจข้อกังวลนี้อย่างสมบูรณ์ เป็นประเด็นที่สมเหตุสมผลและได้ยินบ่อย
      เราอาจโน้มน้าวด้วยตรรกะเชิงพาณิชย์ไม่ได้ แต่เรากำลัง เดิมพันอย่างมีการคำนวณ ว่าการให้ใช้ฟรีอย่างใจกว้างจะเป็นประโยชน์ในระยะยาว
      เรามองว่าผลิตภัณฑ์นี้จะสร้างความไว้วางใจจากนักพัฒนา และในอนาคตจะกลายเป็นช่องทางจัดจำหน่ายที่มีประสิทธิภาพ กลยุทธ์ commercial open source ที่ยังไม่ monetize ในช่วงแรกเป็นเรื่องค่อนข้างพบได้ทั่วไป
      โชคดีที่มีนักลงทุน venture บางรายที่ยินดีสนับสนุนบริษัทที่มีผลิตภัณฑ์ commercial open source ยอดนิยม
      เรายังเป็นบริษัทระยะเริ่มต้น และตั้งใจจะทำให้ผลิตภัณฑ์เดิมลึกขึ้น พร้อมกับนำเสนอผลิตภัณฑ์ใหม่เมื่อเวลาผ่านไป เราจะคิดเงินกับฟีเจอร์ใหม่และผลิตภัณฑ์ใหม่ และมองว่าถ้าต้องใช้เวลาหลายปีกว่าจะมีรายได้หรือกระแสเงินสดที่มีนัยสำคัญก็ไม่เป็นไร

  • การเปิดเป็นโอเพนซอร์สและปล่อยบริการที่ใช้ง่ายออกมานั้นน่าชื่นชม
    อีกอย่าง ถ้าสิ่งนี้กลายเป็น implementation ที่ได้รับความนิยมและมีคุณภาพดี service provider รายอื่น ๆ ก็อาจเชื่อมต่อกับผู้ใช้ซอฟต์แวร์นี้ได้ง่ายขึ้นด้วย
    ผมเคย implement การเชื่อมต่อ SSO ของ F500 ตั้งแต่ต้นหลายครั้ง แต่แต่ละเจ้าทำแบบปรับแต่งเฉพาะตัว ดังนั้นถึงจะเรียกว่า “SAML” ก็ไม่ได้แปลว่าจะ interoperable กันเสมอไป ซอฟต์แวร์แบบนี้อาจทำงานได้โดยปริยาย
    ผมสงสัยว่าตอนให้บริการ SSO แบบ hosted ฟรี จะรักษา ความปลอดภัย ได้ดีแค่ไหนเพื่อไม่ให้ลูกค้าถูกเจาะผ่านทางนั้น
    อีกอย่าง มันจะกลายเป็น single point of failure สำหรับลูกค้าทั้งหมด เลยสงสัยว่า free tier มี uptime guarantee ไหม และจะเสนอในราคาที่สตาร์ทอัพที่อยากใช้ hosting แต่ต้องมี SLA รับไหวได้หรือเปล่า

    • ความปลอดภัยของ SSO แบบ hosted ฟรีสำคัญมาก ไม่มีคำตอบสั้น ๆ มันเป็นเรื่องของการทำสิ่งที่ต้องทำให้ถูกต้อง
      เรื่อง SOC2 เรากำลังทำงานกับ Oneleet และทุกคนก็รู้ว่า SOC2 มีความเป็นละครอยู่มาก แต่เราก็กำลังทำ penetration test ที่ค่อนข้างละเอียดด้วย ถ้าต้องการ ผมส่งผลลัพธ์ทางอีเมลให้ได้
      ในทางปฏิบัติ เราเป็นบริษัทที่จำเป็นต้องทำเรื่องพวกนี้ให้ถูกต้อง
      uptime guarantee ของ free tier เราวางแผนจะตกลงเป็นกรณีไป และขึ้นกับสิ่งที่ต้องการ เราถือว่า guarantee เป็นเรื่องค่อนข้างจริงจัง จึงระมัดระวังกับคำมั่นสัญญา
      เราไม่ได้พยายามทำธุรกิจบริการ และไม่ได้อยากหาเงินจาก “premium support” แต่ถ้าต้องการ SLA ก็จะมีค่าใช้จ่ายเล็กน้อย
      คำถามที่ว่า “cloud provider จะเอาลูกค้าที่ใช้ซอฟต์แวร์นี้ไปหรือไม่” อยากให้ช่วยเรียบเรียงใหม่อีกที

  • ช่วงนี้อุปสรรคใหญ่ที่สุดของ SAML น่าจะเป็น การเชื่อมต่อกับผลิตภัณฑ์ SaaS ต้องเจอสถานการณ์ที่ต้องอีเมลคุยกับทีมซัพพอร์ตอยู่บ่อย ๆ และบางเวนเดอร์ก็ส่ง PDF 204 หน้า ที่พูดถึงแค่การตั้งค่า SSO มาให้ทั้งอย่างนั้นเลย
    การแมปแอตทริบิวต์ก็ยังเละเทะ และน่าทึ่งที่ประสบการณ์ผู้ใช้ยังแย่ได้ขนาดนี้

    • เมื่อก่อนเคยเขียน PDF 204 หน้าแบบนี้มาแล้ว อันที่จริงน่าจะประมาณ 20 หน้า แต่เพราะ IdP ไม่ได้ทำให้ลูกค้าตั้งค่าได้ง่าย สุดท้ายผู้ให้บริการอย่างพวกเราก็ต้องทำเอกสารสอนลูกค้าว่าจะใช้ IdP ของตัวเองอย่างไร
      พอดีเราเพิ่งเปิดตัวฟีเจอร์สำหรับปัญหานี้ แทนที่จะต้องทำ PDF 204 หน้า ก็ให้ SSOReady สร้าง URL สำหรับตั้งค่าแล้วส่งให้ลูกค้า ลูกค้าก็เข้า URL นั้นไปตั้งค่าการเชื่อมต่อ SAML กับผลิตภัณฑ์ได้ผ่าน UI แบบบริการตนเอง
      https://ssoready.com/docs/idp-configuration/enabling-self-se...
    • การซัพพอร์ต SSO กินเวลา มากกว่า 50% ของเวลาซัพพอร์ตลูกค้าของทีมวิศวกรรมเรา
      หนึ่งในเรื่องยากที่สุดคือผู้ใช้ต้องดึงแผนกอื่นที่เป็นเจ้าของระบบ SSO จริง ๆ เข้ามาเกี่ยวข้อง และแผนกนั้นก็ไม่ค่อยมีแรงจูงใจให้รีบทำให้มันใช้งานได้ ตั๋วจึงค้างยาวอยู่บ่อย ๆ
      บางทีเราก็ดูแย่ เพราะต้องขอข้อมูลบางอย่างจากลูกค้า
    • OKTA ทำได้ค่อนข้างดี แต่ต้องจ่ายได้ในระดับ ตั้งแต่สองหมื่นดอลลาร์ต่อปีขึ้นไป

  • เจ๋งดี สนใจตรงที่บอกว่า “วางแผนจะทำเงินในอนาคตด้วยการสร้างฟีเจอร์เสริมสำหรับองค์กรขนาดใหญ่ที่มีความต้องการซับซ้อน”
    อยากรู้ว่าในขั้นตอนสมัคร YC แค่นี้ก็พอให้ผ่านแล้วหรือเปล่า และให้ความสำคัญกับ โมเดลธุรกิจ มากแค่ไหนเพื่อการลงทุน

    • พูดตรง ๆ ตอนที่เข้า YC ได้ เรายังทำโปรเจกต์อื่นอยู่ ตอนนั้นอยากทำซอฟต์แวร์ทำความสะอาดข้อมูลด้วย LLM จนกระทั่งรู้ว่าไม่มีใครสนใจข้อมูลรก ๆ มากนัก
      เหตุผลหนึ่งที่เราสบายใจกับการให้ใช้ฟรีอย่างใจกว้าง คือข้อเท็จจริงพื้นฐานที่ว่าการช่วยบริษัท SaaS รองรับการล็อกอินแบบ SAML ไม่ใช่ตลาดที่ใหญ่นัก ยังไงก็ต้องไปทำเงินจากผลิตภัณฑ์อื่นอยู่ดี
      “การทำเงินจากฟีเจอร์เสริม” หมายถึงผลิตภัณฑ์ SAML ที่เรามีอยู่ตอนนี้ แต่เราก็จะเปิดตัวผลิตภัณฑ์อื่นด้วย
      เป้าหมายระยะยาวคือการสร้าง บริษัทที่คล้าย Auth0 แต่เป็นโอเพนซอร์สและเป็นมิตรกับนักพัฒนา

  • กำลังมองหาทางเลือกที่คุ้มค่ากว่า WorkOS อยู่พอดี เลยถูกจังหวะมาก กำลังสร้างพอร์ทัลตรวจสอบข้อมูลสำหรับองค์กร จะลองใช้ดู
    สงสัยว่ามีแนวทางอ้างอิงทันทีสำหรับการเชื่อมต่อกับ Entra ID ไหม จริง ๆ แล้วแค่มี API endpoint ก็พอหรือเปล่า?

    • สวัสดีครับ ผม Ned ผู้ร่วมก่อตั้งอีกคนของ SSOReady
      ใช่แล้ว โค้ดที่ต้องเขียนจะครอบคลุม IdP ทั้งหมด และความแตกต่างของแต่ละ IdP จะถูกจัดการผ่านค่าตั้งค่าของลูกค้าแต่ละราย
      ตัวอย่างเช่น เราเพิ่งจัดทำเอกสารเฉพาะสำหรับ Entra ไว้เมื่อไม่นานมานี้: https://ssoready.com/docs/idp-configuration/guides-for-commo...
      อยากรู้ว่าเนื้อหานี้ตอบสิ่งที่ต้องการได้ไหม
    • ผู้ก่อตั้ง WorkOS เอง
      เรามี ส่วนลดตามปริมาณ อัตโนมัติสำหรับผู้ใช้แบบจ่ายตามการใช้งาน และแผนรายปีหรือสัญญาแบบปรับแต่งก็ทำราคาให้ต่ำลงได้อีก เรายังมีเครดิตฟรีสำหรับบริษัทระยะเริ่มต้นด้วย
      ถ้าอยากคุยกัน ติดต่อได้ที่ mg@workos.com
      ตอนนี้มีบริษัทหลายร้อยแห่ง รวมถึงสตาร์ตอัปจำนวนมาก ใช้ WorkOS อยู่: https://workos.com/startups

  • เคยทำการเชื่อมต่อ SSO ในบริษัทก่อนหน้า แต่ SAML ดูเจ็บปวดเกินไป เลยทำแค่ OIDC2
    ไม่รู้ว่าตอนนี้ยังเป็นแบบนั้นไหม แต่พักหนึ่ง Okta ไม่อนุญาตให้ใช้ OIDC สำหรับ SSO ในการเชื่อมต่อ Okta ที่ใช้ SCIM และต้องใช้ SAML สำหรับ SSO
    เราเลี่ยงด้วยการทำการเชื่อมต่อ Okta แยกกันสองตัว สำหรับ SSO กับสำหรับ SCIM อธิบายกับฝ่าย IT ของลูกค้าทีไรก็น่ารำคาญเสมอ แต่ไม่มีใครติดใจ เลยไม่ต้อง implement SAML

  • ดูดีนะ อยากรู้ว่ามีแผนเพิ่ม SCIM ไหม
    SAML ก็ดี แต่จากประสบการณ์ หนึ่งในเหตุผลหลักที่ลูกค้าองค์กรใหญ่ต้องการ SSO คือการ deprovision อัตโนมัติ เพื่อลบสิทธิ์เข้าถึงจากทุกแอปในครั้งเดียวเมื่อพนักงานออกจากบริษัท ซึ่งต้องใช้ SCIM
    ถ้ามีทั้ง SAML กับ SCIM หรือแม้แต่แค่ subset เล็ก ๆ ของ SCIM ก็น่าจะเลือกได้แทบไม่ต้องคิด บริการอื่น ๆ เป็นแบบปิด ราคาแพงเกินจริง และการทำเองก็ทรมานมาก

    • SCIM จะเพิ่มเข้ามาเร็ว ๆ นี้ มองว่าฟีเจอร์เกี่ยวกับการ deprovision อัตโนมัติและการจัดการ seat เป็นแรงจูงใจสำคัญ
      พูดตรง ๆ IETF ทำ SCIM เองออกมาได้ค่อนข้างดี ไม่ได้ประหลาดเหมือน SAML จากประสบการณ์ ส่วนที่ยากที่สุดของการเชื่อมต่อ SCIM คือการตั้งค่าให้ตรงกับแต่ละ IdP
      เช่นเดียวกับ SAML สถานการณ์คือ Okta, Microsoft, OneLogin เรียกสิ่งเดียวกันเป๊ะด้วยคำศัพท์ที่ต่างกันอย่างสิ้นเชิง
      หนึ่งในฟีเจอร์ที่คาดหวังคือ ปุ่มสร้างลิงก์ตั้งค่า สำหรับส่งให้ลูกค้า ผ่านลิงก์นั้นลูกค้าจะตั้งค่าคอนฟิก SAML+SCIM ได้เองแบบบริการตนเอง
      ตอนนี้กับ SAML ใช้งานได้แล้ว และดีตรงที่ไม่ต้องเขียนเอกสารแยกตาม IdP เพื่ออธิบายศัพท์แปลก ๆ กับ UI เฉพาะตัวของแต่ละผลิตภัณฑ์

  • ยินดีกับการเปิดตัว เทียบกับ SAML Jackson[1] ของ BoxyHQ แล้วเป็นอย่างไร?
    [1]: https://github.com/boxyhq/jackson

    • ผมคิดว่า BoxyHQ ทำได้ดี
      เหตุผลที่เราชอบแนวทางของเรามีอยู่หลัก ๆ สองข้อ
      ข้อแรก BoxyHQ ต้องการ SAML-over-OAuth เรารองรับสิ่งนี้ โดยเฉพาะเพื่อความเข้ากันได้กับ NextAuth แต่ก็ไม่ได้มองว่ามันช่วยได้เสมอไป
      ข้อสอง ผมคิดว่าบริการของเราใช้ง่ายกว่า เรื่องที่ได้ยินผู้ใช้และลูกค้าบ่นบ่อยที่สุดคือความซับซ้อน เราเลยพยายามมากที่จะทำให้ SAML ชัดเจนและเรียบง่าย ท้ายที่สุดแล้ว ผู้ใช้เป็นคนตัดสินว่าเราทำได้ถึงเกณฑ์นั้นหรือไม่

  • กำลังเขียน custom policy แรกสำหรับ IdP แบบ B2C ของ Microsoft อยู่ ซึ่งเป็นกระบวนการที่เจ็บปวดมาก
    ถ้าทำให้การยืนยันตัวตนและ SSO เจ็บปวดน้อยลงได้ โลกก็น่าจะดีขึ้นจริง ๆ แอปจะปลอดภัยขึ้น ผู้ใช้จะหงุดหงิดน้อยลงเวลาใช้งาน และคนอย่างผมก็จะเครียดน้อยลงด้วย

    • ถ้าจะพูดให้ชัด การทำให้ “การยืนยันตัวตนและ SSO เจ็บปวดน้อยลง” นั้น อาจมองได้ว่าเป็นสิ่งที่ OAuth2 + OIDC ทำสำเร็จแล้ว บริษัทอย่าง Atlassian เข้าใจเรื่องนี้
      http://id.atlassian.com