Launch HN: SSOReady (YC W24) – SAML SSO einfach und Open Source machen

 (github.com/ssoready)
2 Punkte von GN⁺ 2024-08-01 | 1 Kommentare | Auf WhatsApp teilen
  • SSOReady ist ein Open-Source-Tool, um SAML-basiertes Enterprise SSO und SCIM-basiertes Enterprise Directory Sync zu einem Produkt hinzuzufügen; zusätzlich bietet es eine gehostete Setup-UI, über die Kunden das Onboarding selbst durchführen können
  • Es setzt grundsätzlich auf eine HTTP API, damit es mit jedem Application Stack nutzbar ist, und bietet SDKs für TypeScript, Python, Go, Java, C#, Ruby und PHP als schlanke Wrapper an
  • Der SAML-Login besteht aus dem Erzeugen einer Redirect-URL und dem Austausch eines Access Codes; SCIM vereinfacht den Implementierungsablauf, indem Benutzerlisten über eine externe Organisations-ID abgerufen werden
  • SSOReady arbeitet als Schicht für Authentifizierungs-Middleware, besitzt keine Benutzer und verlangt keine Änderungen an der bestehenden Benutzerdatenbank; es kann Cloud-gehostet oder selbst gehostet werden
  • Der Enterprise-Plan bietet Custom Domains und Branding, eine Management API sowie SLA-Support; die MIT-Lizenz hält durch die Möglichkeit eines Forks ein Gegengewicht gegen Preiserhöhungen offen

Was SSOReady bietet

  • SSOReady ist ein Open-Source-Projekt, um SAML- und SCIM-Support zu einem Produkt hinzuzufügen
  • Die Hauptbestandteile sind drei Komponenten
    • SSOReady SAML: die Funktionen, die nötig sind, um SAML, also Enterprise SSO, zu einem Produkt hinzuzufügen
    • SSOReady SCIM: die Funktionen, die nötig sind, um SCIM, also Enterprise Directory Sync, zu einem Produkt hinzuzufügen
    • Self-serve Setup UI: eine gehostete UI, über die Kunden SAML- oder SCIM-Einstellungen selbst onboarden können
  • Die Schnellstart-Dokumentation ist in SAML Quickstart und SCIM Quickstart unterteilt
  • Das README erklärt, dass die meisten Nutzer SAML und SCIM an einem halben Nachmittag implementieren und dafür nur zwei Zeilen Code benötigen

Stack-Unabhängigkeit und Bereitstellungsoptionen

  • SSOReady ist nicht an einen bestimmten Application Stack gebunden; sprachspezifische SDKs werden als schlanke Wrapper über einer intuitiven HTTP API angeboten
  • Folgende SDKs werden bereitgestellt
  • SSOReady arbeitet als Schicht für Authentifizierungs-Middleware, besitzt keine Benutzer und verlangt keine Änderungen an der bestehenden Benutzerdatenbank
  • Bei der Bereitstellung kann zwischen einer Cloud-gehosteten Instanz und Self-Hosting gewählt werden
  • Der Enterprise-Plan bietet SLA-Support sowohl für Cloud als auch für Self-Hosting

SAML-Implementierungsablauf

  • SAML, also Enterprise SSO, besteht aus zwei Schritten
    • dem Startschritt, bei dem Benutzer zum Identity Provider ihres Unternehmens weitergeleitet werden
    • dem Verarbeitungsschritt, bei dem festgestellt wird, wer der Benutzer ist, und er anschließend angemeldet wird
  • Zum Starten des Logins wird der Endpunkt Get SAML Redirect URL verwendet
    • In organizationExternalId kann jede gewünschte ID eingetragen werden, die im Produkt verwendet wird, etwa für Organisation, Workspace oder Team
    • Diese ID wird in SSOReady konfiguriert; SSOReady übernimmt das Nachverfolgen der SAML- und SCIM-Einstellungen dieser Organisation
  • Zur Verarbeitung des Logins wird der Endpunkt Redeem SAML Access Code verwendet
    • Im Handler von /ssoready-callback wird samlAccessCode ausgetauscht, um email und organizationExternalId zu erhalten
    • Das Produkt muss die zurückgegebene E-Mail dann innerhalb der jeweiligen Organisation anmelden
  • Die Endpunkt-URL /ssoready-callback wird in SSOReady konfiguriert

SCIM-Implementierungsablauf

  • SCIM, also Enterprise Directory Sync, wird als Methode vorgestellt, um die Mitarbeiterliste eines Kunden offline abzurufen
  • Zum Abrufen der Mitarbeiter eines Kunden wird der Endpunkt List SCIM Users verwendet
  • Die Anfrage verwendet organizationExternalId; die Antwort enthält scimUsers und nextPageToken
  • Jeder SCIM-Benutzer enthält Werte wie email, deleted und attributes; auf dieser Basis kann das Produkt Benutzer erstellen oder verarbeiten

Enterprise-Funktionen und Projektphilosophie

  • Im Enterprise-Plan stehen erweiterte Funktionen zur Verfügung
    • Custom Domains & Branding: SSOReady unter einer vom Nutzer kontrollierten Domain ausführen und die SAML-/SCIM-Erfahrung an die Marke anpassen
    • Management API: SAML- und SCIM-bezogene Aufgaben programmatisch und in großem Maßstab automatisieren
    • Enterprise Support: SLA-Support einschließlich Self-Hosting-Deployments
  • Die Prämisse des Projekts ist, dass jedes Produkt, das Business-Software verkauft, Enterprise SSO unterstützen sollte und dass dies für Kunden einen großen Sicherheitsvorteil darstellt
  • Es geht von der Problematik aus, dass bestehende Open-Source-SAML-Bibliotheken schlecht dokumentiert und verwirrend sind; SSOReady zielt auf eine klare und standardmäßig sichere Implementierungserfahrung ab
  • Da willkürliche starke Preiserhöhungen bei Sicherheitssoftware als inakzeptabel angesehen werden, wird SSOReady unter der MIT-Lizenz bereitgestellt
  • Sicherheitsprobleme sollen an security@ssoready.com gemeldet werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-01
Meinungen auf Hacker News

  • Da kann man eigentlich nur viel Glück wünschen. Ich habe früher selbst einen IdP gebaut und Funktionen wie Single Login, Single Logout und User-Provisioning implementiert; wenn es tatsächlich funktioniert, wirkt es wirklich wie Magie und man muss lachen.
    Wir hatten alle möglichen Integrationen mit verschiedenen Service Providern und anderen IdPs, und die Funktionen waren gut, aber der eine Haken war, dass es nie eine schmerzfreie Aufgabe war.
    Selbst wenn man den besten IdP der Welt baut, ist die Gegenseite eine Blackbox; oft wird ein Payload ins Leere geschickt, und man weiß nicht, warum er verarbeitet wurde.
    Außerdem wissen die Integrationspartner oft nicht einmal, wie die SAML-Flows, die Payloads oder die SAML-Funktionen ihres eigenen Stacks funktionieren, sodass man sie unterrichten und gleichzeitig deren System lernen muss.
    Es ging weniger um Sorgen wie Signaturen oder Formate, sondern meist um Blackbox-Diagnose und den endlosen schwarzen Abgrund der Zertifikatsverwaltung.

    • Leider passiert so etwas bei vielen Protokollen. Ich habe es bei IPSec, HL7v2 und sogar CSV gesehen.
      Besonders IPSec hat tiefe Narben hinterlassen: Mit einem „Netzwerkingenieur“ zu arbeiten, der nicht einmal eine TCP-Verbindung öffnen kann, um zu prüfen, ob der VPN-Tunnel lebt, lässt einen innerlich verzweifeln: „Werden wir uns mit denen überhaupt integrieren können?“
      Am Ende musste man so schnell wie möglich das System der Gegenseite lernen, beurteilen, ob die Konfiguration stimmt, und die unvermeidlichen Integrationsprobleme finden. Fast immer war irgendwo eine Firewall die Ursache.
      Ein weiteres Problem ist, dass Enterprise-Geräte Standardbegriffe durch ihre eigenen neuen Wörter ersetzen; der Großteil des Lernens besteht dann darin, im Kopf eine Rosetta Stone dafür zu bauen, wie die jeweilige „Appliance“ diesen oder jenen Begriff nennt.
    • Es ist ähnlich wie der Betrieb eines eigenen Mailservers. Selbst wenn SPF, DMARC und DKIM korrekt eingerichtet sind, A/AAAA/TXT/MX-Records weltweit propagiert wurden und man alles mit externen Tools wie mail-tester.com getestet hat, eröffnet sich nun die neue Welt der „anderen Mailserver“.
      Manche Mailserver nehmen alles problemlos an, andere betreiben seltsame Richtlinien und strenge Blocklisten und verwalten Reputationen getrennt nach Domain oder Absender.
    • Wenn man sagt: „Wenn es funktioniert, wirkt es wie Magie und man muss lachen“, und direkt danach: „Es war nie schmerzfrei und fühlte sich immer an wie Zähneziehen“, kann das trotz des Zwischensatzes missverständlich sein.
      Vermutlich soll das Umsatz generieren, und das ist an sich in Ordnung, aber beim nächsten Mal wäre eine geschliffenere Formulierung besser.

  • Sieht großartig aus. Als jemand, der SAML implementiert hat: Es war wirklich schmerzhaft, und dieses Tool wirkt deutlich einfacher.
    Allerdings mache ich mir etwas Sorgen um die Preisgestaltung. Da wir unser System auf diesem Tool aufbauen müssten, entsteht plötzlich ein großer Engineering-Aufwand, SSO neu zu schreiben, falls das Unternehmen später scheitert oder die Preispolitik sich zu unserem Nachteil ändert.
    Wenn das gehostete Produkt kostenlos angeboten wird, wirkt es ziemlich wahrscheinlich, dass das Unternehmen irgendwann scheitert oder die Preise ändert.
    Wenn ich in den nächsten 6–12 Monaten SSO in mein aktuelles Projekt integrieren muss, wäre es viel leichter, das dem Team zu verkaufen, wenn es neben „derzeit kostenlos“ und „keine Ahnung, schick uns eine E-Mail“ einen nachhaltig wirkenden kostenpflichtigen Tarif gäbe.

    • Stimme zu 100 % zu. SAML ist das Tor zur Anwendung, und mir gefällt die Struktur nicht, bei der man Premium-Support für ein kostenloses Produkt erwartet, obwohl man später nicht vorhat, das kostenpflichtige Produkt dieses Unternehmens zu kaufen.
      Man sollte auch nicht vergessen, dass eine der Optionen „Ruf den Gründer an“ ist.
    • Die SSO-Steuer[1] existiert bereits. Sicherheitsfunktionen, Best Practices und Automatisierung vor Menschen zu verstecken, die bereits Kunden sind, ist furchtbar, aber es ist ungefähr der aktuelle Standard.
      In dieser Realität könnte es für ein Unternehmen, das SAML braucht, durchaus angemessen sein, ungefähr die Hälfte dessen zu zahlen, was man bei einer einzelnen SaaS-App allein für diese Funktion bezahlt.
      [1]: https://sso.tax/
    • Nach den Erfahrungen der letzten zehn Jahre würde ich wohl nie wieder auf einem VC-finanzierten Open-Source-Projekt aufbauen. Ich halte beides für schwer vereinbar.
      Das heißt nicht, dass man mit Open Source kein solides Geschäft aufbauen kann. Red Hat hat es geschafft, aber aus meiner Sicht ist das das richtige Modell, nicht das Seed-Stage-VC-Finanzierungsmodell.
    • Ich verstehe die Sorge vollkommen; sie ist berechtigt und wir hören sie oft.
      Vielleicht überzeugt die kommerzielle Logik nicht, aber wir gehen eine kalkulierte Wette ein, dass ein großzügiges kostenloses Angebot langfristig vorteilhaft ist.
      Wir glauben, dass dieses Produkt Vertrauen bei Entwicklern schafft und künftig ein effizienter Vertriebskanal sein wird. Eine kommerzielle Open-Source-Strategie, die anfangs nicht monetarisiert, ist ziemlich verbreitet.
      Glücklicherweise gibt es auch einige Venture-Investoren, die Unternehmen mit beliebten kommerziellen Open-Source-Produkten gern unterstützen.
      Wir sind noch ein junges Unternehmen, werden das bestehende Produkt vertiefen und im Laufe der Zeit auch neue Produkte anbieten. Für neue Funktionen und neue Produkte werden wir Geld verlangen, und wir halten es für in Ordnung, wenn es einige Jahre dauert, bis nennenswerter Umsatz oder Cashflow entsteht.

  • Es ist lobenswert, das als Open Source zu veröffentlichen und einen einfach nutzbaren Service zu starten.
    Zusätzlich könnte es, wenn dies eine beliebte und hochwertige Implementierung wird, auch für andere Service Provider leichter werden, sich mit Nutzern dieser Software zu integrieren.
    Ich habe mehrfach F500-SSO-Integrationen von Grund auf implementiert, und weil alle sie individuell angepasst hatten, bedeutete „SAML“ nicht zwingend, dass es interoperabel war. Mit solcher Software könnte es standardmäßig funktionieren.
    Wenn man kostenlos gehostetes SSO anbietet, frage ich mich, wie gut man die Sicherheit aufrechterhalten kann, damit Kunden nicht darüber kompromittiert werden.
    Außerdem wird es für alle Kunden ein Single Point of Failure sein; ich frage mich, ob es auch im kostenlosen Tier eine Uptime-Garantie gibt. Und ob es für Startups, die Hosting wollen, aber ein SLA brauchen, zu einem bezahlbaren Preis angeboten werden kann.

    • Die Sicherheit von kostenlos gehostetem SSO ist wirklich wichtig. Es gibt keine kurze Antwort; es geht einfach darum, die notwendigen Dinge richtig zu machen.
      In Sachen SOC2 arbeiten wir mit Oneleet zusammen, und auch wenn wir alle wissen, dass SOC2 zu einem guten Teil Theater ist, führen wir auch ziemlich gründliche Penetrationstests durch. Wenn gewünscht, können wir die Ergebnisse per E-Mail schicken.
      Realistisch betrachtet sind wir ein Unternehmen, das solche Dinge korrekt machen muss.
      Uptime-Garantien für das kostenlose Tier wollen wir fallweise vereinbaren; sie hängen davon ab, was genau benötigt wird. Wir nehmen Garantien ziemlich ernst und sind deshalb vorsichtig mit Zusagen.
      Wir wollen kein Servicegeschäft betreiben und auch nicht mit „Premium-Support“ Geld verdienen. Wenn man allerdings ein SLA möchte, gibt es dafür eine geringe Gebühr.
      Die Frage „Wird ein Cloud-Anbieter Kunden abwerben, die diese Software nutzen?“ würde ich gern noch einmal anders formuliert sehen.

  • Das größte Hindernis bei SAML scheint heutzutage die Integration mit SaaS-Produkten zu sein. Ich hatte oft Situationen, in denen man mit dem Support E-Mails hin und her schicken musste, und ein Anbieter hat mir einfach ein 204-seitiges PDF geschickt, das nur die SSO-Einrichtung behandelte.
    Das Attribute Mapping ist weiterhin ein Chaos, und es ist erstaunlich, dass die User Experience immer noch so schlecht ist.

    • Ich habe früher einmal so ein 204-seitiges PDF geschrieben. In Wirklichkeit waren es wohl eher 20 Seiten, aber weil IdPs es Kunden nicht leicht machen, die Einrichtung selbst vorzunehmen, müssen am Ende die Service Provider, also wir, für Kunden dokumentieren, wie sie ihren IdP benutzen.
      Passenderweise haben wir gerade ein Feature für genau dieses Problem veröffentlicht. Statt ein 204-seitiges PDF zu erstellen, erzeugt man in SSOReady eine Setup-URL und gibt sie dem Kunden; der Kunde kann dann über diese URL die SAML-Verbindung mit dem Produkt über eine Self-Service-UI konfigurieren.
      https://ssoready.com/docs/idp-configuration/enabling-self-se...
    • SSO-Support hat mehr als 50 % der Kundensupport-Zeit unseres Engineering-Teams verschlungen.
      Eine der größten Schwierigkeiten war, dass der Nutzer eine andere Abteilung einbeziehen musste, die das eigentliche SSO-System besitzt, und diese Abteilung hatte wenig Anreiz, es schnell zum Laufen zu bringen, sodass Tickets sich lange hinzogen.
      Außerdem ließ es uns schlecht aussehen, weil wir bestimmte Informationen vom Kunden brauchten.
    • OKTA macht das ziemlich gut, aber man muss 20.000 Dollar oder mehr pro Jahr ausgeben können.

  • Cool. Mich interessiert der Teil „Wir planen, künftig mit Zusatzfunktionen für Großunternehmen mit komplexen Anforderungen Geld zu verdienen“.
    Ich frage mich, ob das im YC-Bewerbungsprozess schon ausgereicht hat und wie stark für die Finanzierung auf das Geschäftsmodell geachtet wurde.

    • Ehrlich gesagt arbeiteten wir an einem anderen Projekt, als wir bei YC angenommen wurden. Wir wollten mit LLMs Software zur Datenbereinigung bauen, bis uns klar wurde, dass sich kaum jemand wirklich für unordentliche Daten interessiert.
      Einer der Gründe, warum wir uns mit einem großzügigen kostenlosen Angebot wohlfühlen, ist die grundlegende Tatsache, dass es kein so großer Markt ist, SaaS-Unternehmen dabei zu helfen, SAML-Logins zu unterstützen. Wir müssen ohnehin mit anderen Produkten Geld verdienen.
      „Monetarisierung von Zusatzfunktionen“ bezieht sich auf das aktuelle SAML-Produkt, aber wir werden auch andere Produkte veröffentlichen.
      Das langfristige Ziel ist, ein Unternehmen aufzubauen, das ähnlich wie Auth0 ist, aber Open Source und entwicklerfreundlich.

  • Das kommt genau zur richtigen Zeit, da wir nach einer kosteneffizienteren Alternative zu WorkOS suchen. Wir bauen ein Portal zur Enterprise-Datenvalidierung und werden es ausprobieren.
    Gibt es Richtlinien, die man sofort heranziehen kann, sobald man mit Entra ID integriert? Braucht man wirklich nur einen API-Endpunkt?

    • Hallo, ich bin Ned, der andere Mitgründer von SSOReady.
      Genau. Der Code, den man schreibt, deckt alle IdPs ab, und die IdP-spezifischen Unterschiede werden über die Einstellungen des jeweiligen Kunden behandelt.
      Zum Beispiel habe ich vor Kurzem eine Entra-spezifische Dokumentation zusammengestellt: https://ssoready.com/docs/idp-configuration/guides-for-commo...
      Ich würde gern wissen, ob das euren Bedarf abdeckt.
    • Ich bin der Gründer von WorkOS.
      Für nutzungsbasierte Kunden gibt es automatische Volumenrabatte, und bei Jahresplänen oder individuellen Verträgen sind auch niedrigere Preise möglich. Für Unternehmen in der Frühphase bieten wir außerdem kostenlose Credits an.
      Wenn du sprechen möchtest, kannst du dich unter mg@workos.com melden.
      Derzeit nutzen Hunderte Unternehmen WorkOS, darunter viele Startups: https://workos.com/startups

  • Ich habe in einer früheren Firma SSO-Integrationen implementiert, aber SAML sah so schmerzhaft aus, dass wir nur OIDC2 gemacht haben.
    Ich weiß nicht, ob das heute noch so ist, aber eine Zeit lang erlaubte Okta bei Okta-Integrationen mit SCIM kein OIDC für SSO; für SSO musste man SAML verwenden.
    Wir haben das umgangen, indem wir zwei getrennte Okta-Integrationen gebaut haben, eine für SSO und eine für SCIM. Es war immer lästig, das den IT-Abteilungen der Kunden zu erklären, aber niemand hat sich daran gestört, sodass wir SAML nicht implementieren mussten.

  • Sieht gut aus. Ich frage mich, ob ihr plant, SCIM hinzuzufügen.
    SAML ist gut, aber meiner Erfahrung nach ist einer der Hauptgründe, warum Enterprise-Kunden SSO wollen, die automatische Deprovisionierung, damit beim Ausscheiden eines Mitarbeiters der Zugriff auf alle Apps auf einmal entzogen wird. Dafür braucht man SCIM.
    Mit SAML plus SCIM, oder auch nur einem kleinen Teil von SCIM, wäre die Entscheidung für mich fast ein No-Brainer. Andere Dienste sind Closed Source und absurd teuer, und es selbst zu implementieren ist sehr schmerzhaft.

    • SCIM wird bald dazukommen. Automatische Deprovisionierung und Funktionen rund ums Seat Management sind dafür aus unserer Sicht wichtige Motivatoren.
      Ehrlich gesagt hat die IETF SCIM selbst ziemlich gut gemacht. Es ist nicht so seltsam wie SAML. Nach meiner Erfahrung ist der schwierigste Teil bei SCIM-Integrationen, die IdP-spezifische Konfiguration richtig hinzubekommen.
      Wie bei SAML nennen Okta, Microsoft und OneLogin exakt dasselbe jeweils mit völlig unterschiedlichen Begriffen.
      Eine der Funktionen, auf die ich mich freue, ist ein Button zum Erzeugen eines Setup-Links für Kunden. Über diesen Link kann der Kunde die SAML+SCIM-Konfiguration per Self-Service einrichten.
      Für SAML funktioniert das bereits, und es ist schön, nicht für jedes Produkt eigene IdP-spezifische Dokumentation schreiben zu müssen, die die seltsame Terminologie und die eigenartige UI erklärt.

  • Glückwunsch zum Launch. Wie ist der Vergleich mit SAML Jackson[1] von BoxyHQ?
    [1]: https://github.com/boxyhq/jackson

    • Ich finde, BoxyHQ macht gute Arbeit.
      Es gibt im Wesentlichen zwei Gründe, warum ich unseren Ansatz bevorzuge.
      Erstens möchte BoxyHQ SAML-over-OAuth. Wir unterstützen das, insbesondere wegen NextAuth-Kompatibilität, sehen aber nicht, dass es immer hilfreich ist.
      Zweitens denke ich, dass unser Service einfacher zu benutzen ist. Die häufigste Beschwerde, die wir von Nutzern und Kunden hören, ist Komplexität, daher haben wir viel Mühe darauf verwendet, SAML klar und einfach zu machen. Ob wir diesen Anspruch am Ende erfüllen, müssen die Nutzer beurteilen.

  • Ich schreibe gerade meine erste benutzerdefinierte Richtlinie für Microsofts B2C-IdP, und es ist ein schmerzhafter Prozess.
    Wenn man Authentifizierung und SSO weniger schmerzhaft macht, kann das die Welt tatsächlich ein Stück besser machen. Apps werden sicherer, die Nutzung ist für Menschen weniger frustrierend, und der Stress für Leute wie mich nimmt ebenfalls ab.

    • Wenn man es genau nimmt, lässt sich sagen, dass OAuth2 + OIDC genau das geleistet haben: „Authentifizierung und SSO weniger schmerzhaft“ zu machen. Unternehmen wie Atlassian haben das verstanden.
      http://id.atlassian.com