Launch HN: SSOReady (YC W24) - tecnología para simplificar SAML SSO y hacerlo open source

 (github.com/ssoready)
2 puntos por GN⁺ 2024-08-01 | 1 comentarios | Compartir por WhatsApp
  • SSOReady es una herramienta open source para agregar Enterprise SSO basado en SAML y Enterprise Directory Sync basado en SCIM a un producto, y también ofrece una UI de configuración alojada para que los clientes puedan hacer el onboarding por su cuenta
  • Para poder usarse con cualquier stack de aplicación, se basa en una HTTP API y ofrece SDK para TypeScript, Python, Go, Java, C#, Ruby y PHP como wrappers ligeros
  • El inicio de sesión SAML se compone de la generación de una URL de redirección y el intercambio de un código de acceso, mientras que SCIM simplifica el flujo de implementación al traer la lista de usuarios mediante el ID externo de la organización
  • SSOReady funciona como una capa de middleware de autenticación, no posee los usuarios ni exige cambios en la base de datos de usuarios existente, y permite elegir entre hosting en la nube o self-hosting
  • El plan Enterprise ofrece dominios y branding personalizados, Management API y soporte con SLA, mientras que la licencia MIT deja abierta la posibilidad de hacer un fork como mecanismo de control ante aumentos de precio

Qué ofrece SSOReady

  • SSOReady es un proyecto open source para agregar soporte de SAML y SCIM a un producto
  • Sus componentes principales son tres
    • SSOReady SAML: las funciones necesarias para agregar SAML, es decir, Enterprise SSO, a un producto
    • SSOReady SCIM: las funciones necesarias para agregar SCIM, es decir, Enterprise Directory Sync, a un producto
    • Self-serve Setup UI: una UI alojada para que los clientes incorporen por su cuenta la configuración de SAML o SCIM
  • La documentación de inicio rápido se divide en SAML Quickstart y SCIM Quickstart
  • El README explica que la mayoría de los usuarios implementan SAML y SCIM en una tarde y que solo hacen falta dos líneas de código

Independencia del stack y opciones de despliegue

  • SSOReady no está atado a un stack de aplicación específico, y los SDK por lenguaje se ofrecen como wrappers ligeros sobre una HTTP API intuitiva
  • Los SDK disponibles son los siguientes
  • SSOReady funciona como una capa de middleware de autenticación, no posee los usuarios ni exige cambios en la base de datos de usuarios existente
  • Como método de despliegue, se puede elegir entre usar una instancia alojada en la nube o self-hosting
  • El plan Enterprise ofrece soporte con SLA tanto para la nube como para self-hosting

Flujo de implementación de SAML

  • SAML, es decir, Enterprise SSO, consta de dos pasos
    • El paso inicial, que redirige al usuario al Identity Provider de la empresa
    • El paso de procesamiento, que verifica quién es el usuario y luego lo inicia sesión
  • Para iniciar el login se usa el endpoint Get SAML Redirect URL
    • En organizationExternalId se puede colocar cualquier ID que use el producto, como organización, workspace o equipo
    • Ese ID se configura dentro de SSOReady, y SSOReady se encarga de rastrear la configuración SAML y SCIM de esa organización
  • Para procesar el login se usa el endpoint Redeem SAML Access Code
    • En el handler de /ssoready-callback, se intercambia samlAccessCode para recibir email y organizationExternalId
    • El producto solo tiene que iniciar sesión con el correo devuelto dentro de esa organización
  • La URL del endpoint /ssoready-callback se configura en SSOReady

Flujo de implementación de SCIM

  • SCIM, es decir, Enterprise Directory Sync, se presenta como una forma de traer offline la lista de empleados del cliente
  • Para traer los empleados del cliente se usa el endpoint List SCIM Users
  • La solicitud usa organizationExternalId, y la respuesta incluye scimUsers y nextPageToken
  • Cada usuario SCIM incluye valores como email, deleted y attributes, y el producto puede crear o procesar usuarios con base en ellos

Funciones Enterprise y filosofía del proyecto

  • En el plan Enterprise se pueden usar funciones ampliadas
    • Custom Domains & Branding: ejecutar SSOReady en un dominio controlado por el usuario y adaptar la experiencia de SAML y SCIM a la marca
    • Management API: automatizar a gran escala y de forma programática las tareas relacionadas con SAML y SCIM
    • Enterprise Support: soporte con SLA, incluidos despliegues self-hosted
  • La premisa del proyecto es que todo producto que venda software para empresas debe soportar Enterprise SSO, y que esto representa una gran ventaja de seguridad para los clientes
  • Parte de la idea de que las bibliotecas SAML open source existentes tienen poca documentación y son confusas, y SSOReady busca ofrecer una experiencia de implementación clara y segura por defecto
  • Dado que consideran inaceptable aumentar arbitrariamente y de forma importante el precio del software de seguridad, SSOReady se ofrece con licencia MIT
  • Indican que los problemas de seguridad deben reportarse a security@ssoready.com

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-08-01
Opiniones de Hacker News

  • Solo puedo desearles suerte. Antes hice mi propio IdP e implementé varias funciones como inicio de sesión único, cierre de sesión único y aprovisionamiento de usuarios; cuando realmente funcionaba, era tan mágico que daba risa.
    Hicimos todo tipo de integraciones con varios proveedores de servicios e incluso con otros IdP, y la funcionalidad era buena, pero con una salvedad: nunca fue un trabajo sin dolor.
    Aunque construyas el mejor IdP del mundo, la contraparte es una caja negra, así que muchas veces no sabes por qué se consumió un payload después de enviarlo al vacío.
    Además, muchas veces la contraparte no conoce el flujo de SAML, los payloads ni siquiera las funciones SAML de su propio stack, así que tienes que enseñarle mientras aprendes también su sistema.
    Más que preocupaciones como firmas o formatos, casi todo era diagnosticar cajas negras y caer en el agujero negro de la gestión interminable de certificados.

    • Lamentablemente, esto pasa con muchos protocolos. Lo he visto en IPSec, HL7v2 e incluso CSV.
      IPSec en particular dejó cicatrices, y trabajando con “ingenieros de red” que ni siquiera podían abrir una conexión TCP para comprobar si el túnel VPN estaba vivo, uno se consume pensando: “¿será que algún día lograremos integrarnos con el otro lado?”.
      Al final, había que aprender lo antes posible el sistema de la contraparte para determinar si la configuración era correcta y encontrar los problemas de integración inevitables. Casi siempre la causa era algún firewall.
      También es un problema que los equipos empresariales cambien la terminología estándar por palabras propias, así que gran parte del aprendizaje termina siendo construir en la cabeza una piedra de Rosetta para saber cómo llama ese “appliance” de la contraparte a cada término.
    • Es parecido a operar tu propio servidor de correo. Aunque configures bien SPF, DMARC y DKIM, los registros A/AAAA/TXT/MX ya se hayan propagado por todo el mundo y hayas hecho pruebas con herramientas externas como mail-tester.com, se abre un nuevo mundo: “los otros servidores de correo”.
      Algunos servidores de correo reciben bien, pero otros tienen políticas extrañas, listas de bloqueo estrictas y administran reputaciones separadas por dominio o remitente.
    • Decir “cuando funciona es mágico y da risa” y enseguida “nunca fue indoloro y siempre se sintió como sacar una muela” puede prestarse a malentendidos, aunque haya una salvedad en medio.
      Probablemente la intención sea generar ventas, y eso está bien, pero la próxima vez convendría pulir la expresión.

  • Se ve genial. Habiendo implementado SAML, fue realmente doloroso, y esta herramienta se ve mucho más fácil de manejar.
    Sin embargo, el precio me preocupa un poco. Como tendríamos que construir nuestro sistema encima de esta herramienta, si más adelante la empresa quiebra o cambia su política de precios de una forma desfavorable para nosotros, de pronto tendríamos un gran trabajo de ingeniería para reescribir el SSO.
    Si ofrecen el producto alojado gratis, parece bastante probable que al final quiebren o cambien los precios.
    Para quienes tendremos que agregar SSO a un proyecto actual en los próximos 6 a 12 meses, sería mucho más fácil convencer al equipo si hubiera un plan de pago que parezca sostenible, en lugar de “por ahora es gratis” y “no sabemos bien, mándanos un email”.

    • 100% de acuerdo. SAML es la puerta de entrada de una aplicación, así que no me gusta una estructura en la que se espera soporte premium para un producto gratuito si uno no tiene intención de comprar luego el producto de pago de esta empresa.
      Tampoco hay que olvidar que una de las opciones es “llamar al fundador”.
    • El impuesto al SSO[1] ya existe. Es terrible bloquear funciones de seguridad, buenas prácticas y automatización a personas que ya son clientes, pero eso está cerca del estándar actual.
      En esa realidad, si alguien en una empresa necesita SAML, tal vez tenga sentido pagar aproximadamente la mitad de lo que se paga por esta sola función en una única app SaaS.
      [1]: https://sso.tax/
    • Por mi experiencia de los últimos 10 años, creo que nunca volvería a construir encima de un proyecto open source financiado por VC. Me parece que ambas cosas son difíciles de compatibilizar.
      No significa que no se pueda construir un negocio sólido con open source. Red Hat lo logró, pero creo que hay que ir por ese modelo, no por el modelo de financiamiento VC en etapa semilla.
    • Entiendo completamente la preocupación; es válida y la escuchamos con frecuencia.
      Puede que no logremos convencer con la lógica comercial, pero estamos haciendo una apuesta calculada: que una oferta gratuita generosa nos beneficiará a largo plazo.
      Creemos que este producto generará confianza entre desarrolladores y en el futuro será un canal de distribución eficiente. Una estrategia comercial open source que no monetiza al principio es bastante común.
      Por suerte, también hay algunos inversionistas de venture capital dispuestos a apoyar a empresas con productos comerciales open source populares.
      Todavía somos una empresa en etapa temprana; planeamos profundizar el producto existente y, con el tiempo, ofrecer también productos nuevos. Cobraremos por funciones nuevas y productos nuevos, y nos parece aceptable que tome años llegar a ingresos o flujo de caja significativos.

  • Es digno de elogio que lo hayan publicado como open source y lanzado un servicio fácil de usar.
    Como beneficio adicional, si esto se convierte en una implementación popular y de buena calidad, también podría facilitar que otros proveedores de servicios se integren con los usuarios de este software.
    Implementé varias veces desde cero integraciones SSO para F500, y como cada una estaba hecha a la medida, que dijeran “SAML” no significaba necesariamente que fueran interoperables. Con un software así, tal vez funcione por defecto.
    Me pregunto qué tan bien podrán mantener la seguridad al ofrecer SSO alojado gratis, para que los clientes no se vean comprometidos a través de ustedes.
    También será un punto único de falla para todos los clientes, así que me pregunto si incluso el nivel gratuito tendrá garantía de disponibilidad. También me pregunto si podrán ofrecerlo a un precio accesible para startups que quieran hosting pero necesiten un SLA.

    • La seguridad del SSO alojado gratis es realmente importante. No hay una respuesta corta; simplemente se trata de hacer bien lo que hay que hacer.
      En cuanto a SOC2, estamos trabajando con Oneleet, y todos sabemos que SOC2 es en buena medida teatro, pero también estamos haciendo una prueba de penetración bastante exhaustiva. Si quieres, puedo enviarte los resultados por email.
      En la práctica, somos una empresa que tiene que hacer bien este tipo de cosas.
      Las garantías de disponibilidad del nivel gratuito se acordarán caso por caso y dependerán de lo que se necesite. Tomamos las garantías bastante en serio, así que somos cuidadosos con lo que prometemos.
      No queremos ser un negocio de servicios ni ganar dinero con “soporte premium”. Dicho eso, si quieres un SLA, habrá un costo modesto.
      Me gustaría que reformularas la pregunta de “si un proveedor cloud se llevará a los clientes que usan este software”.

  • Hoy en día, el mayor obstáculo de SAML parece ser la integración con productos SaaS. Me ha tocado muchas veces tener que intercambiar emails con el equipo de soporte, y algunos proveedores incluso me mandaron tal cual un PDF de 204 páginas dedicado solo a la configuración de SSO
    El mapeo de atributos sigue siendo un desastre, y sorprende que la experiencia de usuario todavía sea tan mala

    • Antes me tocó escribir uno de esos PDFs de 204 páginas. En realidad creo que eran como 20 páginas, pero como los IdP no facilitan que los clientes lo configuren, al final el proveedor del servicio, o sea nosotros, tiene que documentar para el cliente cómo usar su propio IdP
      Justo lanzamos una función para este problema. En lugar de tener que crear un PDF de 204 páginas, puedes generar una URL de configuración en SSOReady y dársela al cliente; el cliente entra a esa URL y configura la conexión SAML con tu producto mediante una UI de autoservicio
      https://ssoready.com/docs/idp-configuration/enabling-self-se...
    • El soporte de SSO ocupaba más del 50% del tiempo de atención al cliente de nuestro equipo de ingeniería
      Una de las mayores dificultades era que el usuario tenía que involucrar a otro departamento que realmente era dueño del sistema SSO, y ese departamento no tenía muchos incentivos para hacerlo funcionar rápido, así que los tickets se alargaban
      También nos hacía quedar mal porque necesitábamos que el cliente nos diera cierta información
    • OKTA lo hace bastante bien, pero tienes que poder gastar más de unos 20 mil dólares al año

  • Excelente. Me da curiosidad la parte de “planeamos monetizar en el futuro creando funciones adicionales para grandes empresas con requisitos complejos”
    Me pregunto si eso por sí solo fue suficiente para entrar a YC, y cuánto peso le dieron al modelo de negocio para invertir

    • Para ser honesto, cuando entramos a YC estábamos trabajando en otro proyecto. Queríamos crear software de limpieza de datos con LLMs, hasta que nos dimos cuenta de que a nadie le importaban tanto los datos desordenados
      Una de las razones por las que nos sentimos cómodos ofreciendo un plan gratuito generoso es el hecho básico de que ayudar a empresas SaaS a soportar inicio de sesión con SAML no es un mercado tan grande. De todos modos tendremos que ganar dinero con otros productos
      “Monetización de funciones adicionales” se refiere al producto SAML que ofrecemos ahora, pero también lanzaremos otros productos
      El objetivo a largo plazo es crear una empresa parecida a Auth0, pero open source y amigable para desarrolladores

  • Esto llega justo a tiempo, porque estamos buscando una alternativa más rentable que WorkOS. Estamos creando un portal de validación de datos empresariales y planeo probarlo
    Me pregunto si hay alguna guía que podamos consultar apenas lo integremos con Entra ID. ¿De verdad basta con tener un endpoint de API?

    • Hola, soy Ned, el otro cofundador de SSOReady
      Correcto. El código que escribas cubre todos los IdP, y las diferencias específicas de cada IdP se manejan en los valores de configuración de cada cliente
      Por ejemplo, hace poco ordenamos la documentación específica para Entra: https://ssoready.com/docs/idp-configuration/guides-for-commo...
      Me gustaría saber si eso cubre lo que necesitas
    • Soy el fundador de WorkOS
      Tenemos descuentos por volumen automáticos para usuarios con pago por uso, y también es posible obtener precios más bajos con planes anuales o contratos personalizados. También ofrecemos créditos gratuitos para empresas en etapa temprana
      Si quieres conversar, puedes escribirme a mg@workos.com
      Actualmente cientos de empresas, incluidas muchas startups, usan WorkOS: https://workos.com/startups

  • En una empresa anterior implementé integración SSO, y como SAML se veía demasiado doloroso, hicimos solo OIDC2
    No sé si sigue siendo así, pero durante un tiempo Okta no permitía OIDC para SSO en integraciones de Okta que usaban SCIM, y había que usar SAML para SSO
    Lo evitamos creando dos integraciones de Okta separadas: una para SSO y otra para SCIM. Siempre era molesto explicárselo al departamento de IT del cliente, pero nadie lo cuestionó, así que no tuvimos que implementar SAML

  • Se ve bien. Me pregunto si tienen planes de agregar SCIM
    SAML está bien, pero según mi experiencia, una de las principales razones por las que los clientes enterprise quieren SSO es el desprovisionamiento automático: quitar el acceso en todas las apps de una sola vez cuando un empleado deja la empresa. Para eso se necesita SCIM
    Con SAML más SCIM, o incluso solo un pequeño subconjunto de SCIM, creo que sería una elección casi obvia. Los otros servicios son cerrados y ridículamente caros, e implementarlo uno mismo es un gran dolor

    • SCIM se agregará pronto. Vemos como una gran motivación las funciones relacionadas con desprovisionamiento automático y gestión de asientos
      Para ser franco, el IETF hizo un trabajo bastante bueno con SCIM en sí. No es tan raro como SAML. Según mi experiencia, la parte más difícil de una integración SCIM es ajustar la configuración específica de cada IdP
      Igual que con SAML, Okta, Microsoft y OneLogin llaman a exactamente lo mismo con términos completamente distintos
      Una de las funciones que esperamos ofrecer es un botón para generar un enlace de configuración que puedas darle al cliente. Con ese enlace, el cliente podrá configurar por autoservicio una configuración SAML+SCIM
      Ya funciona ahora con SAML, y es bueno no tener que escribir documentación separada para cada IdP explicando la terminología rara y las interfaces peculiares de cada producto

  • Felicitaciones por el lanzamiento. ¿Cómo se compara con SAML Jackson[1] de BoxyHQ?
    [1]: https://github.com/boxyhq/jackson

    • Creo que BoxyHQ está haciendo un buen trabajo
      Hay básicamente dos razones por las que preferimos nuestro enfoque
      Primero, BoxyHQ quiere SAML-over-OAuth. Nosotros lo soportamos, especialmente por compatibilidad con NextAuth, pero no siempre creemos que ayude
      Segundo, creemos que nuestro servicio es más fácil de usar. La queja que escuchamos con más frecuencia de usuarios y clientes es la complejidad, así que nos esforzamos mucho por hacer que SAML sea claro y simple. Al final, si cumplimos con ese estándar o no, lo decidirán los usuarios

  • Estoy escribiendo mi primera política personalizada para el IdP B2C de Microsoft, y es un proceso doloroso.
    Si hacemos que la autenticación y el SSO sean menos dolorosos, el mundo realmente puede mejorar. Las apps serán más seguras, la gente se frustrará menos al usarlas, y también se reducirá el estrés de personas como yo.

    • Si lo pensamos bien, hacer que “la autenticación y el SSO sean menos dolorosos” es algo que lograron OAuth2 + OIDC. Empresas como Atlassian lo entendieron.
      http://id.atlassian.com