Launch HN: SSOReady (YC W24) - SAML SSO’yu kolay ve açık kaynak hâle getiren teknoloji

 (github.com/ssoready)
2 puan yazan GN⁺ 2024-08-01 | 1 yorum | WhatsApp'ta paylaş
  • SSOReady, ürününüze SAML tabanlı Enterprise SSO ve SCIM tabanlı Enterprise Directory Sync eklemek için açık kaynak bir araçtır; müşterilerin kendi kendine onboarding yapabileceği barındırılan bir kurulum arayüzü de sunar
  • Her türlü uygulama stack’inde kullanılabilmesi için temelde HTTP API’yi esas alır; TypeScript, Python, Go, Java, C#, Ruby ve PHP için SDK’ları ince sarmalayıcılar olarak sağlar
  • SAML login, yönlendirme URL’si oluşturma ve erişim kodu değiş tokuşundan oluşur; SCIM ise kullanıcı listesini kuruluş dış kimliğiyle getirme yöntemiyle uygulama akışını basitleştirir
  • SSOReady, bir authentication middleware katmanı olarak çalışır; kullanıcıları sahiplenmez veya mevcut kullanıcı veritabanında değişiklik gerektirmez, bulut barındırma ya da self-hosting seçilebilir
  • Enterprise planı custom domain ve branding, Management API, SLA desteği sunar; MIT lisansı ise fiyat artışlarına karşı bir denge unsuru olarak fork etme olasılığını açık tutar

SSOReady’nin sunduğu özellikler

  • SSOReady, ürününüze SAML ve SCIM desteği eklemek için geliştirilmiş açık kaynak bir projedir
  • Başlıca üç bileşenden oluşur
    • SSOReady SAML: Ürüne SAML, yani Enterprise SSO eklemek için gereken işlevler
    • SSOReady SCIM: Ürüne SCIM, yani Enterprise Directory Sync eklemek için gereken işlevler
    • Self-serve Setup UI: Müşterilerin SAML veya SCIM kurulumunu kendi kendilerine onboarding yapabildiği barındırılan arayüz
  • Hızlı başlangıç dokümanları SAML Quickstart ve SCIM Quickstart olarak ayrılır
  • README, çoğu kullanıcının SAML ve SCIM’i bir öğleden sonra içinde uyguladığını ve yalnızca iki satır kod gerektiğini belirtir

Stack bağımsızlığı ve dağıtım seçenekleri

  • SSOReady belirli bir uygulama stack’ine bağlı değildir; dile özel SDK’lar, sezgisel bir HTTP API üzerinde ince sarmalayıcılar olarak sunulur
  • Sağlanan SDK’lar şunlardır
  • SSOReady bir authentication middleware katmanı olarak çalışır; kullanıcıları sahiplenmez ve mevcut kullanıcı veritabanında değişiklik gerektirmez
  • Dağıtım yöntemi olarak bulutta barındırılan bir instance kullanımı veya self-hosting seçilebilir
  • Enterprise planı, hem bulut hem de self-hosting için SLA desteği sağlar

SAML uygulama akışı

  • SAML, yani Enterprise SSO, iki adımdan oluşur
    • Kullanıcıyı şirketin Identity Provider’ına yönlendiren başlangıç adımı
    • Kullanıcının kim olduğunu doğruladıktan sonra login yaptıran işleme adımı
  • Login başlatmak için Get SAML Redirect URL endpoint’i kullanılır
    • organizationExternalId alanına kuruluş, workspace, ekip vb. ürününüzde kullandığınız istediğiniz ID’yi koyabilirsiniz
    • Bu ID SSOReady içinde yapılandırılır; SSOReady ilgili kuruluşun SAML ve SCIM ayarlarının takibini yönetir
  • Login işleme için Redeem SAML Access Code endpoint’i kullanılır
    • /ssoready-callback handler’ında samlAccessCode değiş tokuş edilerek email ve organizationExternalId alınır
    • Ürün, dönen e-posta adresiyle ilgili kuruluş içinde login yaptırabilir
  • /ssoready-callback endpoint URL’si SSOReady’de yapılandırılır

SCIM uygulama akışı

  • SCIM, yani Enterprise Directory Sync, müşterinin çalışan listesini çevrimdışı alma yöntemi olarak tanıtılır
  • Müşterinin çalışanlarını getirmek için List SCIM Users endpoint’i kullanılır
  • İstekte organizationExternalId kullanılır; yanıtta scimUsers ve nextPageToken bulunur
  • Her SCIM kullanıcısı email, deleted, attributes gibi değerler içerir; ürün bunlara dayanarak kullanıcı oluşturabilir veya işleyebilir

Enterprise özellikleri ve proje felsefesi

  • Enterprise planında genişletilmiş özellikler kullanılabilir
    • Custom Domains & Branding: SSOReady’yi kullanıcının kontrol ettiği bir domain üzerinde çalıştırma ve SAML/SCIM deneyimini markaya uyarlama
    • Management API: SAML ve SCIM ile ilgili işleri programatik biçimde büyük ölçekte otomatikleştirme
    • Enterprise Support: Self-hosting dağıtımları dahil SLA desteği
  • Projenin varsayımı, iş yazılımı satan her ürünün Enterprise SSO desteklemesi gerektiği ve bunun müşteriler için büyük bir güvenlik avantajı olduğu yönündedir
  • Mevcut açık kaynak SAML kütüphanelerinin dokümantasyonunun yetersiz ve kafa karıştırıcı olduğu düşünülür; SSOReady, net ve varsayılan olarak güvenli bir uygulama deneyimi hedefler
  • Güvenlik yazılımının fiyatını keyfi şekilde büyük ölçüde artırmanın kabul edilemez olduğu yaklaşımıyla SSOReady MIT lisansı altında sunulur
  • Güvenlik sorunlarının security@ssoready.com adresine bildirilmesi istenir

İlgili okumalar

1 yorum

 
GN⁺ 2024-08-01
Hacker News yorumları

  • Şans dilemekten başka bir şey yok. Geçmişte bizzat bir IdP yaptım; tek oturum açma, tek oturum kapatma, kullanıcı provizyonlama gibi birçok özelliği uyguladım. Gerçekten çalıştığında gülümseten bir sihir gibi geliyor
    Birçok hizmet sağlayıcıyla ve farklı IdP’lerle türlü türlü entegrasyon yaptık, özellikler de iyiydi; ama tek bir not: bu asla acısız bir iş değildi
    Dünyanın en iyi IdP’sini yapsanız bile karşı taraf bir kara kutu; payload boşluğa gönderildikten sonra neden tüketildiğini çoğu zaman bilemiyorsunuz
    Üstelik entegrasyon yaptığınız taraf çoğu zaman SAML akışını, payload’ını, hatta kendi stack’indeki SAML özelliklerini bile bilmiyor; karşı tarafa öğretirken aynı anda o sistemi de öğrenmeniz gerekiyor
    İmza ya da format gibi kaygılardan çok kara kutu teşhisi ve bitmek bilmeyen sertifika yönetimi kara deliği gibi işler ağırlıktaydı

    • Ne yazık ki bu durum birçok protokolde yaşanıyor. IPSec’te, HL7v2’de, hatta CSV’de bile gördüm
      Özellikle IPSec çok yara bıraktı; VPN tünelinin ayakta olup olmadığını kontrol etmek için tek bir TCP bağlantısı bile açamayan “ağ mühendisleriyle” çalışırken “karşı tarafla entegrasyon gerçekten olacak mı?” diye içiniz içinizi yiyor
      Sonunda mümkün olduğunca hızlı şekilde karşı sistemi öğrenip ayarların doğru olup olmadığına karar vermek ve kaçınılmaz entegrasyon sorunlarını bulmak gerekiyordu. Neredeyse her zaman sebep bir yerlerdeki güvenlik duvarı oluyordu
      Kurumsal cihazların standart terimleri kendilerine özgü yeni kelimelerle adlandırması da sorun; öğrenmenin büyük kısmı, karşı taraftaki “appliance”ın şu ya da bu terime ne dediğine dair zihinde bir Rosetta taşı oluşturmaya dönüşüyor
    • Kendi posta sunucunuzu işletmeye benziyor. SPF, DMARC, DKIM’i düzgün ayarlayıp A/AAAA/TXT/MX kayıtlarının tüm dünyaya yayılmasını sağlasanız ve mail-tester.com gibi harici araçlarla testleri tamamlasanız bile, şimdi karşınıza “diğer posta sunucuları” diye yeni bir dünya açılıyor
      Bazı posta sunucuları sorunsuz kabul ediyor; bazılarıysa tuhaf politikalar ve katı engelleme listeleri işletiyor, alan adı ya da gönderici bazında ayrı itibar yönetiyor
    • “Çalıştığında sihir gibi ve gülümsetiyor” dedikten hemen sonra “hiç acısız olmadı, hep diş çektirmek gibiydi” derseniz, arada not olsa bile yanlış anlaşılmaya yol açabilir
      Muhtemelen amaç satış yaratmak; bunda sorun yok, ama bir dahaki sefere ifadeyi biraz cilalamak iyi olur

  • Harika görünüyor. SAML uygulamış biri olarak gerçekten acı vericiydi; bu araç çok daha kolay görünüyor
    Yine de fiyatlandırma konusunda biraz endişeliyim. Sistemimizi bu aracın üzerine inşa etmemiz gerekeceği için, ileride şirket batarsa ya da fiyat politikası bizim aleyhimize değişirse SSO’yu yeniden yazmak gibi büyük bir mühendislik işi bir anda ortaya çıkar
    Barındırılan ürünü ücretsiz sunuyorlarsa sonunda batma ya da fiyatı değiştirme ihtimalleri epey yüksek görünüyor
    Önümüzdeki 6-12 ay içinde mevcut projeye SSO eklemek zorunda olan biri olarak, “şimdilik ücretsiz” ve “emin değiliz, bize e-posta verin” dışında sürdürülebilir görünen ücretli bir plan olursa bunu ekibe kabul ettirmek çok daha kolay olur

    • %100 katılıyorum. SAML, uygulamanın geçidi; ileride bu şirketin ücretli ürününü satın alma niyetiniz yoksa ücretsiz üründe premium destek beklenen bir yapı bana cazip gelmiyor
      Seçeneklerden birinin “kurucuyu arayın” olduğunu da unutmamak gerek
    • Zaten SSO vergisi[1] diye bir şey var. Güvenlik özelliklerini, en iyi uygulamaları ve otomasyonu zaten müşteri olan insanlardan esirgemek korkunç, ama mevcut standarda yakın olan da bu
      Bu gerçeklikte, şirkette SAML’e ihtiyaç duyan biriyseniz, tek bir SaaS uygulamasında bu tek özellik için ödediğinizin yaklaşık yarısını ödemek makul olabilir
      [1]: https://sso.tax/
    • Son 10 yıldaki deneyimime göre bir daha VC yatırımlı açık kaynak projelerin üzerine bir şey inşa etmem gibi geliyor. İkisinin bağdaşmasının zor olduğunu düşünüyorum
      Açık kaynakla sağlam bir iş kurulamaz demek istemiyorum. Red Hat bunu başardı; ama gidilecek model o olmalı, seed aşaması VC finansmanı modeli değil
    • Kaygıyı tamamen anlıyorum; geçerli ve sık duyduğumuz bir konu
      Ticari mantığı ikna edici bulmayabilirsiniz, ama cömert bir ücretsiz sunumun uzun vadede fayda sağlayacağına dair hesaplanmış bir bahis yapıyoruz
      Bu ürünün geliştirici güveni oluşturacağını ve gelecekte verimli bir dağıtım kanalı olacağını düşünüyoruz. Başlangıçta gelir elde etmeyen ticari açık kaynak stratejileri oldukça yaygın
      Neyse ki popüler bir ticari açık kaynak ürünü olan şirketleri desteklemeye istekli bazı girişim yatırımcıları da var
      Henüz erken aşama bir şirketiz; mevcut ürünü daha derinleştirecek ve zamanla yeni ürünler de sunacağız. Yeni özellikler ve yeni ürünler için ücret alacağız; anlamlı gelir ya da nakit akışına ulaşmak birkaç yıl sürse de sorun olmadığını düşünüyoruz

  • Açık kaynak olarak yayımlayıp kullanımı kolay bir hizmet çıkarmak övgüye değer
    Ek olarak, bu popüler ve kaliteli bir implementasyon hâline gelirse diğer hizmet sağlayıcıların bu yazılımın kullanıcılarıyla entegrasyon yapması da kolaylaşabilir
    F500 SSO entegrasyonlarını birkaç kez sıfırdan uyguladım; herkes kendine göre özelleştirdiği için adına “SAML” denmesi mutlaka birlikte çalışacağı anlamına gelmiyordu. Böyle bir yazılımla varsayılan olarak çalışabilir
    Ücretsiz barındırılan SSO sunarken müşterilerin o taraf üzerinden ele geçirilmemesi için güvenliği ne kadar iyi sağlayabileceklerini merak ediyorum
    Ayrıca tüm müşteriler için tekil arıza noktası olacak; ücretsiz katmanda çalışma süresi garantisi olup olmadığını da merak ediyorum. Barındırma isteyen ama SLA’ya ihtiyaç duyan startup’lara karşılanabilir bir fiyatla sunup sunamayacaklarını da merak ediyorum

    • Ücretsiz barındırılan SSO’nun güvenliği gerçekten önemli. Kısa bir cevap yok; sadece yapılması gerekenleri doğru yapmak meselesi
      SOC2 konusunda Oneleet ile çalışıyoruz; SOC2’nin büyük ölçüde tiyatro olduğunu hepimiz biliyoruz, ama oldukça kapsamlı bir penetrasyon testi de yürütüyoruz. İsterseniz sonuçları e-postayla gönderebiliriz
      Gerçekçi olmak gerekirse, biz bu işleri doğru yapmak zorunda olan bir şirketiz
      Ücretsiz katmanda çalışma süresi garantisini vaka bazında kararlaştırmayı planlıyoruz; gereken içeriğe göre değişir. Garantileri oldukça ciddiye aldığımız için taahhütlerde dikkatliyiz
      Bir hizmet işi yapmak istemiyoruz ve “premium destekten” para kazanmak da istemiyoruz. Ancak SLA istenirse küçük bir ücret var
      “Bulut sağlayıcısı bu yazılımı kullanan müşterileri kapacak mı?” sorusunu yeniden ifade ederseniz iyi olur

  • Bugünlerde SAML’in önündeki en büyük engel SaaS ürün entegrasyonu gibi görünüyor. Destek ekipleriyle e-posta trafiğine girmek zorunda kaldığım çok oldu; hatta bazı sağlayıcılar yalnızca SSO kurulumunu anlatan 204 sayfalık bir PDF’i olduğu gibi göndermişti
    Öznitelik eşleme hâlâ karmakarışık ve kullanıcı deneyiminin hâlâ bu kadar kötü olması şaşırtıcı

    • Geçmişte böyle 204 sayfalık bir PDF yazmışlığım var. Gerçekte muhtemelen 20 sayfa civarındaydı ama IdP’ler müşterilerin kolayca yapılandırabileceği şekilde tasarlamadığı için sonunda hizmet sağlayıcı olarak biz, müşteriye kendi IdP’sini nasıl kullanacağını belgelemek zorunda kalıyoruz
      Tam da bu sorun için bir özellik yayımladık. 204 sayfalık PDF hazırlamak yerine SSOReady’de bir kurulum URL’si oluşturup müşteriye verebiliyorsunuz; müşteri de o URL’ye giderek ürününüzle SAML bağlantısını self-servis UI üzerinden yapılandırabiliyor
      https://ssoready.com/docs/idp-configuration/enabling-self-se...
    • SSO desteği, mühendislik ekibimizin müşteri destek zamanının %50’den fazlasını alıyordu
      En büyük zorluklardan biri, kullanıcının gerçek SSO sistemine sahip başka bir departmanı sürece dahil etmek zorunda kalmasıydı; o departmanın da bunu hızlıca çalışır hale getirmek için pek motivasyonu olmadığından ticket’lar uzayıp gidiyordu
      Müşteriden belirli bilgileri istememiz gerektiği için biz de kötü görünüyorduk
    • OKTA bunu epey iyi yapıyor ama yılda 20 bin dolar ve üzeri harcayabiliyor olmanız gerekiyor

  • Harika. “İleride gelir elde etmek için karmaşık ihtiyaçları olan büyük kurumsal müşterilere yönelik ek özellikler geliştirmeyi planlıyoruz” kısmını merak ettim
    YC başvuru sürecinde bunun kabul almak için yeterli olup olmadığını ve yatırım için iş modeline ne kadar önem verdiklerini merak ediyorum

    • Açıkçası YC’ye kabul edildiğimizde başka bir proje üzerinde çalışıyorduk. Kimsenin dağınık veriyi o kadar da umursamadığını fark edene kadar LLM’lerle veri temizleme yazılımı yapmak istiyordum
      Cömert bir ücretsiz kullanım sunmaktan rahat olmamızın nedenlerinden biri, SaaS şirketlerinin SAML login’i desteklemesine yardımcı olmanın tek başına çok büyük bir pazar olmadığı gerçeği. Zaten parayı başka ürünlerden kazanmamız gerekecek
      “Ek özelliklerden gelir elde etme” mevcut SAML ürünümüzle ilgili, ama başka ürünler de çıkaracağız
      Uzun vadeli hedefimiz Auth0 benzeri ama açık kaynaklı ve geliştirici dostu bir şirket kurmak

  • WorkOS’a göre daha maliyet etkin bir alternatif aradığım için tam zamanında oldu. Kurumsal veri doğrulama portalı geliştiriyorum ve deneyeceğim
    Entra ID ile entegre olur olmaz başvurabileceğim bir yönerge var mı merak ediyorum. Gerçekten yalnızca API endpoint’i yeterli mi?

    • Merhaba, ben SSOReady’nin diğer kurucu ortağı Ned
      Evet. Yazacağınız kod tüm IdP’leri kapsar; IdP’ye özgü farklar her müşterinin yapılandırma değerlerinde ele alınır
      Örneğin kısa süre önce Entra’ya özel dokümanı derledik: https://ssoready.com/docs/idp-configuration/guides-for-commo...
      İhtiyacınızı bunun karşılayıp karşılamadığını merak ediyorum
    • WorkOS’un kurucusuyum
      Kullandıkça öde kullanıcıları için otomatik hacim indirimleri var; yıllık planlarda veya özel sözleşmelerde daha düşük fiyatlar da mümkün. Erken aşama şirketlere ücretsiz kredi de sağlıyoruz
      Konuşmak istersen mg@workos.com adresinden ulaşabilirsin
      Şu anda birçok startup dahil yüzlerce şirket WorkOS kullanıyor: https://workos.com/startups

  • Önceki şirkette SSO entegrasyonu uygulamıştım; SAML o kadar sancılı görünüyordu ki yalnızca OIDC2 yaptım
    Hâlâ böyle mi bilmiyorum ama bir süre Okta, SCIM kullanan Okta entegrasyonlarında SSO için OIDC’ye izin vermiyordu; SSO için SAML kullanmak gerekiyordu
    Biz de SSO ve SCIM için iki ayrı Okta entegrasyonu oluşturarak etrafından dolaştık. Bunu müşteri BT departmanlarına açıklamak hep zahmetliydi ama kimse sorun etmediği için SAML uygulamak zorunda kalmadık

  • İyi görünüyor. SCIM ekleme planınız var mı merak ediyorum
    SAML iyi ama deneyimime göre büyük kurumsal müşterilerin SSO istemesinin başlıca nedenlerinden biri, çalışan ayrıldığında tüm uygulamalardan erişimi tek seferde kaldıran otomatik deprovisioning. Bunun için SCIM gerekiyor
    SAML’e ek olarak SCIM, hatta SCIM’in küçük bir alt kümesi bile olsa neredeyse hiç düşünmeden seçilecek bir seçenek olurdu. Diğer hizmetler kapalı kaynaklı ve fahiş pahalı; kendin uygulamak ise büyük eziyet

    • SCIM yakında eklenecek. Otomatik deprovisioning ve koltuk yönetimiyle ilgili özelliklerin büyük motivasyon olduğunu düşünüyorum
      Açıkçası IETF, SCIM’in kendisini oldukça iyi tasarlamış. SAML kadar tuhaf değil. Deneyimime göre SCIM entegrasyonlarında en zor kısım IdP’ye özgü ayarları tutturmak
      SAML’de olduğu gibi Okta, Microsoft ve OneLogin tamamen aynı şeye bambaşka terimlerle ad veriyor
      Beklediğimiz özelliklerden biri, müşteriye verebileceğiniz bir kurulum bağlantısı oluşturma düğmesi. Bu bağlantı üzerinden müşteri SAML+SCIM yapılandırmasını self-servis olarak ayarlayabilecek
      Şu anda SAML’de zaten çalışıyor ve her ürünün garip terminolojisini ve kendine özgü UI’ını açıklayan IdP’ye özel dokümanlar ayrıca yazmak zorunda kalmamak güzel

  • Lansmanınız kutlu olsun. BoxyHQ’nun SAML Jackson[1]’ı ile karşılaştırınca nasıl?
    [1]: https://github.com/boxyhq/jackson

    • BoxyHQ’nun iyi iş çıkardığını düşünüyorum
      Bizim yaklaşımımızı tercih etmemin temelde iki nedeni var
      Birincisi, BoxyHQ SAML-over-OAuth istiyor. Biz bunu özellikle NextAuth uyumluluğu için destekliyoruz ama bunun her zaman faydalı olduğunu düşünmüyorum
      İkincisi, hizmetimizin kullanımının daha kolay olduğunu düşünüyorum. Kullanıcılardan ve müşterilerden en sık duyduğumuz şikâyet karmaşıklık olduğu için SAML’i açık ve basit hale getirmek için çok uğraşıyoruz. Sonuçta bu çıtayı karşılayıp karşılamadığımıza kullanıcılar karar verecek

  • Microsoft’un B2C IdP’si için ilk özel ilkemi yazıyorum ve acı verici bir süreç
    Kimlik doğrulama ve SSO’yu daha az sancılı hâle getirmek gerçekten dünyayı daha iyi bir yer yapabilir. Uygulamalar daha güvenli olur, insanlar kullanırken daha az bunalır, benim gibi insanların stresi de azalır

    • “Kimlik doğrulama ve SSO’yu daha az sancılı” hâle getirme işini, aslında OAuth2 + OIDC’nin başardığı şey olarak görebiliriz. Atlassian gibi şirketler bunu anlamış
      http://id.atlassian.com