Launch HN: SSOReady (YC W24) - SAML SSO को आसान और open source बनाने वाली तकनीक

 (github.com/ssoready)
2 पॉइंट द्वारा GN⁺ 2024-08-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SSOReady आपके product में SAML-आधारित Enterprise SSO और SCIM-आधारित Enterprise Directory Sync जोड़ने के लिए एक open source tool है, जो ग्राहकों को खुद onboarding करने के लिए hosted setup UI भी देता है
  • किसी भी application stack में इस्तेमाल हो सके, इसलिए HTTP API को आधार बनाया गया है, और TypeScript·Python·Go·Java·C#·Ruby·PHP के SDK पतले wrappers के रूप में दिए गए हैं
  • SAML login redirect URL बनाने और access code exchange करने से बना है, जबकि SCIM संगठन के external ID से users की सूची लाने के तरीके से implementation flow को सरल बनाता है
  • SSOReady authentication middleware layer की तरह काम करता है; यह users को own नहीं करता और मौजूदा user database में बदलाव की मांग नहीं करता, और cloud hosting या self-hosting में से चुनने का विकल्प देता है
  • Enterprise plan custom domain·branding, Management API, SLA support देता है, और MIT license price बढ़ोतरी पर नियंत्रण के साधन के रूप में fork की संभावना खुली रखता है

SSOReady क्या सुविधाएँ देता है

  • SSOReady product में SAML और SCIM support जोड़ने के लिए एक open source project है
  • इसके मुख्य हिस्से तीन हैं
    • SSOReady SAML: product में SAML, यानी Enterprise SSO जोड़ने के लिए जरूरी functionality
    • SSOReady SCIM: product में SCIM, यानी Enterprise Directory Sync जोड़ने के लिए जरूरी functionality
    • Self-serve Setup UI: customers को SAML या SCIM settings खुद onboard करने देने वाला hosted UI
  • quick start docs SAML Quickstart और SCIM Quickstart में बंटे हैं
  • README बताता है कि ज्यादातर users SAML और SCIM को आधे दिन में implement कर लेते हैं, और सिर्फ दो lines of code चाहिए होती हैं

Stack independence और deployment विकल्प

  • SSOReady किसी खास application stack से बंधा नहीं है, और language-specific SDKs एक सहज HTTP API के ऊपर पतले wrappers के रूप में दिए जाते हैं
  • उपलब्ध SDK ये हैं
  • SSOReady authentication middleware layer की तरह काम करता है; यह users को own नहीं करता और मौजूदा user database में बदलाव की मांग नहीं करता
  • deployment के लिए cloud-hosted instance इस्तेमाल करने या self-hosting में से चुना जा सकता है
  • Enterprise plan cloud और self-hosting, दोनों के लिए SLA support देता है

SAML implementation flow

  • SAML, यानी Enterprise SSO, दो steps से बना है
    • शुरुआत का step, जिसमें user को कंपनी के Identity Provider पर redirect किया जाता है
    • processing step, जिसमें यह verify करके login कराया जाता है कि user कौन है
  • login शुरू करने के लिए Get SAML Redirect URL endpoint का इस्तेमाल होता है
    • organizationExternalId में आप product में इस्तेमाल होने वाली अपनी पसंद की ID डाल सकते हैं, जैसे organization, workspace, team आदि
    • यह ID SSOReady के अंदर set की जाती है, और SSOReady उस organization की SAML·SCIM settings की tracking संभालता है
  • login process करने के लिए Redeem SAML Access Code endpoint का इस्तेमाल होता है
    • /ssoready-callback के handler में samlAccessCode exchange करके email और organizationExternalId मिलते हैं
    • product को returned email को उस organization के अंदर login करा देना चाहिए
  • /ssoready-callback endpoint URL SSOReady में set किया जाता है

SCIM implementation flow

  • SCIM, यानी Enterprise Directory Sync, ग्राहक के employees की सूची offline लाने के तरीके के रूप में पेश किया गया है
  • ग्राहक के employees लाने के लिए List SCIM Users endpoint का इस्तेमाल होता है
  • request में organizationExternalId इस्तेमाल होता है, और response में scimUsers और nextPageToken शामिल होते हैं
  • हर SCIM user में email, deleted, attributes जैसी values शामिल होती हैं, और product इनके आधार पर users बना या process कर सकता है

Enterprise features और project philosophy

  • Enterprise plan में extended features इस्तेमाल किए जा सकते हैं
    • Custom Domains & Branding: SSOReady को user-controlled domain पर चलाना और SAML·SCIM experience को brand के अनुसार customize करना
    • Management API: SAML और SCIM से जुड़े tasks को programmatic तरीके से बड़े पैमाने पर automate करना
    • Enterprise Support: self-hosting deployment सहित SLA support
  • project का premise यह है कि business software बेचने वाले हर product को Enterprise SSO support करना चाहिए, और यह customers के लिए बड़ा security benefit है
  • मौजूदा open source SAML libraries में documentation की कमी और confusion होने की समस्या मानी गई है, और SSOReady का लक्ष्य एक स्पष्ट और default रूप से सुरक्षित implementation experience देना है
  • security software की कीमत मनमाने ढंग से बहुत ज्यादा बढ़ाना स्वीकार्य नहीं है—इस रुख के तहत SSOReady MIT license के तहत उपलब्ध है
  • security issues security@ssoready.com पर report करने के लिए कहा गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-01
Hacker News की राय

  • शुभकामनाएँ ही दे सकता हूँ। पहले मैंने खुद एक IdP बनाया था, और single login, single logout, user provisioning जैसी कई सुविधाएँ implement की थीं; जब यह सच में काम करता है तो यह इतना जादू जैसा लगता है कि हँसी आ जाती है
    कई service providers और अलग-अलग IdP तक हर तरह के integration किए, और features भी अच्छे थे, लेकिन एक बात पक्की थी कि यह कभी भी बिना दर्द वाला काम नहीं था
    आप दुनिया का सबसे अच्छा IdP बना लें, फिर भी सामने वाला पक्ष black box होता है, इसलिए payload शून्य में भेजे जाने के बाद वह क्यों consume हुआ, यह कई बार पता नहीं चलता
    ऊपर से, integration वाला दूसरा पक्ष अक्सर SAML के flow, payload, अपने stack की SAML capability तक नहीं जानता, इसलिए आपको उन्हें सिखाते हुए साथ-साथ उस system को भी सीखना पड़ता है
    signature या format जैसी चिंताओं से ज़्यादा, ज़्यादातर काम black box diagnostics और अंतहीन certificate management के black hole जैसा था

    • दुर्भाग्य से ऐसी चीज़ें कई protocols में होती हैं। IPSec, HL7v2, यहाँ तक कि CSV में भी देखा है
      खासकर IPSec ने गहरे घाव दिए; VPN tunnel ज़िंदा है या नहीं यह check करने के लिए एक TCP connection तक नहीं खोल पाने वाले “network engineer” के साथ काम करते हुए अंदर ही अंदर जलता रहा कि “क्या उधर से integration हो भी पाएगा?”
      आखिरकार जितनी जल्दी हो सके सामने वाले system को सीखना पड़ा, यह समझने के लिए कि configuration सही है या नहीं, और unavoidable integration issues ढूँढने पड़े। लगभग हमेशा कहीं न कहीं firewall ही कारण होता था
      Enterprise devices का standard terms को अपने ही नए शब्दों में बदलकर बुलाना भी समस्या है, इसलिए ज़्यादातर learning सामने वाले “appliance” में किस term को क्या कहा जाता है, इसका दिमाग़ में Rosetta Stone बनाने जैसा बन जाता है
    • अपने mail server को चलाने जैसा है। SPF, DMARC, DKIM सही से set कर दिए, A/AAAA/TXT/MX records दुनिया भर में propagate हो गए, और mail-tester.com जैसे external tools से testing भी कर ली, फिर अब “दूसरे mail servers” नाम की नई दुनिया खुलती है
      कुछ mail servers अच्छी तरह accept करते हैं, लेकिन कुछ अजीब policies और सख्त block lists चलाते हैं और domain या sender-wise reputation अलग से manage करते हैं
    • अगर आप कहते हैं “काम करे तो जादू जैसा लगता है और हँसी आती है”, और तुरंत बाद कहते हैं “यह कभी भी बिना दर्द वाला नहीं रहा और हमेशा दाँत उखाड़ने जैसा था”, तो बीच में caveat होने के बावजूद गलतफहमी हो सकती है
      शायद इरादा revenue बनाने का होगा, और अपने आप में वह ठीक है, लेकिन अगली बार wording को थोड़ा refine करना बेहतर होगा

  • अच्छा लग रहा है। SAML implement कर चुके व्यक्ति के तौर पर यह सच में दर्दनाक था, लेकिन यह tool काफ़ी ज़्यादा आसान लगता है
    हालांकि pricing को लेकर थोड़ी चिंता है। हमें अपना system इस tool के ऊपर बनाना होगा, इसलिए बाद में अगर company बंद हो जाए या pricing policy बदलकर हमारे लिए unfavorable हो जाए, तो SSO को फिर से लिखने का बड़ा engineering काम अचानक पैदा हो जाएगा
    अगर hosted product free में दे रहे हैं, तो आखिरकार company के बंद होने या pricing बदलने की संभावना काफ़ी ज़्यादा लगती है
    अगले 6–12 महीनों में current project में SSO जोड़ने की स्थिति में, “अभी free है” और “पता नहीं, email दे दीजिए” के बजाय, अगर कोई sustainable दिखने वाला paid plan हो तो team को convince करना बहुत आसान होगा

    • 100% सहमत। SAML application का gateway है, इसलिए जब बाद में इस company का paid product खरीदने का इरादा नहीं है, तब free product पर premium support की उम्मीद वाली structure मुझे पसंद नहीं
      यह भी न भूलें कि options में से एक “founder को call करें” है
    • SSO tax[1] पहले से मौजूद है। Security features, best practices और automation को उन लोगों से रोककर रखना जो पहले से customers हैं, भयानक है, लेकिन अभी यही standard के काफ़ी करीब है
      ऐसी reality में, अगर company में किसी को SAML चाहिए, तो शायद single SaaS app में सिर्फ इसी feature के लिए चुकाई जाने वाली cost का लगभग आधा देना ठीक हो सकता है
      [1]: https://sso.tax/
    • पिछले 10 सालों के अनुभव के आधार पर, लगता है कि मैं VC-funded open source project के ऊपर फिर कभी build नहीं करूँगा। मुझे लगता है दोनों का साथ चलना मुश्किल है
      इसका मतलब यह नहीं कि open source से मजबूत business नहीं बनाया जा सकता। Red Hat ने किया, लेकिन model वही होना चाहिए; seed-stage VC funding model नहीं, मेरे हिसाब से
    • चिंता पूरी तरह समझता हूँ, यह वाजिब है और अक्सर सुनने को मिलती है
      हो सकता है commercial logic समझा न पाऊँ, लेकिन हम यह calculated bet लगा रहे हैं कि उदार free offering लंबी अवधि में लाभदायक होगी
      हमें लगता है कि यह product developer trust बनाएगा और भविष्य में efficient distribution channel बनेगा। शुरुआती दौर में monetization न करने वाली commercial open source strategy काफ़ी common है
      सौभाग्य से कुछ venture investors भी हैं जो popular commercial open source products वाली companies को खुशी से support करते हैं
      हम अभी शुरुआती stage की company हैं, मौजूदा product को और गहरा बनाएँगे और समय के साथ नए products भी देंगे। नई features और नए products पर charge करेंगे, और meaningful revenue या cash flow तक कुछ साल लगें तो भी हमें ठीक लगता है

  • Open source में release करना और इस्तेमाल में आसान service launch करना तारीफ़ के काबिल है
    अतिरिक्त रूप से, अगर यह popular और high-quality implementation बन जाता है, तो दूसरे service providers के लिए भी इस software के users के साथ integrate करना आसान हो सकता है
    F500 SSO integrations कई बार scratch से implement किए हैं, और सबने अपनी-अपनी customization कर रखी थी, इसलिए “SAML” कहा जाने पर भी ज़रूरी नहीं कि वे interoperable हों। ऐसा software हो तो शायद default रूप से काम कर जाए
    Free hosted SSO देते समय customers उस रास्ते से compromise न हों, इसके लिए आप कितनी अच्छी तरह security maintain कर पाएँगे, यह जानने की उत्सुकता है
    साथ ही यह सभी customers के लिए single point of failure बनेगा, तो free tier में भी uptime guarantee है या नहीं, यह जानना चाहूँगा। जिन startups को hosting चाहिए लेकिन SLA भी चाहिए, उन्हें affordable pricing पर दे पाएँगे या नहीं, यह भी सवाल है

    • Free hosted SSO की security सच में महत्वपूर्ण है। कोई short answer नहीं है; बस जो करना चाहिए उसे सही तरीके से करने की बात है
      SOC2 के लिए हम Oneleet के साथ काम कर रहे हैं, और हम सब जानते हैं कि SOC2 काफी हद तक नाटक है, लेकिन काफ़ी thorough penetration testing भी चल रही है। चाहें तो results email से भेज सकते हैं
      वास्तविकता यह है कि हम ऐसी company हैं जिसे ये चीज़ें सही तरीके से करनी ही होंगी
      Free tier की uptime guarantee case-by-case agree करने की योजना है, और यह जरूरतों पर निर्भर करेगा। हम guarantees को काफ़ी गंभीरता से लेते हैं, इसलिए commitments में सावधान रहते हैं
      हम services business करने नहीं निकले हैं और “premium support” से पैसे भी नहीं कमाना चाहते। लेकिन अगर SLA चाहिए, तो थोड़ी लागत होगी
      “क्या cloud provider इस software का इस्तेमाल करने वाले customers को ले जाएगा” वाले सवाल को फिर से phrasing कर दें तो अच्छा होगा

  • आजकल SAML की सबसे बड़ी बाधा शायद SaaS product integration है। कई बार support team के साथ ईमेल आगे-पीछे करने पड़े, और कुछ vendors तो सिर्फ SSO setup पर 204-page PDF वैसी की वैसी भेज देते थे
    Attribute mapping अभी भी गड़बड़ है, और यह हैरानी की बात है कि user experience अब भी इतना खराब है

    • मैंने पहले ऐसा 204-page PDF लिखा है। असल में शायद वह करीब 20 pages का था, लेकिन IdPs customers के लिए setup आसान नहीं बनाते, इसलिए आखिर में service provider, यानी हमें ही customers के लिए यह document करना पड़ता है कि वे अपना IdP कैसे इस्तेमाल करें
      संयोग से हमने इसी समस्या के लिए एक feature launch किया है। 204-page PDF बनाने की ज़रूरत नहीं; SSOReady में setup URL generate करके customer को दे दें, और customer उस URL पर जाकर product के साथ SAML connection को self-service UI से configure कर सकता है
      https://ssoready.com/docs/idp-configuration/enabling-self-se...
    • SSO support हमारी engineering team के customer support time का 50% से ज्यादा लेता था
      सबसे बड़ी मुश्किलों में से एक यह थी कि user को असली SSO system own करने वाली दूसरी department को शामिल करना पड़ता था, और उस department के पास इसे जल्दी चलाने की बहुत motivation नहीं होती थी, इसलिए ticket लंबे समय तक खिंचते रहते थे
      customer से कुछ खास जानकारी मांगनी पड़ती थी, जिससे हम भी बुरे दिखते थे
    • OKTA काफी अच्छा करता है, लेकिन इसके लिए सालाना 20,000 dollar से ऊपर खर्च कर पाने की क्षमता चाहिए

  • बढ़िया। “जटिल जरूरतों वाली बड़ी कंपनियों के लिए add-on features बनाकर आगे चलकर monetization करने की योजना” वाला हिस्सा दिलचस्प है
    जानना चाहूंगा कि YC application process में क्या इतना ही accept होने के लिए काफी था, और investment के लिए उन्होंने business model को कितना importance दिया

    • सच कहूं तो YC में accept होने के समय हम किसी और project पर काम कर रहे थे। जब तक यह नहीं समझ आया कि messy data की लोगों को ज्यादा परवाह नहीं है, हम LLM से data cleaning software बनाना चाहते थे
      generous free offering को लेकर comfortable होने की एक वजह यह basic fact है कि SaaS companies को SAML login support करने में मदद करना इतना बड़ा market नहीं है। वैसे भी हमें किसी और product से पैसे कमाने होंगे
      “add-on feature monetization” अभी वाले SAML product के बारे में है, लेकिन हम दूसरे products भी launch करने वाले हैं
      long-term goal Auth0 जैसी, लेकिन open source और developer-friendly company बनाना है

  • WorkOS से ज्यादा cost-effective alternative खोज रहे हैं, इसलिए यह सही समय पर आया। हम enterprise data verification portal बना रहे हैं और इसे try करने वाले हैं
    Entra ID के साथ integrate करते ही follow करने के लिए कोई guidelines हैं? क्या सच में बस API endpoint ही चाहिए?

    • नमस्ते, मैं SSOReady का दूसरा co-founder Ned हूं
      हां। जो code लिखना है वह सभी IdPs को cover करता है, और IdP-specific differences हर customer के configuration values में handle होते हैं
      उदाहरण के लिए, कुछ समय पहले हमने Entra-specific docs तैयार किए हैं: https://ssoready.com/docs/idp-configuration/guides-for-commo...
      जानना चाहूंगा कि क्या इससे आपकी जरूरत पूरी होती है
    • मैं WorkOS का founder हूं
      usage-based users के लिए automatic volume discounts हैं, और annual plans या custom contracts में और कम pricing भी possible है। early-stage companies के लिए free credits भी देते हैं
      अगर बात करना चाहें तो mg@workos.com पर contact कर सकते हैं
      अभी कई startups सहित सैकड़ों companies WorkOS इस्तेमाल कर रही हैं: https://workos.com/startups

  • पिछली company में SSO integration implement किया था, लेकिन SAML इतना painful लगा कि हमने सिर्फ OIDC2 किया
    अब भी ऐसा है या नहीं पता नहीं, लेकिन कुछ समय तक Okta, SCIM इस्तेमाल करने वाले Okta integration में SSO के लिए OIDC allow नहीं करता था, और SSO के लिए SAML इस्तेमाल करना पड़ता था
    हमने workaround के तौर पर SSO और SCIM के लिए दो अलग-अलग Okta integrations बनाए। customer IT department को समझाना हमेशा annoying था, लेकिन किसी ने issue नहीं बनाया, इसलिए SAML implement करने की जरूरत नहीं पड़ी

  • अच्छा लग रहा है। क्या SCIM जोड़ने की planning है?
    SAML अच्छा है, लेकिन experience के मुताबिक enterprise customers के SSO चाहने की मुख्य वजहों में से एक automated deprovisioning है, ताकि employee के leave करने पर सभी apps से access एक साथ हट जाए। इसके लिए SCIM चाहिए
    SAML के साथ SCIM भी, या SCIM का छोटा subset भी हो, तो यह लगभग बिना सोचे चुनने लायक हो जाएगा। बाकी services closed-source हैं और absurdly expensive हैं, और खुद implement करना बहुत painful है

    • SCIM जल्द जोड़ा जाएगा। automated deprovisioning और seat management से जुड़े features बड़ा motivation हैं
      सच कहूं तो IETF ने SCIM को अपने आप में काफी अच्छा बनाया है। यह SAML जैसा अजीब नहीं है। experience के मुताबिक SCIM integration का सबसे कठिन हिस्सा IdP-specific configuration सही करना है
      SAML की तरह ही Okta, Microsoft, OneLogin exact same चीजों को बिल्कुल अलग terminology में बुलाते हैं
      जिन features का इंतजार है, उनमें से एक customer को देने के लिए configuration link generate button है। उस link के जरिए customer SAML+SCIM configuration self-service तरीके से setup कर सकेगा
      अभी SAML में यह already काम कर रहा है, और अच्छा यह है कि हर product की अजीब terminology और quirky UI समझाने के लिए अलग-अलग IdP-specific docs नहीं लिखने पड़ते

  • launch के लिए congratulations। BoxyHQ के SAML Jackson[1] से तुलना करें तो यह कैसा है?
    [1]: https://github.com/boxyhq/jackson

    • मेरे हिसाब से BoxyHQ अच्छा काम कर रहा है
      हमारा approach पसंद करने की मूलतः दो वजहें हैं
      पहली, BoxyHQ SAML-over-OAuth चाहता है। हम इसे खासकर NextAuth compatibility के लिए support करते हैं, लेकिन हमें नहीं लगता कि यह हमेशा मददगार होता है
      दूसरी, हमें लगता है कि हमारी service इस्तेमाल में आसान है। users और customers से सबसे ज्यादा जो complaint सुनते हैं वह complexity की है, इसलिए हमने SAML को clear और simple बनाने पर काफी मेहनत की है। आखिरकार यह तय करना users का काम है कि यह उस standard पर खरी उतरती है या नहीं

  • Microsoft के B2C IdP के लिए पहली custom policy लिख रहा हूँ, और यह काफ़ी दर्दनाक प्रक्रिया है
    authentication और SSO को कम दर्दनाक बनाया जाए तो सच में दुनिया बेहतर हो सकती है। apps ज़्यादा सुरक्षित हो जाएँगे, लोगों को इस्तेमाल करते समय कम झुंझलाहट होगी, और मेरे जैसे लोगों का stress भी कम होगा

    • “authentication और SSO को कम दर्दनाक” बनाना, देखा जाए तो OAuth2 + OIDC ने ही किया है। Atlassian जैसी कंपनियों ने यह बात समझी
      http://id.atlassian.com