Launch HN: SSOReady (YC W24) - Tecnologia que torna SAML SSO simples e open source

 (github.com/ssoready)
2 pontos por GN⁺ 2024-08-01 | 1 comentários | Compartilhar no WhatsApp
  • SSOReady é uma ferramenta open source para adicionar Enterprise SSO baseado em SAML e Enterprise Directory Sync baseado em SCIM ao seu produto, oferecendo também uma UI de configuração hospedada para que clientes façam o onboarding por conta própria
  • Para funcionar com qualquer stack de aplicação, tem uma HTTP API como base e oferece SDKs para TypeScript, Python, Go, Java, C#, Ruby e PHP como wrappers leves
  • O login SAML é composto pela geração de uma URL de redirecionamento e pela troca de um código de acesso, enquanto o SCIM simplifica o fluxo de implementação ao buscar a lista de usuários por um ID externo da organização
  • O SSOReady atua como uma camada de middleware de autenticação, sem possuir os usuários nem exigir mudanças no banco de dados de usuários existente, e permite escolher entre hospedagem na nuvem ou self-hosting
  • O plano Enterprise oferece domínio e branding personalizados, Management API e suporte com SLA, enquanto a licença MIT mantém aberta a possibilidade de fork como mecanismo de contenção contra aumentos de preço

O que o SSOReady oferece

  • SSOReady é um projeto open source para adicionar suporte a SAML e SCIM ao seu produto
  • Ele é composto por três partes principais
    • SSOReady SAML: recursos necessários para adicionar SAML, ou seja, Enterprise SSO, ao seu produto
    • SSOReady SCIM: recursos necessários para adicionar SCIM, ou seja, Enterprise Directory Sync, ao seu produto
    • Self-serve Setup UI: UI hospedada para que clientes façam o onboarding da configuração de SAML ou SCIM por conta própria
  • A documentação de início rápido é dividida em SAML Quickstart e SCIM Quickstart
  • O README explica que a maioria dos usuários implementa SAML e SCIM em uma tarde e precisa de apenas duas linhas de código

Independência de stack e opções de implantação

  • O SSOReady não fica preso a uma stack de aplicação específica; os SDKs por linguagem são oferecidos como wrappers leves sobre uma HTTP API intuitiva
  • Os SDKs disponíveis são:
  • O SSOReady atua como uma camada de middleware de autenticação, não possui os usuários e não exige mudanças no banco de dados de usuários existente
  • O modelo de implantação pode ser escolhido entre usar uma instância hospedada na nuvem ou fazer self-hosting
  • O plano Enterprise oferece suporte com SLA tanto para nuvem quanto para self-hosting

Fluxo de implementação de SAML

  • SAML, ou Enterprise SSO, é composto por duas etapas
    • Uma etapa inicial que redireciona o usuário para o Identity Provider da empresa
    • Uma etapa de processamento que confirma quem é o usuário e então realiza o login
  • Para iniciar o login, usa-se o endpoint Get SAML Redirect URL
    • Em organizationExternalId, você pode colocar qualquer ID usado no seu produto, como organização, workspace ou time
    • Esse ID é configurado dentro do SSOReady, que se encarrega de acompanhar as configurações de SAML e SCIM dessa organização
  • Para processar o login, usa-se o endpoint Redeem SAML Access Code
    • No handler de /ssoready-callback, troque o samlAccessCode para receber email e organizationExternalId
    • O produto só precisa fazer login com o e-mail retornado dentro daquela organização
  • A URL do endpoint /ssoready-callback é configurada no SSOReady

Fluxo de implementação de SCIM

  • SCIM, ou Enterprise Directory Sync, é apresentado como uma forma de buscar offline a lista de funcionários do cliente
  • Para buscar os funcionários do cliente, usa-se o endpoint List SCIM Users
  • A requisição usa organizationExternalId, e a resposta inclui scimUsers e nextPageToken
  • Cada usuário SCIM inclui valores como email, deleted e attributes, e o produto pode criar ou processar usuários com base neles

Recursos Enterprise e filosofia do projeto

  • Recursos expandidos estão disponíveis no plano Enterprise
    • Custom Domains & Branding: execute o SSOReady em um domínio controlado pelo usuário e personalize a experiência de SAML e SCIM com a marca
    • Management API: automatize em grande escala, por programação, tarefas relacionadas a SAML e SCIM
    • Enterprise Support: suporte com SLA, incluindo implantações self-hosted
  • A premissa do projeto é que todo produto que vende software para empresas deve oferecer suporte a Enterprise SSO, pois isso representa um grande benefício de segurança para os clientes
  • Há a percepção de que as bibliotecas SAML open source existentes têm documentação insuficiente e são confusas; o SSOReady busca oferecer uma experiência de implementação clara e segura por padrão
  • Por defender que aumentos arbitrários e expressivos nos preços de software de segurança são inaceitáveis, o SSOReady é oferecido sob a licença MIT
  • Problemas de segurança devem ser reportados para security@ssoready.com

Leituras relacionadas

1 comentários

 
GN⁺ 2024-08-01
Opiniões no Hacker News

  • Só resta desejar boa sorte. No passado, eu mesmo criei um IdP e implementei várias funcionalidades, como login único, logout único e provisionamento de usuários; quando isso realmente funciona, parece magia e dá até vontade de rir
    Integrei com vários provedores de serviço e até com outros IdPs, e os recursos eram bons, mas havia uma ressalva: isso definitivamente nunca foi um trabalho sem dor
    Mesmo que você crie o melhor IdP do mundo, o outro lado é uma caixa-preta; muitas vezes o payload é enviado para o vazio e você não sabe por que ele foi consumido
    Além disso, muitas vezes a contraparte de integração não conhece o fluxo do SAML, o payload, nem sequer os recursos de SAML da própria stack, então você precisa ensiná-la e, ao mesmo tempo, aprender o sistema dela
    A maior parte do trabalho não era se preocupar com assinaturas ou formatos, mas diagnosticar caixas-pretas e cair no buraco negro interminável da gestão de certificados

    • Infelizmente, isso acontece em muitos protocolos. Já vi em IPSec, HL7v2 e até CSV
      O IPSec, em especial, deixou cicatrizes profundas; trabalhando com um “engenheiro de redes” que nem conseguia abrir uma conexão TCP para verificar se o túnel VPN estava vivo, eu ficava angustiado pensando: “será que a integração com o outro lado vai mesmo acontecer?”
      No fim, era preciso aprender o sistema da contraparte o mais rápido possível para avaliar se a configuração estava correta e encontrar os problemas inevitáveis de integração. Quase sempre a causa era algum firewall em algum lugar
      Outro problema é que equipamentos enterprise trocam a terminologia padrão por palavras próprias, então a maior parte do aprendizado vira montar, na cabeça, uma pedra de Roseta para saber como aquele “appliance” chama este ou aquele termo
    • É parecido com operar seu próprio servidor de e-mail. Mesmo configurando corretamente SPF, DMARC e DKIM, garantindo que os registros A/AAAA/TXT/MX tenham se propagado pelo mundo todo e testando tudo com ferramentas externas como mail-tester.com, abre-se um novo mundo chamado “outros servidores de e-mail”
      Alguns servidores de e-mail aceitam bem, mas outros operam políticas estranhas, listas de bloqueio rigorosas e gerenciam reputações separadas por domínio ou remetente
    • Dizer que “quando funciona parece magia e dá vontade de rir” e logo depois dizer que “nunca foi indolor e sempre pareceu arrancar um dente” pode causar mal-entendido, mesmo havendo uma ressalva no meio
      Provavelmente a intenção é gerar vendas, e isso em si é ok, mas seria melhor ajustar a formulação na próxima vez

  • Parece legal. Como alguém que já implementou SAML, foi realmente doloroso, e esta ferramenta parece bem mais fácil de usar
    Mas fico um pouco preocupado com o preço. Como teríamos de construir nosso sistema em cima desta ferramenta, se a empresa quebrar no futuro ou mudar a política de preços de um jeito desfavorável para nós, de repente surgirá um grande trabalho de engenharia para reescrever o SSO
    Se o produto hospedado for oferecido de graça, parece bem provável que, no fim, a empresa quebre ou mude os preços
    Para quem precisa adicionar SSO ao projeto atual nos próximos 6 a 12 meses, seria muito mais fácil convencer a equipe se houvesse um plano pago que parecesse sustentável, em vez de apenas “por enquanto é grátis” e “não sabemos, mande um e-mail”

    • Concordo 100%. SAML é a porta de entrada da aplicação, então não gosto de uma estrutura em que se espera suporte premium em um produto gratuito sem intenção de comprar o produto pago dessa empresa no futuro
      Também não dá para esquecer que uma das opções é “ligar para o fundador”
    • O imposto do SSO[1] já existe. É péssimo bloquear recursos de segurança, boas práticas e automação de pessoas que já são clientes, mas isso é quase o padrão atual
      Nessa realidade, se alguém na empresa precisa de SAML, talvez faça sentido pagar cerca de metade do que se paga por esse único recurso em um único app SaaS
      [1]: https://sso.tax/
    • Pela minha experiência dos últimos 10 anos, acho que nunca mais vou construir em cima de um projeto open source financiado por VC. Vejo os dois como difíceis de conciliar
      Não estou dizendo que não seja possível criar um negócio sólido com open source. A Red Hat conseguiu, mas acho que o caminho é aquele modelo, não o modelo de capital de VC em estágio seed
    • Entendo totalmente a preocupação; ela é válida e a ouvimos com frequência
      Talvez não consigamos convencer pelo argumento comercial, mas estamos fazendo uma aposta calculada de que uma oferta gratuita generosa será vantajosa no longo prazo
      Vemos este produto como algo que cria confiança com desenvolvedores e que, no futuro, será um canal de distribuição eficiente. Uma estratégia de open source comercial sem monetização no início é bastante comum
      Felizmente, há alguns investidores de venture capital dispostos a apoiar empresas com produtos open source comerciais populares
      Ainda somos uma empresa em estágio inicial, vamos aprofundar os produtos existentes e, com o tempo, também oferecer novos produtos. Vamos cobrar por novos recursos e novos produtos, e consideramos aceitável levar alguns anos até chegar a uma receita ou fluxo de caixa significativos

  • É louvável terem lançado como open source e disponibilizado um serviço fácil de usar
    Além disso, se isso se tornar uma implementação popular e de boa qualidade, outros provedores de serviço também poderão ter mais facilidade para integrar com usuários deste software
    Já implementei várias integrações de SSO com F500 do zero, e como cada uma era personalizada, mesmo sendo “SAML” elas não eram necessariamente interoperáveis. Com um software como este, talvez funcione por padrão
    Fico curioso para saber quão bem vocês conseguirão manter a segurança ao oferecer SSO hospedado gratuito, de modo que os clientes não sejam comprometidos por meio de vocês
    Também será um ponto único de falha para todos os clientes, então fico curioso se há garantia de uptime também no nível gratuito. Também me pergunto se conseguiriam oferecer isso a um preço acessível para startups que querem hospedagem, mas precisam de SLA

    • A segurança do SSO hospedado gratuito é realmente importante. Não há resposta curta; é simplesmente uma questão de fazer direito o que precisa ser feito
      Em relação ao SOC2, estamos trabalhando com a Oneleet, e todos sabemos que o SOC2 é em grande parte teatro, mas também estamos conduzindo um teste de intrusão bastante minucioso. Se quiser, posso enviar os resultados por e-mail
      Na prática, somos uma empresa que precisa fazer esse tipo de coisa direito
      As garantias de uptime do nível gratuito serão combinadas caso a caso e dependerão do que for necessário. Levamos garantias bastante a sério, então somos cuidadosos ao prometer
      Não queremos ser uma empresa de serviços nem ganhar dinheiro com “suporte premium”. Dito isso, se você quiser SLA, haverá uma pequena cobrança
      Seria bom reformular a pergunta “o provedor de nuvem vai pegar os clientes que usam este software?”

  • O maior obstáculo do SAML hoje em dia parece ser a integração com produtos SaaS. Já passei por muitas situações em que era preciso trocar e-mails com a equipe de suporte, e alguns fornecedores simplesmente enviavam um PDF de 204 páginas só sobre a configuração de SSO
    O mapeamento de atributos ainda é uma bagunça, e é surpreendente que a experiência do usuário ainda seja tão ruim

    • Já escrevi um desses PDFs de 204 páginas no passado. Na prática acho que tinha umas 20 páginas, mas como os IdPs não facilitam a configuração para os clientes, no fim cabe ao provedor de serviço — ou seja, nós — documentar para o cliente como usar o IdP dele
      Acabamos de lançar um recurso para esse problema. Em vez de criar um PDF de 204 páginas, você gera no SSOReady uma URL de configuração e a entrega ao cliente; ao acessar essa URL, ele consegue configurar a conexão SAML com o produto por meio de uma UI self-service
      https://ssoready.com/docs/idp-configuration/enabling-self-se...
    • O suporte a SSO consumia mais de 50% do tempo de atendimento ao cliente da nossa equipe de engenharia
      Uma das maiores dificuldades era que o usuário precisava envolver outro departamento, que era quem realmente controlava o sistema de SSO, e esse departamento não tinha muito incentivo para fazer tudo funcionar rapidamente, então os tickets se arrastavam
      Também ficávamos parecendo os vilões por precisar receber certas informações do cliente
    • A OKTA faz isso bem, mas você precisa poder gastar na faixa de US$ 20 mil por ano ou mais

  • Muito legal. Fiquei curioso com a parte de “planejamos monetizar no futuro criando recursos adicionais para grandes empresas com requisitos complexos”
    Queria saber se algo nesse nível foi suficiente para passar no processo de inscrição da YC, e quanto eles deram importância ao modelo de negócios para investir

    • Para ser sincero, quando entramos na YC estávamos trabalhando em outro projeto. Queríamos criar um software de limpeza de dados com LLMs, até perceber que ninguém se importa tanto assim com dados bagunçados
      Um dos motivos pelos quais nos sentimos confortáveis oferecendo um nível gratuito generoso é o fato básico de que ajudar empresas SaaS a oferecer login SAML não é um mercado tão grande. De qualquer forma, teremos que ganhar dinheiro com outros produtos
      “Monetização de recursos adicionais” se refere ao produto SAML que oferecemos hoje, mas também vamos lançar outros produtos
      O objetivo de longo prazo é criar uma empresa parecida com a Auth0, mas open source e amigável para desenvolvedores

  • Estou procurando uma alternativa mais econômica ao WorkOS, então isso veio em boa hora. Estou criando um portal empresarial de validação de dados e pretendo testar
    Assim que integrar com o Entra ID, há algum guia que eu deva consultar? É mesmo só uma questão de ter um endpoint de API?

    • Olá, sou o Ned, outro cofundador da SSOReady
      Isso mesmo. O código que você escreve cobre todos os IdPs, e as diferenças específicas de cada IdP ficam nos valores de configuração de cada cliente
      Por exemplo, há pouco tempo organizamos uma documentação específica para Entra: https://ssoready.com/docs/idp-configuration/guides-for-commo...
      Fico curioso para saber se isso atende ao que você precisa
    • Sou o fundador da WorkOS
      Temos descontos por volume automáticos para usuários no modelo pay-as-you-go, e planos anuais ou contratos personalizados podem ter preços ainda menores. Também oferecemos créditos gratuitos para empresas em estágio inicial
      Se quiser conversar, pode entrar em contato pelo mg@workos.com
      Hoje centenas de empresas, incluindo muitas startups, usam a WorkOS: https://workos.com/startups

  • Implementei integração de SSO em uma empresa anterior e o SAML parecia tão doloroso que fizemos apenas OIDC2
    Não sei se ainda é assim, mas durante um tempo a Okta não permitia OIDC para SSO em uma integração Okta que usasse SCIM; para SSO era preciso usar SAML
    Contornamos isso criando duas integrações Okta separadas, uma para SSO e outra para SCIM. Sempre era chato explicar isso ao departamento de TI do cliente, mas ninguém reclamava, então não tivemos que implementar SAML

  • Parece bom. Há planos de adicionar SCIM?
    SAML é ótimo, mas, pela minha experiência, um dos principais motivos pelos quais clientes grandes querem SSO é o desprovisionamento automático, para remover de uma vez o acesso de um funcionário a todos os apps quando ele sai da empresa. Para isso é preciso SCIM
    Com SAML mais SCIM, ou mesmo só um pequeno subconjunto de SCIM, acho que eu escolheria quase sem pensar. Outros serviços são fechados e absurdamente caros, e implementar por conta própria é um sofrimento enorme

    • SCIM será adicionado em breve. Vejo recursos ligados a desprovisionamento automático e gestão de assentos como grandes motivações
      Para ser honesto, a IETF fez um trabalho bem bom no SCIM em si. Não é esquisito como o SAML. Pela minha experiência, a parte mais difícil das integrações SCIM é acertar a configuração específica de cada IdP
      Assim como no SAML, Okta, Microsoft e OneLogin chamam exatamente a mesma coisa por termos completamente diferentes
      Um dos recursos que esperamos oferecer é um botão para gerar um link de configuração para entregar ao cliente. Por esse link, o cliente poderá configurar a composição SAML+SCIM em modo self-service
      Isso já funciona hoje com SAML, e é bom não precisar escrever documentação específica para cada IdP explicando a terminologia estranha e as UIs peculiares de cada produto

  • Parabéns pelo lançamento. Como se compara ao SAML Jackson[1] da BoxyHQ?
    [1]: https://github.com/boxyhq/jackson

    • Acho que a BoxyHQ faz um bom trabalho
      Há basicamente dois motivos pelos quais preferimos nossa abordagem
      Primeiro, a BoxyHQ quer SAML-over-OAuth. Nós damos suporte a isso, especialmente pela compatibilidade com NextAuth, mas nem sempre acho que ajuda
      Segundo, acredito que nosso serviço é mais fácil de usar. A reclamação que ouvimos com mais frequência de usuários e clientes é a complexidade, então nos esforçamos bastante para tornar o SAML claro e simples. No fim, cabe aos usuários julgar se atendemos a esse padrão

  • Estou escrevendo minha primeira política personalizada para o IdP B2C da Microsoft, e o processo é doloroso
    Tornar autenticação e SSO menos dolorosos pode, de fato, melhorar o mundo. Os apps ficam mais seguros, as pessoas se frustram menos ao usá-los, e o estresse de gente como eu também diminui

    • “Tornar autenticação e SSO menos dolorosos” é algo que, pensando bem, dá para dizer que OAuth2 + OIDC conseguiu fazer. Empresas como a Atlassian entenderam isso
      http://id.atlassian.com