Launch HN: SSOReady (YC W24) - Công nghệ giúp SAML SSO trở nên đơn giản và mã nguồn mở

 (github.com/ssoready)
2 điểm bởi GN⁺ 2024-08-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • SSOReady là công cụ mã nguồn mở để thêm Enterprise SSO dựa trên SAML và Enterprise Directory Sync dựa trên SCIM vào sản phẩm, đồng thời cung cấp UI cấu hình được host để khách hàng có thể tự onboarding
  • Công cụ lấy HTTP API làm nền tảng để có thể dùng với bất kỳ stack ứng dụng nào, đồng thời cung cấp các SDK mỏng cho TypeScript, Python, Go, Java, C#, Ruby và PHP
  • Đăng nhập SAML được đơn giản hóa thành luồng triển khai gồm tạo URL chuyển hướng và đổi access code, còn SCIM là cách lấy danh sách người dùng bằng ID bên ngoài của tổ chức
  • SSOReady hoạt động như một lớp middleware xác thực, không sở hữu người dùng cũng không yêu cầu thay đổi cơ sở dữ liệu người dùng hiện có, và có thể chọn cloud-hosted hoặc self-hosted
  • Gói Enterprise cung cấp custom domain·branding, Management API và hỗ trợ SLA; giấy phép MIT giữ khả năng fork như một biện pháp kiềm chế việc tăng giá

Những gì SSOReady cung cấp

  • SSOReady là dự án mã nguồn mở để thêm hỗ trợ SAML và SCIM vào sản phẩm
  • Có ba thành phần chính
    • SSOReady SAML: chức năng cần thiết để thêm SAML, tức Enterprise SSO, vào sản phẩm
    • SSOReady SCIM: chức năng cần thiết để thêm SCIM, tức Enterprise Directory Sync, vào sản phẩm
    • Self-serve Setup UI: UI được host để khách hàng tự onboarding cấu hình SAML hoặc SCIM
  • Tài liệu bắt đầu nhanh được chia thành SAML Quickstart và SCIM Quickstart
  • README giải thích rằng đa số người dùng có thể triển khai SAML và SCIM trong một buổi chiều, và chỉ cần hai dòng mã

Tính độc lập với stack và các lựa chọn triển khai

  • SSOReady không bị ràng buộc vào stack ứng dụng cụ thể nào; các SDK theo ngôn ngữ chỉ là những wrapper mỏng trên HTTP API trực quan
  • Các SDK được cung cấp gồm
  • SSOReady hoạt động như một lớp middleware xác thực, không sở hữu người dùng và không yêu cầu thay đổi cơ sở dữ liệu người dùng hiện có
  • Có thể chọn dùng instance được host trên cloud hoặc self-hosting
  • Gói Enterprise cung cấp hỗ trợ SLA cho cả cloud lẫn self-hosting

Luồng triển khai SAML

  • SAML, tức Enterprise SSO, gồm hai bước
    • bước khởi đầu để chuyển hướng người dùng tới Identity Provider của công ty
    • bước xử lý để xác định người dùng là ai rồi đăng nhập cho họ
  • Để bắt đầu đăng nhập, dùng endpoint Get SAML Redirect URL
    • Trong organizationExternalId, có thể đưa vào bất kỳ ID nào mà sản phẩm đang dùng cho tổ chức, workspace, team, v.v.
    • ID đó được cấu hình trong SSOReady, và SSOReady sẽ theo dõi cấu hình SAML·SCIM của tổ chức tương ứng
  • Để xử lý đăng nhập, dùng endpoint Redeem SAML Access Code
    • Trong handler của /ssoready-callback, đổi samlAccessCode để nhận email và organizationExternalId
    • Sản phẩm chỉ cần dùng email được trả về để đăng nhập người dùng trong tổ chức tương ứng
  • URL endpoint /ssoready-callback được cấu hình trong SSOReady

Luồng triển khai SCIM

  • SCIM, tức Enterprise Directory Sync, được giới thiệu là cách lấy danh sách nhân viên của khách hàng theo kiểu offline
  • Khi lấy nhân viên của khách hàng, dùng endpoint List SCIM Users
  • Yêu cầu sử dụng organizationExternalId, và phản hồi bao gồm scimUsers cùng nextPageToken
  • Mỗi người dùng SCIM có các giá trị như email, deleted, attributes; sản phẩm có thể dựa vào đó để tạo hoặc xử lý người dùng

Tính năng Enterprise và triết lý dự án

  • Có thể dùng các tính năng mở rộng trong gói Enterprise
    • Custom Domains & Branding: chạy SSOReady trên domain do người dùng kiểm soát và tùy biến trải nghiệm SAML·SCIM theo thương hiệu
    • Management API: tự động hóa ở quy mô lớn các tác vụ liên quan đến SAML và SCIM theo cách lập trình được
    • Enterprise Support: hỗ trợ SLA, bao gồm cả triển khai self-hosting
  • Tiền đề của dự án là mọi sản phẩm bán phần mềm cho doanh nghiệp đều nên hỗ trợ Enterprise SSO, vì điều này mang lại lợi ích bảo mật lớn cho khách hàng
  • Dự án cho rằng các thư viện SAML mã nguồn mở hiện có thường thiếu tài liệu và gây khó hiểu; SSOReady hướng đến trải nghiệm triển khai rõ ràng và an toàn theo mặc định
  • Theo quan điểm rằng việc tùy tiện tăng mạnh giá phần mềm bảo mật là không thể chấp nhận, SSOReady được phát hành theo giấy phép MIT
  • Các vấn đề bảo mật được hướng dẫn báo cáo về security@ssoready.com

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-08-01
Ý kiến trên Hacker News

  • Chỉ có thể chúc may mắn. Trước đây tôi từng tự xây IdP, triển khai đủ thứ như đăng nhập một lần, đăng xuất một lần, cấp phát người dùng, v.v., và khi nó thực sự chạy thì đúng là kỳ diệu đến mức phải bật cười
    Tôi đã tích hợp với đủ loại service provider và cả các IdP khác, tính năng cũng ổn, nhưng có một điểm chắc chắn là việc này chưa từng là không đau đớn
    Dù có làm ra IdP tốt nhất thế giới thì phía bên kia vẫn là hộp đen, nên rất nhiều lúc payload bị gửi vào khoảng không rồi bạn không thể biết vì sao nó lại bị xử lý như vậy
    Hơn nữa, bên tích hợp thường cũng không hiểu luồng SAML, payload, thậm chí cả tính năng SAML trong chính stack của họ, nên mình vừa phải dạy họ vừa phải tự học hệ thống đó
    Phần lớn công việc không phải là lo về chữ ký hay định dạng, mà là chẩn đoán hộp đen và rơi vào hố đen quản lý chứng chỉ bất tận

    • Đáng tiếc là chuyện này xảy ra với rất nhiều giao thức. Tôi từng thấy ở IPSec, HL7v2, thậm chí cả CSV
      Đặc biệt IPSec để lại nhiều vết sẹo; làm việc với một “kỹ sư mạng” không mở nổi lấy một kết nối TCP để kiểm tra xem đường hầm VPN còn sống không khiến tôi chỉ biết nóng ruột tự hỏi “liệu có tích hợp được với bên kia không?”
      Cuối cùng vẫn phải học hệ thống đối tác càng nhanh càng tốt để phán đoán xem cấu hình có đúng không, rồi tìm ra những vấn đề tích hợp không thể tránh khỏi. Gần như lúc nào nguyên nhân cũng là tường lửa ở đâu đó
      Việc các thiết bị enterprise đổi thuật ngữ chuẩn thành từ ngữ riêng của họ cũng là vấn đề, nên phần lớn việc học thực chất là dựng một viên đá Rosetta trong đầu xem “appliance” của đối tác gọi thuật ngữ này hay thuật ngữ kia là gì
    • Nó giống như tự vận hành máy chủ mail của mình vậy. Kể cả khi bạn đã cấu hình SPF, DMARC, DKIM chuẩn chỉnh, các bản ghi A/AAAA/TXT/MX đã được lan truyền toàn cầu, và còn test bằng công cụ bên ngoài như mail-tester.com, thì rồi một thế giới mới mang tên “các mail server khác” lại mở ra
      Có mail server nhận rất tốt, nhưng cũng có nơi chạy chính sách kỳ quặc và danh sách chặn cực nghiêm, lại còn quản lý uy tín riêng theo domain hoặc người gửi
    • Nói “khi chạy thì kỳ diệu đến mức bật cười”, rồi ngay sau đó lại bảo “chưa lần nào không đau đớn và lúc nào cũng như nhổ răng” thì dù có thêm vế giải thích ở giữa vẫn dễ gây hiểu nhầm
      Có lẽ mục đích là để tạo doanh thu, điều đó tự nó không sao, nhưng lần sau nên trau chuốt cách diễn đạt hơn

  • Trông rất hay. Với tư cách người từng triển khai SAML, tôi thấy nó thực sự đau khổ, còn công cụ này có vẻ dễ thở hơn nhiều
    Tuy vậy tôi hơi lo về giá. Vì chúng tôi sẽ phải xây hệ thống của mình trên công cụ này, nên nếu sau này công ty phá sản hoặc đổi chính sách giá theo hướng bất lợi cho chúng tôi thì sẽ đột nhiên phát sinh một công việc kỹ thuật lớn là phải viết lại SSO
    Nếu họ cung cấp sản phẩm hosted miễn phí thì khả năng cuối cùng phá sản hoặc đổi giá có vẻ khá cao
    Với người cần gắn SSO vào dự án hiện tại trong 6~12 tháng tới như tôi, nếu ngoài “hiện đang miễn phí” và “chưa rõ nên cứ email cho chúng tôi” mà có một gói trả phí trông bền vững, thì sẽ dễ thuyết phục cả team hơn nhiều

    • Đồng ý 100%. SAML là cổng vào của ứng dụng, nên nếu ngay từ đầu đã không có ý định mua sản phẩm trả phí của công ty này thì mô hình kỳ vọng hỗ trợ cao cấp cho sản phẩm miễn phí nghe không ổn với tôi
      Cũng đừng quên rằng một trong các lựa chọn là “gọi điện cho nhà sáng lập”
    • Thuế SSO[1] đã tồn tại rồi. Việc khóa các tính năng bảo mật, best practice, và tự động hóa khỏi chính những người đã là khách hàng là điều tệ hại, nhưng đó gần như là chuẩn hiện tại
      Trong thực tế như vậy, nếu ở công ty có người cần SAML thì có lẽ việc trả khoảng một nửa chi phí của một ứng dụng SaaS đơn lẻ chỉ cho tính năng này cũng là hợp lý
      [1]: https://sso.tax/
    • Theo kinh nghiệm 10 năm qua, tôi sẽ không bao giờ xây thêm thứ gì trên dự án mã nguồn mở có vốn VC nữa. Theo tôi hai thứ đó khó mà cùng tồn tại
      Không có nghĩa là không thể xây doanh nghiệp vững chắc bằng mã nguồn mở. Red Hat đã làm được, nhưng phải đi theo mô hình đó chứ không phải mô hình gọi vốn VC giai đoạn seed
    • Tôi hoàn toàn hiểu mối lo đó, nó hợp lý và cũng là điều chúng tôi nghe rất thường xuyên
      Có thể chúng tôi không thuyết phục được mọi người về logic thương mại, nhưng đây là một canh cược có tính toán rằng việc cho miễn phí hào phóng sẽ có lợi về dài hạn
      Chúng tôi tin sản phẩm này sẽ tạo được niềm tin với developer và về sau sẽ trở thành một kênh phân phối hiệu quả. Chiến lược mã nguồn mở thương mại không kiếm tiền ở giai đoạn đầu là chuyện khá phổ biến
      May mắn là cũng có một số nhà đầu tư mạo hiểm sẵn sàng ủng hộ những công ty sở hữu sản phẩm mã nguồn mở thương mại được ưa chuộng
      Chúng tôi vẫn là công ty giai đoạn đầu, sẽ tiếp tục đào sâu sản phẩm hiện có và theo thời gian sẽ ra thêm sản phẩm mới. Các tính năng mới và sản phẩm mới sẽ được tính phí, và chúng tôi thấy ổn nếu phải mất vài năm mới đạt doanh thu hay dòng tiền đáng kể

  • Đáng khen khi họ phát hành dưới dạng mã nguồn mở và ra mắt một dịch vụ dễ dùng
    Ngoài ra, nếu đây trở thành một implementation phổ biến và chất lượng tốt, thì các service provider khác cũng có thể dễ tích hợp hơn với người dùng phần mềm này
    Tôi đã nhiều lần tự tay triển khai tích hợp SSO cho F500 từ đầu, và vì mỗi bên đều tùy biến nên dù cùng gọi là “SAML” cũng không nhất thiết tương tác được với nhau. Với phần mềm kiểu này thì có thể mặc định sẽ chạy
    Tôi cũng tò mò họ sẽ duy trì bảo mật tốt đến đâu khi cung cấp hosted SSO miễn phí để khách hàng không bị xâm phạm thông qua phía họ
    Ngoài ra, đây sẽ là điểm lỗi duy nhất cho toàn bộ khách hàng, nên tôi cũng muốn biết tầng miễn phí có đảm bảo uptime không. Và liệu họ có thể cung cấp hosted với mức giá startup chịu được cho những bên muốn hosted nhưng vẫn cần SLA hay không

    • Bảo mật của hosted SSO miễn phí thực sự rất quan trọng. Không có câu trả lời ngắn gọn nào cả, đơn giản là phải làm những việc cần làm cho đúng
      Về SOC2, chúng tôi đang làm việc với Oneleet, và dù ai cũng biết SOC2 phần nào mang tính trình diễn, chúng tôi cũng đang thực hiện kiểm thử xâm nhập khá kỹ. Nếu muốn, tôi có thể gửi kết quả qua email
      Thực tế là chúng tôi là kiểu công ty bắt buộc phải làm chuyện này cho ra hồn
      Với đảm bảo uptime cho tầng miễn phí, chúng tôi dự định thỏa thuận theo từng trường hợp cụ thể và sẽ tùy vào nhu cầu. Chúng tôi xem các cam kết này khá nghiêm túc nên rất cẩn trọng khi hứa hẹn
      Chúng tôi không định làm business dịch vụ, cũng không muốn kiếm tiền bằng “hỗ trợ cao cấp”. Tuy vậy nếu muốn SLA thì sẽ có một khoản phí nhỏ
      Câu hỏi “liệu nhà cung cấp đám mây có lấy mất khách đang dùng phần mềm này không” thì mong bạn diễn đạt lại một chút

  • Có vẻ trở ngại lớn nhất của SAML hiện nay là tích hợp với sản phẩm SaaS. Tôi đã nhiều lần phải qua lại email với đội hỗ trợ, thậm chí có nhà cung cấp còn gửi nguyên một file PDF 204 trang chỉ để nói về cấu hình SSO
    Việc ánh xạ thuộc tính vẫn còn rất lộn xộn, thật ngạc nhiên là trải nghiệm người dùng đến giờ vẫn tệ như vậy

    • Trước đây tôi từng viết một file PDF 204 trang kiểu này. Thực ra chắc chỉ khoảng 20 trang, nhưng vì các IdP không làm cho khách hàng dễ cấu hình, nên rốt cuộc phía nhà cung cấp dịch vụ, tức là chúng tôi, phải tự tài liệu hóa cách dùng IdP của họ cho khách hàng
      Đúng lúc, chúng tôi vừa ra mắt một tính năng cho chính vấn đề này. Không cần tạo PDF 204 trang nữa; bạn có thể tạo URL cấu hình trong SSOReady và gửi cho khách hàng, để họ vào đó tự thiết lập kết nối SAML với sản phẩm qua giao diện tự phục vụ
      https://ssoready.com/docs/idp-configuration/enabling-self-se...
    • Việc hỗ trợ SSO từng chiếm hơn 50% thời gian hỗ trợ khách hàng của đội kỹ sư chúng tôi
      Một trong những khó khăn lớn nhất là người dùng phải lôi kéo một bộ phận khác, nơi thực sự sở hữu hệ thống SSO, và bộ phận đó thường không có nhiều động lực để làm gấp nên ticket cứ bị kéo dài
      Điều đó cũng khiến chúng tôi trông có vẻ là bên gây khó dễ vì phải yêu cầu khách hàng cung cấp thông tin cụ thể
    • OKTA làm khá tốt, nhưng bạn phải có khả năng chi từ hơn 20.000 USD mỗi năm

  • Hay đấy. Tôi tò mò về đoạn “có kế hoạch kiếm tiền sau này bằng cách làm các tính năng bổ sung cho doanh nghiệp lớn có yêu cầu phức tạp”
    Không biết trong quá trình nộp YC, chỉ như vậy đã đủ để được nhận chưa, và họ coi trọng mô hình kinh doanh đến mức nào khi quyết định đầu tư

    • Nói thật là khi được YC nhận, tôi lại đang làm một dự án khác. Tôi từng muốn làm phần mềm dọn dẹp dữ liệu bằng LLM, trước khi nhận ra rằng hầu như chẳng ai quan tâm nhiều đến dữ liệu bẩn cả
      Một trong những lý do chúng tôi thoải mái với gói miễn phí hào phóng là vì sự thật cơ bản rằng việc giúp các công ty SaaS hỗ trợ đăng nhập SAML không phải là một thị trường quá lớn. Dù sao thì chúng tôi cũng phải kiếm tiền từ sản phẩm khác
      “Kiếm tiền từ tính năng bổ sung” là nói về sản phẩm SAML hiện tại, nhưng chúng tôi cũng dự định ra mắt các sản phẩm khác
      Mục tiêu dài hạn là xây dựng một công ty giống Auth0 nhưng mã nguồn mở và thân thiện với nhà phát triển hơn

  • Tôi đang tìm một giải pháp thay thế tiết kiệm chi phí hơn WorkOS nên đúng lúc thật. Tôi đang xây cổng xác minh dữ liệu doanh nghiệp và sẽ thử dùng
    Tôi muốn biết có hướng dẫn tham khảo ngay cho việc tích hợp với Entra ID không. Có thật là chỉ cần endpoint API là được à?

    • Xin chào, tôi là Ned, đồng sáng lập còn lại của SSOReady
      Đúng vậy. Phần code bạn cần viết là chung cho mọi IdP, còn khác biệt theo từng IdP sẽ được xử lý ở giá trị cấu hình của từng khách hàng
      Ví dụ, gần đây chúng tôi đã sắp xếp lại tài liệu riêng cho Entra: https://ssoready.com/docs/idp-configuration/guides-for-commo...
      Tôi muốn biết liệu như vậy đã đáp ứng đúng nhu cầu bạn cần chưa
    • Tôi là nhà sáng lập WorkOS
      Chúng tôi có chiết khấu theo sản lượng tự động cho khách hàng trả theo mức sử dụng, và các gói năm hoặc hợp đồng tùy chỉnh còn có thể rẻ hơn nữa. Chúng tôi cũng cung cấp tín dụng miễn phí cho các công ty giai đoạn đầu
      Nếu muốn trao đổi, bạn có thể liên hệ qua mg@workos.com
      Hiện tại WorkOS đang được hàng trăm công ty sử dụng, trong đó có nhiều startup: https://workos.com/startups

  • Ở công ty trước tôi từng triển khai tích hợp SSO, nhưng SAML có vẻ quá đau khổ nên chúng tôi chỉ làm OIDC2
    Tôi không biết bây giờ còn vậy không, nhưng có một thời gian Okta không cho phép dùng OIDC cho SSO trong các tích hợp Okta sử dụng SCIM, mà bắt buộc phải dùng SAML cho SSO
    Chúng tôi lách bằng cách tạo hai tích hợp Okta riêng, một cho SSO và một cho SCIM. Giải thích chuyện này với bộ phận CNTT của khách hàng lúc nào cũng phiền, nhưng chẳng ai phàn nàn nên chúng tôi không cần phải triển khai SAML

  • Trông rất ổn. Tôi muốn biết có kế hoạch bổ sung SCIM không
    SAML cũng tốt, nhưng theo kinh nghiệm của tôi, một trong những lý do chính khiến khách hàng doanh nghiệp lớn muốn SSO là để tự động hủy cấp quyền trên tất cả ứng dụng khi nhân viên nghỉ việc. Muốn làm vậy thì cần SCIM
    Nếu có cả SAML lẫn SCIM, hoặc thậm chí chỉ một tập con nhỏ của SCIM thôi, thì gần như tôi sẽ chọn mà không cần đắn đo. Các dịch vụ khác đều đóng, đắt vô lý, còn tự triển khai thì cực kỳ đau đầu

    • SCIM sẽ sớm được bổ sung. Chúng tôi thấy các tính năng liên quan đến tự động hủy cấp quyền và quản lý số ghế là động lực rất lớn
      Nói thật thì IETF làm SCIM khá ổn. Nó không kỳ quặc như SAML. Theo kinh nghiệm của tôi, phần khó nhất của tích hợp SCIM là khớp cấu hình theo từng IdP
      Cũng như với SAML, Okta, Microsoft và OneLogin gọi cùng một thứ bằng những thuật ngữ hoàn toàn khác nhau
      Một tính năng mà chúng tôi rất mong chờ là nút tạo liên kết cấu hình để gửi cho khách hàng. Qua liên kết đó, khách hàng có thể tự thiết lập cấu hình SAML+SCIM theo kiểu tự phục vụ
      Hiện giờ nó đã hoạt động với SAML, và rất tiện vì không cần phải viết riêng tài liệu cho từng IdP để giải thích thuật ngữ kỳ quặc và giao diện khác thường của từng sản phẩm

  • Chúc mừng ra mắt. So với SAML Jackson của BoxyHQ[1] thì thế nào?
    [1]: https://github.com/boxyhq/jackson

    • Tôi nghĩ BoxyHQ đang làm rất tốt
      Về cơ bản có hai lý do khiến chúng tôi thích cách tiếp cận của mình hơn
      Thứ nhất, BoxyHQ muốn dùng SAML-over-OAuth. Chúng tôi cũng hỗ trợ điều đó, đặc biệt để tương thích với NextAuth, nhưng không phải lúc nào chúng tôi cũng thấy nó hữu ích
      Thứ hai, tôi nghĩ dịch vụ của chúng tôi dễ dùng hơn. Điều phàn nàn chúng tôi nghe nhiều nhất từ người dùng và khách hàng là sự phức tạp, nên chúng tôi đã nỗ lực rất nhiều để làm cho SAML rõ ràng và đơn giản. Cuối cùng thì có đạt được tiêu chuẩn đó hay không vẫn là điều do người dùng đánh giá

  • Tôi đang viết chính sách tùy chỉnh đầu tiên cho B2C IdP của Microsoft, và đó là một quá trình đầy đau đớn
    Nếu có thể làm cho xác thực và SSO bớt đau khổ hơn, thì thế giới thực sự có thể trở nên tốt đẹp hơn. Ứng dụng sẽ an toàn hơn, mọi người sẽ bớt bực bội khi sử dụng, và mức độ căng thẳng của những người như tôi cũng giảm đi

    • Xét cho cùng, việc làm cho “xác thực và SSO bớt đau khổ hơn” có thể xem là điều mà OAuth2 + OIDC đã làm được. Các công ty như Atlassian hiểu điều này
      http://id.atlassian.com