Launch HN: SSOReady (YC W24) - Teknologi untuk membuat SAML SSO lebih mudah dan open source

 (github.com/ssoready)
2 poin oleh GN⁺ 2024-08-01 | 1 komentar | Bagikan ke WhatsApp
  • SSOReady adalah alat open source untuk menambahkan Enterprise SSO berbasis SAML dan Enterprise Directory Sync berbasis SCIM ke produk, serta menyediakan UI konfigurasi ter-hosting agar pelanggan dapat melakukan onboarding sendiri
  • Dengan HTTP API sebagai fondasi agar bisa digunakan di stack aplikasi apa pun, SSOReady juga menyediakan SDK untuk TypeScript, Python, Go, Java, C#, Ruby, dan PHP sebagai wrapper tipis
  • Login SAML disederhanakan menjadi alur implementasi yang terdiri dari pembuatan redirect URL dan pertukaran access code, sementara SCIM mengambil daftar pengguna berdasarkan ID eksternal organisasi
  • SSOReady berfungsi sebagai lapisan middleware autentikasi yang tidak memiliki pengguna dan tidak mengharuskan perubahan pada database pengguna yang sudah ada, serta bisa dipilih antara cloud hosting atau self-hosting
  • Paket Enterprise menyediakan custom domain dan branding, Management API, serta dukungan SLA, sementara lisensi MIT membuka kemungkinan fork sebagai penyeimbang terhadap kenaikan harga

Fitur yang disediakan SSOReady

  • SSOReady adalah proyek open source untuk menambahkan dukungan SAML dan SCIM ke produk
  • Terdapat tiga komponen utama
    • SSOReady SAML: fitur yang diperlukan untuk menambahkan SAML, yaitu Enterprise SSO, ke produk
    • SSOReady SCIM: fitur yang diperlukan untuk menambahkan SCIM, yaitu Enterprise Directory Sync, ke produk
    • Self-serve Setup UI: UI ter-hosting agar pelanggan dapat melakukan onboarding konfigurasi SAML atau SCIM sendiri
  • Dokumen mulai cepat dibagi menjadi SAML Quickstart dan SCIM Quickstart
  • README menjelaskan bahwa sebagian besar pengguna mengimplementasikan SAML dan SCIM dalam setengah hari dan hanya memerlukan dua baris kode

Independensi stack dan opsi deployment

  • SSOReady tidak terikat pada stack aplikasi tertentu, dan SDK per bahasa disediakan sebagai wrapper tipis di atas HTTP API yang intuitif
  • SDK yang tersedia adalah sebagai berikut
  • SSOReady berfungsi sebagai lapisan middleware autentikasi yang tidak memiliki pengguna dan tidak mengharuskan perubahan pada database pengguna yang sudah ada
  • Metode deployment bisa dipilih antara menggunakan instance cloud hosting atau self-hosting
  • Paket Enterprise menyediakan dukungan SLA baik untuk cloud maupun self-hosting

Alur implementasi SAML

  • SAML, yaitu Enterprise SSO, terdiri dari dua tahap
    • tahap awal untuk mengarahkan pengguna ke Identity Provider perusahaan
    • tahap pemrosesan untuk memverifikasi siapa pengguna tersebut lalu melakukan login
  • Untuk memulai login, digunakan endpoint Get SAML Redirect URL
    • organizationExternalId dapat diisi dengan ID apa pun yang digunakan produk, seperti organisasi, workspace, atau tim
    • ID tersebut dikonfigurasi di SSOReady, dan SSOReady menangani pelacakan konfigurasi SAML dan SCIM organisasi tersebut
  • Untuk memproses login, digunakan endpoint Redeem SAML Access Code
    • Di handler /ssoready-callback, samlAccessCode ditukar untuk mendapatkan email dan organizationExternalId
    • Produk kemudian cukup melakukan login menggunakan email yang dikembalikan di dalam organisasi tersebut
  • URL endpoint /ssoready-callback dikonfigurasi di SSOReady

Alur implementasi SCIM

  • SCIM, yaitu Enterprise Directory Sync, diperkenalkan sebagai cara untuk mengambil daftar karyawan pelanggan secara offline
  • Untuk mengambil data karyawan pelanggan, digunakan endpoint List SCIM Users
  • Permintaan menggunakan organizationExternalId, dan respons berisi scimUsers serta nextPageToken
  • Setiap pengguna SCIM mencakup nilai seperti email, deleted, dan attributes, yang bisa digunakan produk untuk membuat atau memproses pengguna

Fitur Enterprise dan filosofi proyek

  • Fitur lanjutan tersedia di paket Enterprise
    • Custom Domains & Branding: menjalankan SSOReady di domain yang dikendalikan pengguna dan menyesuaikan pengalaman SAML dan SCIM dengan brand
    • Management API: mengotomatisasi pekerjaan terkait SAML dan SCIM secara terprogram dalam skala besar
    • Enterprise Support: dukungan SLA termasuk untuk deployment self-hosting
  • Premis proyek ini adalah bahwa setiap produk yang menjual perangkat lunak untuk bisnis harus mendukung Enterprise SSO, karena hal ini memberikan manfaat keamanan yang besar bagi pelanggan
  • Ada pandangan bahwa library SAML open source yang sudah ada kurang terdokumentasi dan membingungkan, dan SSOReady menargetkan pengalaman implementasi yang jelas dan aman secara default
  • Berdasarkan pandangan bahwa menaikkan harga perangkat lunak keamanan secara sewenang-wenang dalam jumlah besar tidak dapat diterima, SSOReady disediakan dengan lisensi MIT
  • Isu keamanan diarahkan untuk dilaporkan ke security@ssoready.com

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-01
Opini Hacker News

  • Mau tidak mau hanya bisa mendoakan semoga beruntung. Dulu pernah membuat IdP sendiri dan mengimplementasikan berbagai fitur seperti single login, single logout, provisioning pengguna, dan lain-lain; ketika benar-benar berjalan, rasanya benar-benar seperti sihir sampai membuat tertawa
    Kami mengintegrasikannya dengan berbagai penyedia layanan dan IdP lain, dan fiturnya juga bagus, tetapi satu catatannya: itu sama sekali bukan pekerjaan tanpa rasa sakit
    Sekalipun Anda membuat IdP terbaik di dunia, pihak lawan tetap berupa kotak hitam, sehingga sering kali payload dikirim ke kehampaan lalu tidak jelas mengapa payload itu dikonsumsi
    Selain itu, sering kali pihak integrasi bahkan tidak memahami alur SAML, payload, atau bahkan fitur SAML di stack mereka sendiri, sehingga Anda harus mengajari pihak lawan sambil sekaligus mempelajari sistem mereka
    Alih-alih kekhawatiran seperti tanda tangan atau format, sebagian besar pekerjaannya adalah diagnosis kotak hitam dan lubang hitam manajemen sertifikat yang tak ada habisnya

    • Sayangnya, hal seperti ini terjadi di banyak protokol. Saya melihatnya di IPSec, HL7v2, bahkan CSV
      IPSec khususnya meninggalkan luka yang dalam; bekerja dengan “network engineer” yang bahkan tidak bisa membuka satu koneksi TCP untuk memastikan tunnel VPN masih hidup membuat batin terbakar sambil bertanya, “apakah mungkin kita bisa terintegrasi dengan pihak sana?”
      Pada akhirnya, kami harus mempelajari sistem pihak lawan secepat mungkin untuk menilai apakah konfigurasinya benar, lalu mencari masalah integrasi yang tak terhindarkan. Hampir selalu penyebabnya adalah firewall di suatu tempat
      Perangkat enterprise juga bermasalah karena mengganti istilah standar dengan kata-kata baru versi mereka sendiri, sehingga sebagian besar proses belajar menjadi pekerjaan membuat semacam Rosetta Stone di kepala tentang istilah ini dan itu disebut apa oleh “appliance” pihak lawan
    • Mirip dengan menjalankan server email sendiri. Bahkan setelah mengonfigurasi SPF, DMARC, DKIM dengan benar, memastikan record A/AAAA/TXT/MX sudah tersebar ke seluruh dunia, dan menyelesaikan pengujian dengan alat eksternal seperti mail-tester.com, kini terbentang dunia baru bernama “server email lain”
      Sebagian server email menerimanya dengan baik, tetapi sebagian lain menjalankan kebijakan aneh dan daftar blokir yang ketat, serta mengelola reputasi terpisah per domain atau pengirim
    • Kalau mengatakan “ketika berjalan, rasanya seperti sihir dan membuat tertawa”, lalu segera setelah itu mengatakan “tidak pernah sekalipun tanpa rasa sakit dan selalu terasa seperti mencabut gigi”, meski ada catatan di tengah, itu bisa menimbulkan salah paham
      Mungkin maksudnya untuk menghasilkan penjualan, dan itu sendiri tidak apa-apa, tetapi lain kali sebaiknya ungkapannya diperhalus

  • Terlihat keren. Dari sudut pandang orang yang pernah mengimplementasikan SAML, itu benar-benar menyakitkan, dan alat ini terlihat jauh lebih mudah
    Namun saya agak khawatir soal harga. Karena kami harus membangun sistem kami di atas alat ini, jika nanti perusahaannya bangkrut atau kebijakan harganya berubah menjadi tidak menguntungkan bagi kami, tiba-tiba akan muncul pekerjaan engineering besar untuk menulis ulang SSO
    Jika produk hosting diberikan gratis, tampaknya kemungkinan akhirnya bangkrut atau mengubah harga cukup tinggi
    Dari posisi harus menambahkan SSO ke proyek saat ini dalam 6–12 bulan ke depan, akan jauh lebih mudah meyakinkan tim jika ada paket berbayar yang terlihat berkelanjutan, bukan sekadar “sekarang gratis” dan “kami belum tahu, jadi kirim email”

    • Setuju 100%. SAML adalah gerbang masuk aplikasi, jadi saya tidak suka struktur yang mengharapkan dukungan premium pada produk gratis padahal nantinya tidak berniat membeli produk berbayar dari perusahaan ini
      Jangan lupa juga bahwa salah satu pilihannya adalah “telepon pendiri”
    • Pajak SSO[1] memang sudah ada. Menahan fitur keamanan, praktik terbaik, dan otomatisasi dari orang yang sudah menjadi pelanggan itu mengerikan, tetapi itulah yang nyaris menjadi standar saat ini
      Dalam kenyataan seperti itu, jika seseorang di perusahaan membutuhkan SAML, mungkin masuk akal membayar sekitar setengah dari biaya yang dibayarkan untuk satu fitur ini di satu aplikasi SaaS
      [1]: https://sso.tax/
    • Berdasarkan pengalaman 10 tahun terakhir, rasanya saya tidak akan pernah lagi membangun di atas proyek open source yang didanai VC. Menurut saya keduanya sulit berjalan bersama
      Bukan berarti tidak bisa membuat bisnis yang kuat dengan open source. Red Hat berhasil melakukannya, tetapi menurut saya harus memakai model itu, bukan model pendanaan VC tahap seed
    • Kekhawatiran itu sepenuhnya saya pahami, valid, dan sering kami dengar
      Mungkin logika komersialnya tidak meyakinkan, tetapi kami sedang membuat taruhan terhitung bahwa penawaran gratis yang murah hati akan menguntungkan dalam jangka panjang
      Kami melihat produk ini akan membangun kepercayaan developer dan di masa depan menjadi kanal distribusi yang efisien. Strategi open source komersial yang tidak dimonetisasi pada tahap awal cukup umum
      Untungnya, ada sebagian investor ventura yang bersedia mendukung perusahaan dengan produk open source komersial yang populer
      Kami masih perusahaan tahap awal, dan berencana memperdalam produk yang ada serta menyediakan produk baru seiring waktu. Kami akan mengenakan biaya untuk fitur dan produk baru, dan kami merasa tidak masalah meski butuh beberapa tahun sampai pendapatan atau arus kas menjadi berarti

  • Merilisnya sebagai open source dan meluncurkan layanan yang mudah dipakai patut dipuji
    Sebagai tambahan, jika ini menjadi implementasi yang populer dan berkualitas tinggi, penyedia layanan lain juga bisa lebih mudah berintegrasi dengan pengguna perangkat lunak ini
    Saya beberapa kali mengimplementasikan integrasi SSO F500 dari nol, dan karena masing-masing dibuat khusus, meskipun disebut “SAML” belum tentu saling interoperabel. Dengan perangkat lunak seperti ini, mungkin bisa berjalan secara default
    Saya penasaran seberapa baik mereka bisa menjaga keamanan saat menyediakan SSO hosting gratis agar pelanggan tidak dikompromikan melalui pihak mereka
    Saya juga penasaran ini akan menjadi single point of failure bagi semua pelanggan, jadi apakah tier gratis juga memiliki jaminan uptime. Saya juga penasaran apakah mereka bisa menawarkannya dengan harga terjangkau untuk startup yang menginginkan hosting tetapi membutuhkan SLA

    • Keamanan SSO hosting gratis benar-benar penting. Tidak ada jawaban singkat; ini sekadar soal melakukan hal-hal yang memang harus dilakukan dengan benar
      Untuk SOC2, kami bekerja dengan Oneleet, dan kita semua tahu SOC2 sebagian besar adalah sandiwara, tetapi kami juga sedang menjalankan penetration test yang cukup menyeluruh. Jika mau, kami bisa mengirim hasilnya lewat email
      Secara realistis, kami adalah perusahaan yang memang harus melakukan hal-hal seperti ini dengan benar
      Jaminan uptime untuk tier gratis rencananya akan disepakati kasus per kasus, dan bergantung pada kebutuhan. Kami menganggap jaminan cukup serius, jadi berhati-hati dalam membuat janji
      Kami tidak berniat menjadi bisnis jasa dan juga tidak ingin menghasilkan uang dari “dukungan premium”. Namun jika menginginkan SLA, akan ada biaya kecil
      Pertanyaan “apakah penyedia cloud akan mengambil pelanggan yang memakai perangkat lunak ini” sebaiknya diutarakan ulang

  • Hambatan terbesar SAML belakangan ini sepertinya adalah integrasi produk SaaS. Saya sering mengalami situasi harus bolak-balik email dengan tim dukungan, dan ada vendor yang bahkan mengirim begitu saja PDF 204 halaman yang khusus membahas penyiapan SSO
    Pemetaan atribut masih tetap berantakan, dan mengejutkan bahwa pengalaman pengguna masih seburuk ini

    • Saya pernah menulis PDF 204 halaman seperti itu. Sebenarnya mungkin sekitar 20 halaman, tetapi karena IdP tidak membuatnya mudah bagi pelanggan untuk menyiapkannya, akhirnya penyedia layanan—yaitu kami—harus mendokumentasikan cara pelanggan menggunakan IdP mereka sendiri
      Kebetulan kami baru merilis fitur untuk masalah ini. Alih-alih harus membuat PDF 204 halaman, Anda bisa membuat URL konfigurasi di SSOReady dan memberikannya kepada pelanggan; pelanggan lalu membuka URL itu dan menyiapkan koneksi SAML dengan produk melalui UI layanan mandiri
      https://ssoready.com/docs/idp-configuration/enabling-self-se...
    • Dukungan SSO memakan lebih dari 50% waktu dukungan pelanggan tim engineering kami
      Salah satu kesulitan terbesar adalah pengguna harus melibatkan departemen lain yang benar-benar memiliki sistem SSO, dan departemen itu tidak punya banyak insentif untuk segera membuatnya berfungsi, sehingga tiket sering berlarut-larut
      Kami juga terlihat buruk karena harus meminta informasi tertentu dari pelanggan
    • OKTA melakukannya cukup baik, tetapi Anda harus bisa mengeluarkan biaya di kisaran 20 ribu dolar AS per tahun atau lebih

  • Keren. Saya penasaran dengan bagian “berencana memonetisasi di masa depan dengan membuat fitur tambahan untuk perusahaan besar yang punya kebutuhan kompleks”
    Saya penasaran apakah pada proses aplikasi YC, hal seperti ini saja sudah cukup untuk diterima, dan seberapa besar mereka menekankan model bisnis untuk investasi

    • Sejujurnya, saat diterima di YC kami sedang mengerjakan proyek lain. Kami ingin membuat perangkat lunak pembersihan data dengan LLM, sampai kami menyadari bahwa tidak ada yang terlalu peduli dengan data yang berantakan
      Salah satu alasan kami nyaman memberi paket gratis yang murah hati adalah fakta mendasar bahwa membantu perusahaan SaaS mendukung login SAML bukanlah pasar yang begitu besar. Bagaimanapun, kami harus menghasilkan uang dari produk lain
      “Monetisasi fitur tambahan” merujuk pada produk SAML yang kami tawarkan saat ini, tetapi kami juga akan meluncurkan produk lain
      Tujuan jangka panjangnya adalah membangun perusahaan yang mirip Auth0, tetapi open source dan ramah developer

  • Ini tepat waktu karena saya sedang mencari alternatif yang lebih hemat biaya daripada WorkOS. Saya sedang membangun portal validasi data enterprise dan berencana mencobanya
    Saya penasaran apakah ada panduan yang bisa dijadikan rujukan begitu berintegrasi dengan Entra ID. Benarkah hanya perlu endpoint API?

    • Halo, saya Ned, co-founder SSOReady yang lain
      Betul. Kode yang perlu ditulis mencakup semua IdP, dan perbedaan spesifik IdP ditangani lewat nilai konfigurasi tiap pelanggan
      Misalnya, belum lama ini kami merapikan dokumentasi khusus Entra: https://ssoready.com/docs/idp-configuration/guides-for-commo...
      Saya penasaran apakah ini memenuhi kebutuhan Anda
    • Saya founder WorkOS
      Kami punya diskon volume otomatis untuk pengguna pay-as-you-go, dan paket tahunan atau kontrak khusus juga bisa mendapat harga lebih rendah. Kami juga menyediakan kredit gratis untuk perusahaan tahap awal
      Kalau ingin berdiskusi, silakan hubungi mg@workos.com
      Saat ini ratusan perusahaan, termasuk banyak startup, menggunakan WorkOS: https://workos.com/startups

  • Di perusahaan sebelumnya saya mengimplementasikan integrasi SSO, tetapi SAML terlihat sangat menyakitkan sehingga kami hanya memakai OIDC2
    Saya tidak tahu apakah sekarang masih begitu, tetapi untuk beberapa waktu Okta tidak mengizinkan OIDC untuk SSO pada integrasi Okta yang memakai SCIM, dan harus memakai SAML untuk SSO
    Kami mengakalinya dengan membuat dua integrasi Okta terpisah, satu untuk SSO dan satu untuk SCIM. Selalu merepotkan menjelaskannya ke departemen IT pelanggan, tetapi tidak ada yang mempermasalahkan, jadi kami tidak perlu mengimplementasikan SAML

  • Kelihatannya bagus. Saya penasaran apakah ada rencana menambahkan SCIM
    SAML memang bagus, tetapi dari pengalaman saya, salah satu alasan utama pelanggan enterprise menginginkan SSO adalah deprovisioning otomatis untuk mencabut akses dari semua aplikasi sekaligus saat karyawan keluar. Untuk itu diperlukan SCIM
    Dengan SAML plus SCIM, atau bahkan subset kecil SCIM saja, rasanya ini hampir menjadi pilihan tanpa perlu banyak berpikir. Layanan lain tertutup dan luar biasa mahal, sedangkan mengimplementasikannya sendiri sangat menyakitkan

    • SCIM akan segera ditambahkan. Menurut kami fitur terkait deprovisioning otomatis dan manajemen seat adalah motivasi besar
      Sejujurnya, IETF membuat SCIM itu sendiri dengan cukup baik. Tidak seaneh SAML. Dari pengalaman, bagian tersulit integrasi SCIM adalah menyesuaikan konfigurasi per IdP
      Sama seperti SAML, Okta, Microsoft, dan OneLogin menyebut hal yang persis sama dengan istilah yang sepenuhnya berbeda
      Salah satu fitur yang kami nantikan adalah tombol untuk membuat tautan konfigurasi yang bisa diberikan kepada pelanggan. Melalui tautan itu, pelanggan bisa menyiapkan konfigurasi SAML+SCIM secara layanan mandiri
      Saat ini di SAML fitur itu sudah berfungsi, dan enaknya kami tidak perlu menulis dokumentasi terpisah per IdP untuk menjelaskan istilah aneh dan UI unik tiap produk

  • Selamat atas peluncurannya. Dibandingkan dengan SAML Jackson[1] dari BoxyHQ, bagaimana?
    [1]: https://github.com/boxyhq/jackson

    • Menurut saya BoxyHQ melakukan pekerjaannya dengan baik
      Pada dasarnya ada dua alasan kami lebih menyukai pendekatan kami
      Pertama, BoxyHQ menginginkan SAML-over-OAuth. Kami mendukung ini, terutama untuk kompatibilitas NextAuth, tetapi kami tidak selalu menganggapnya membantu
      Kedua, menurut kami layanan kami lebih mudah digunakan. Keluhan yang paling sering kami dengar dari pengguna dan pelanggan adalah kompleksitas, jadi kami berusaha keras membuat SAML jelas dan sederhana. Pada akhirnya, pengguna yang akan menilai apakah standar itu terpenuhi

  • Saya sedang menulis custom policy pertama untuk IdP B2C Microsoft, dan prosesnya menyakitkan
    Jika autentikasi dan SSO dibuat tidak terlalu menyakitkan, dunia benar-benar bisa menjadi lebih baik. Aplikasi jadi lebih aman, orang-orang tidak terlalu frustrasi saat menggunakannya, dan stres orang seperti saya juga berkurang

    • Jika dipikir-pikir, membuat “autentikasi dan SSO tidak terlalu menyakitkan” bisa dibilang adalah hal yang berhasil dilakukan oleh OAuth2 + OIDC. Perusahaan seperti Atlassian memahami hal ini
      http://id.atlassian.com