Launch HN: SSOReady (YC W24) - la technologie open source qui simplifie le SAML SSO

 (github.com/ssoready)
2 points par GN⁺ 2024-08-01 | 1 commentaires | Partager sur WhatsApp
  • SSOReady est un outil open source permettant d’ajouter à un produit le SSO Enterprise basé sur SAML et la synchronisation d’annuaire Enterprise basée sur SCIM, avec en plus une interface de configuration hébergée que les clients peuvent utiliser pour s’onboarder eux-mêmes
  • Pour pouvoir être utilisé avec n’importe quelle stack applicative, HTTP API sert de base, et des SDK pour TypeScript, Python, Go, Java, C#, Ruby et PHP sont fournis sous forme de wrappers légers
  • La connexion SAML se compose de la génération d’une URL de redirection et de l’échange d’un code d’accès, tandis que SCIM simplifie le flux d’implémentation en récupérant la liste des utilisateurs à partir d’un ID externe d’organisation
  • SSOReady fonctionne comme une couche de middleware d’authentification, sans posséder les utilisateurs ni exiger de modifications de la base de données utilisateurs existante, avec au choix un hébergement cloud ou un self-hosting
  • Le plan Enterprise propose domaine personnalisé et branding, Management API et support SLA, tandis que la licence MIT laisse ouverte la possibilité d’un fork comme garde-fou contre les hausses de prix

Ce que propose SSOReady

  • SSOReady est un projet open source destiné à ajouter la prise en charge de SAML et SCIM à un produit
  • Il se compose de trois éléments principaux
    • SSOReady SAML : les fonctionnalités nécessaires pour ajouter SAML, c’est-à-dire le SSO Enterprise, à un produit
    • SSOReady SCIM : les fonctionnalités nécessaires pour ajouter SCIM, c’est-à-dire la synchronisation d’annuaire Enterprise, à un produit
    • Self-serve Setup UI : une interface hébergée permettant aux clients d’onboarder eux-mêmes leur configuration SAML ou SCIM
  • Les guides de démarrage rapide sont séparés entre SAML Quickstart et SCIM Quickstart
  • Le README indique que la plupart des utilisateurs implémentent SAML et SCIM en une demi-journée, avec seulement deux lignes de code

Indépendance vis-à-vis de la stack et options de déploiement

  • SSOReady n’est lié à aucune stack applicative particulière, et les SDK par langage sont fournis comme de simples wrappers au-dessus d’une HTTP API intuitive
  • Les SDK disponibles sont les suivants
  • SSOReady fonctionne comme une couche de middleware d’authentification, sans posséder les utilisateurs ni exiger de modifications de la base de données utilisateurs existante
  • Le mode de déploiement peut être choisi entre une instance hébergée dans le cloud ou le self-hosting
  • Le plan Enterprise fournit un support SLA aussi bien pour le cloud que pour le self-hosting

Flux d’implémentation SAML

  • SAML, c’est-à-dire le SSO Enterprise, se compose de deux étapes
    • une étape initiale qui redirige l’utilisateur vers l’Identity Provider de son entreprise
    • une étape de traitement qui vérifie l’identité de l’utilisateur avant de le connecter
  • Pour initier la connexion, on utilise l’endpoint Get SAML Redirect URL
    • organizationExternalId peut contenir l’identifiant de votre choix utilisé dans le produit, qu’il s’agisse d’une organisation, d’un workspace, d’une équipe, etc.
    • Cet identifiant est configuré dans SSOReady, qui se charge ensuite du suivi de la configuration SAML et SCIM de cette organisation
  • Pour traiter la connexion, on utilise l’endpoint Redeem SAML Access Code
    • Dans le handler de /ssoready-callback, il faut échanger samlAccessCode pour obtenir email et organizationExternalId
    • Le produit n’a ensuite plus qu’à connecter l’utilisateur dans l’organisation correspondante à partir de l’e-mail renvoyé
  • L’URL de l’endpoint /ssoready-callback se configure dans SSOReady

Flux d’implémentation SCIM

  • SCIM, c’est-à-dire la synchronisation d’annuaire Enterprise, est présenté comme un moyen de récupérer hors ligne la liste des employés d’un client
  • Pour récupérer les employés d’un client, on utilise l’endpoint List SCIM Users
  • La requête utilise organizationExternalId, et la réponse contient scimUsers ainsi que nextPageToken
  • Chaque utilisateur SCIM inclut des valeurs comme email, deleted et attributes, que le produit peut utiliser pour créer ou traiter les utilisateurs

Fonctionnalités Enterprise et philosophie du projet

  • Des fonctionnalités avancées sont disponibles dans le plan Enterprise
    • Custom Domains & Branding : exécuter SSOReady sur un domaine contrôlé par l’utilisateur et adapter l’expérience SAML et SCIM à la marque
    • Management API : automatiser à grande échelle, par programmation, les opérations liées à SAML et SCIM
    • Enterprise Support : support SLA, y compris pour les déploiements en self-hosting
  • Le projet part du principe que tout produit vendant du logiciel aux entreprises devrait prendre en charge le SSO Enterprise, car cela apporte un avantage de sécurité majeur aux clients
  • Il part aussi du constat que les bibliothèques SAML open source existantes souffrent d’une documentation insuffisante et déroutante ; SSOReady vise donc une expérience d’implémentation claire et sûre par défaut
  • Considérant qu’il est inacceptable d’augmenter arbitrairement et massivement le prix des logiciels de sécurité, SSOReady est proposé sous licence MIT
  • Les problèmes de sécurité doivent être signalés à security@ssoready.com

À lire aussi

1 commentaires

 
GN⁺ 2024-08-01
Avis de Hacker News

  • Je ne peux que vous souhaiter bonne chance. J’ai déjà créé moi-même un IdP, avec authentification unique, déconnexion unique, provisionnement des utilisateurs, etc., et quand ça marche vraiment, c’est tellement magique que ça fait sourire.
    Nous avions fait toutes sortes d’intégrations avec plusieurs fournisseurs de services et même d’autres IdP, et les fonctionnalités étaient bonnes, mais il y avait une réserve : cela n’a jamais été un travail indolore.
    Même si vous créez le meilleur IdP du monde, l’autre côté reste une boîte noire : souvent, une fois le payload envoyé dans le vide, on ne sait pas pourquoi il a été consommé.
    En plus, il arrive fréquemment que l’intégrateur en face ne comprenne pas le flux SAML, le payload, ni même les fonctionnalités SAML de sa propre stack, ce qui oblige à lui apprendre tout en apprenant aussi son système.
    L’essentiel du travail concernait moins les signatures ou les formats que le diagnostic de boîtes noires et le trou noir sans fin de la gestion des certificats.

    • Malheureusement, ce genre de choses arrive avec beaucoup de protocoles. Je l’ai vu avec IPSec, HL7v2, et même CSV.
      IPSec m’a particulièrement laissé des cicatrices : à travailler avec des « ingénieurs réseau » incapables d’ouvrir ne serait-ce qu’une connexion TCP pour vérifier si un tunnel VPN était vivant, on finit par se demander avec anxiété : « est-ce qu’on arrivera seulement à s’intégrer avec eux ? »
      Au final, il fallait apprendre le système d’en face le plus vite possible pour déterminer si la configuration était correcte et trouver les inévitables problèmes d’intégration. Presque toujours, la cause était un pare-feu quelque part.
      Autre problème : les équipements enterprise rebaptisent les termes standard avec leur propre vocabulaire, si bien que l’essentiel de l’apprentissage consiste à se construire dans la tête une pierre de Rosette reliant tel ou tel terme au nom que lui donne l’« appliance » d’en face.
    • C’est un peu comme exploiter son propre serveur mail. Même après avoir correctement configuré SPF, DMARC et DKIM, s’être assuré que les enregistrements A/AAAA/TXT/MX se sont propagés dans le monde entier et avoir testé avec des outils externes comme mail-tester.com, un nouveau monde s’ouvre : celui des « autres serveurs mail ».
      Certains acceptent bien vos messages, tandis que d’autres appliquent des politiques étranges, des listes de blocage strictes et gèrent séparément la réputation par domaine ou par expéditeur.
    • Dire « quand ça marche, c’est magique et ça fait sourire », puis enchaîner immédiatement avec « ça n’a jamais été indolore et ça a toujours ressemblé à un arrachage de dents » peut prêter à confusion, même avec une réserve entre les deux.
      J’imagine que l’objectif est de générer du chiffre d’affaires, et ce n’est pas un problème en soi, mais la prochaine fois il vaudrait mieux affiner la formulation.

  • Ça a l’air excellent. Pour avoir implémenté SAML, c’était vraiment pénible, et cet outil semble beaucoup plus facile à utiliser.
    Cela dit, le prix m’inquiète un peu. Comme il faudrait bâtir notre système au-dessus de cet outil, si l’entreprise disparaît plus tard ou change sa politique tarifaire à notre désavantage, nous nous retrouverions soudain avec un gros chantier d’ingénierie pour réécrire le SSO.
    S’ils proposent gratuitement le produit hébergé, il me semble assez probable qu’ils finissent soit par disparaître, soit par modifier leurs prix.
    Pour quelqu’un qui doit ajouter du SSO à son projet actuel dans les 6 à 12 prochains mois, il serait beaucoup plus facile de convaincre l’équipe s’il existait une offre payante qui semble durable, plutôt que seulement « gratuit pour l’instant » et « on ne sait pas trop, envoyez-nous un e-mail ».

    • Je suis d’accord à 100 %. SAML est la porte d’entrée d’une application ; je n’aime pas l’idée de s’appuyer sur un produit gratuit en espérant un support premium alors qu’on n’a pas l’intention d’acheter plus tard l’offre payante de cette entreprise.
      Il ne faut pas non plus oublier que l’une des options est « appeler le fondateur ».
    • La taxe SSO[1] existe déjà. Bloquer des fonctionnalités de sécurité, des bonnes pratiques et de l’automatisation à des gens qui sont déjà clients est horrible, mais c’est à peu près la norme actuelle.
      Dans ce contexte, si quelqu’un dans une entreprise a besoin de SAML, il peut être raisonnable de payer environ la moitié de ce que coûte cette seule fonctionnalité dans une application SaaS donnée.
      [1]: https://sso.tax/
    • D’après mon expérience des dix dernières années, je ne pense plus jamais bâtir quoi que ce soit sur un projet open source financé par du capital-risque. À mes yeux, les deux cohabitent difficilement.
      Cela ne veut pas dire qu’il est impossible de construire une activité solide autour de l’open source. Red Hat l’a fait, mais c’est ce modèle qu’il faut suivre, pas le modèle financé par du VC au stade seed.
    • Je comprends parfaitement l’inquiétude ; elle est légitime et revient souvent.
      L’argument commercial ne convaincra peut-être pas, mais nous faisons un pari calculé : offrir généreusement du gratuit sera bénéfique à long terme.
      Nous pensons que ce produit créera de la confiance auprès des développeurs et deviendra à l’avenir un canal de distribution efficace. Une stratégie d’open source commercial qui ne monétise pas au début est assez courante.
      Heureusement, certains investisseurs en capital-risque sont prêts à soutenir des entreprises qui ont des produits open source commerciaux populaires.
      Nous sommes encore une jeune entreprise ; nous allons approfondir le produit existant et proposer aussi de nouveaux produits avec le temps. Les nouvelles fonctionnalités et les nouveaux produits seront payants, et nous acceptons l’idée qu’il faille plusieurs années avant d’atteindre un chiffre d’affaires ou un flux de trésorerie significatif.

  • Publier cela en open source et lancer un service facile à utiliser mérite des félicitations.
    Accessoirement, si cela devient une implémentation populaire et de qualité, cela pourrait aussi faciliter l’intégration d’autres fournisseurs de services avec les utilisateurs de ce logiciel.
    J’ai implémenté plusieurs intégrations SSO pour des entreprises du Fortune 500 en partant de zéro, et comme chacune avait été personnalisée, le fait d’appeler ça « SAML » ne garantissait pas forcément l’interopérabilité. Avec ce type de logiciel, cela pourrait fonctionner par défaut.
    Je me demande dans quelle mesure ils pourront maintenir une bonne sécurité en proposant du SSO hébergé gratuit, afin que les clients ne soient pas compromis via eux.
    Je me demande aussi s’il y aura une garantie de disponibilité pour l’offre gratuite, puisqu’ils deviendront un point de défaillance unique pour tous leurs clients. Et s’ils pourront proposer un prix abordable aux startups qui veulent de l’hébergement mais ont besoin d’un SLA.

    • La sécurité du SSO hébergé gratuit est vraiment essentielle. Il n’y a pas de réponse courte : il faut simplement faire correctement ce qui doit être fait.
      Pour SOC2, nous travaillons avec Oneleet, et même si tout le monde sait que SOC2 relève en grande partie du théâtre, nous menons aussi un test d’intrusion assez approfondi. Nous pouvons vous envoyer les résultats par e-mail si vous le souhaitez.
      Concrètement, nous sommes une entreprise qui doit absolument faire les choses correctement sur ce sujet.
      Les garanties de disponibilité de l’offre gratuite seront convenues au cas par cas et dépendront des besoins. Nous prenons les garanties assez au sérieux, donc nous sommes prudents dans nos engagements.
      Nous ne cherchons pas à être une entreprise de services, et nous ne voulons pas non plus gagner de l’argent avec du « support premium ». Cela dit, si vous voulez un SLA, il y aura un coût modeste.
      Concernant la question « est-ce qu’un fournisseur cloud va prendre les clients qui utilisent ce logiciel », pourriez-vous la reformuler ?

  • Ces temps-ci, le plus gros obstacle avec SAML semble être l’intégration aux produits SaaS. J’ai souvent dû échanger des e-mails avec des équipes support, et certains fournisseurs se contentaient même d’envoyer un PDF de 204 pages consacré uniquement à la configuration du SSO
    Le mapping des attributs reste un vrai bazar, et c’est étonnant que l’expérience utilisateur soit encore aussi mauvaise

    • J’ai déjà rédigé ce genre de PDF de 204 pages. En réalité, il devait plutôt faire une vingtaine de pages, mais comme les IdP ne facilitent pas la configuration côté client, c’est au fournisseur de service — donc à nous — de documenter pour les clients comment utiliser leur propre IdP
      Justement, nous avons lancé une fonctionnalité pour ce problème. Au lieu de créer un PDF de 204 pages, SSOReady génère une URL de configuration que vous donnez au client ; celui-ci ouvre cette URL et peut configurer sa connexion SAML avec le produit via une UI en self-service
      https://ssoready.com/docs/idp-configuration/enabling-self-se...
    • Le support SSO représentait plus de 50 % du temps de support client de notre équipe d’ingénierie
      L’une des plus grandes difficultés était que l’utilisateur devait impliquer un autre service, celui qui possédait réellement le système SSO, et ce service n’avait pas vraiment d’incitation à faire avancer les choses rapidement, donc les tickets traînaient
      Comme nous devions obtenir certaines informations du client, cela nous faisait aussi passer pour les méchants
    • OKTA s’en sort plutôt bien, mais il faut pouvoir dépenser au moins dans les 20 000 dollars par an

  • Super. Je suis curieux à propos de la partie « créer des fonctionnalités supplémentaires pour les grandes entreprises aux besoins complexes afin de les monétiser plus tard »
    Je me demande si cela suffisait déjà pour être accepté à YC pendant la candidature, et à quel point ils ont accordé de l’importance au modèle économique pour l’investissement

    • Pour être honnête, quand nous avons été acceptés à YC, nous travaillions sur un autre projet. Nous voulions créer un logiciel de nettoyage de données avec des LLM, jusqu’à ce que nous réalisions que personne ne se souciait vraiment des données en désordre
      L’une des raisons pour lesquelles nous sommes à l’aise avec une offre gratuite généreuse, c’est le fait de base que le marché consistant à aider des sociétés SaaS à prendre en charge la connexion SAML n’est pas si énorme. De toute façon, il faudra gagner de l’argent avec d’autres produits
      La « monétisation de fonctionnalités supplémentaires » concerne le produit SAML que nous proposons actuellement, mais nous lancerons aussi d’autres produits
      L’objectif à long terme est de créer une entreprise similaire à Auth0, mais open source et plus developer-friendly

  • C’est très opportun, car je cherche une alternative plus rentable à WorkOS. Je construis un portail de validation de données d’entreprise et je vais l’essayer
    Je me demande s’il existe des instructions à suivre dès qu’on l’intègre avec Entra ID. Est-ce qu’un simple endpoint d’API suffit vraiment ?

    • Bonjour, je suis Ned, l’autre cofondateur de SSOReady
      Oui. Le code à écrire couvre tous les IdP, et les différences propres à chaque IdP sont gérées dans les paramètres de configuration de chaque client
      Par exemple, nous avons récemment préparé une documentation spécifique à Entra : https://ssoready.com/docs/idp-configuration/guides-for-commo...
      Je serais curieux de savoir si cela couvre ce dont vous avez besoin
    • Je suis le fondateur de WorkOS
      Nous proposons des remises de volume automatiques pour les utilisateurs à l’usage, et des tarifs encore plus bas sont possibles avec des forfaits annuels ou des contrats sur mesure. Nous offrons aussi des crédits gratuits aux entreprises en phase initiale
      Si vous voulez en discuter, vous pouvez me contacter à mg@workos.com
      Aujourd’hui, des centaines d’entreprises, dont de nombreuses startups, utilisent WorkOS : https://workos.com/startups

  • Dans une entreprise précédente, j’ai implémenté une intégration SSO, mais SAML avait l’air tellement pénible que nous n’avons fait que OIDC2
    Je ne sais pas si c’est encore le cas, mais pendant un moment, Okta n’autorisait pas OIDC pour le SSO dans les intégrations Okta utilisant SCIM ; il fallait utiliser SAML pour le SSO
    Nous avons contourné le problème en créant deux intégrations Okta séparées, une pour le SSO et une pour SCIM. C’était toujours pénible à expliquer aux équipes IT des clients, mais personne n’y voyait d’objection, donc nous n’avons pas eu besoin d’implémenter SAML

  • Ça a l’air bien. Je me demande si vous prévoyez d’ajouter SCIM
    SAML est très bien, mais d’après mon expérience, l’une des principales raisons pour lesquelles les grands comptes veulent du SSO est le déprovisionnement automatique : quand un employé quitte l’entreprise, ses accès sont supprimés de toutes les apps en une seule fois. Pour cela, il faut SCIM
    Avec SAML plus SCIM, ou même seulement un petit sous-ensemble de SCIM, ce serait presque un choix évident. Les autres services sont fermés et absurdement chers, et le faire soi-même est très douloureux

    • SCIM arrive bientôt. Les fonctionnalités liées au déprovisionnement automatique et à la gestion des sièges sont, à mon avis, une grande motivation
      Honnêtement, l’IETF a plutôt bien conçu SCIM en lui-même. Ce n’est pas aussi étrange que SAML. D’expérience, la partie la plus difficile d’une intégration SCIM est d’ajuster la configuration propre à chaque IdP
      Comme avec SAML, Okta, Microsoft et OneLogin appellent exactement la même chose avec des termes complètement différents
      L’une des fonctionnalités que j’attends est un bouton pour générer un lien de configuration à donner au client. Via ce lien, le client pourra configurer lui-même SAML+SCIM en self-service
      C’est déjà opérationnel pour SAML, et c’est agréable de ne pas avoir à écrire une documentation séparée par IdP pour expliquer la terminologie bizarre et les UI particulières de chaque produit

  • Félicitations pour le lancement. Comment vous comparez-vous à SAML Jackson[1] de BoxyHQ ?
    [1]: https://github.com/boxyhq/jackson

    • Je pense que BoxyHQ fait du bon travail
      Il y a essentiellement deux raisons pour lesquelles nous préférons notre approche
      Premièrement, BoxyHQ veut du SAML-over-OAuth. Nous le prenons en charge, notamment pour la compatibilité avec NextAuth, mais nous ne pensons pas que ce soit toujours utile
      Deuxièmement, nous pensons que notre service est plus facile à utiliser. La plainte que nous entendons le plus souvent de la part des utilisateurs et des clients concerne la complexité ; nous avons donc beaucoup travaillé pour rendre SAML clair et simple. Au final, c’est aux utilisateurs de juger si nous atteignons ce niveau

  • Je suis en train d’écrire ma première politique personnalisée pour l’IdP B2C de Microsoft, et c’est un processus douloureux
    Rendre l’authentification et le SSO moins pénibles peut réellement améliorer le monde. Les apps deviennent plus sûres, les gens sont moins frustrés en les utilisant, et le stress de personnes comme moi diminue aussi

    • « Rendre l’authentification et le SSO moins pénibles », au fond, on peut dire que c’est ce qu’ont accompli OAuth2 + OIDC. Des entreprises comme Atlassian l’ont compris
      http://id.atlassian.com