Como posso integrar ambientes de desenvolvimento web locais com uma solução SSO central?

5

Temos um aplicativo da Web de página única e temos um novo site de SSO (também o nosso próprio) usando o OAuth2 e estamos procurando conectá-lo.

Em nossas implantações de produção / preparação / CI, é fácil conectar tudo. Por exemplo:

  • na produção, teremos https://app.company.com acessando nosso backend de prod para https://sso.company.com para auth e vice-versa
  • no IC teremos https://app.ci.company.com acessar nosso backend de desenvolvimento e apontar para https://sso.ci.company.com para autenticação.

Quando estamos desenvolvendo o aplicativo, acessamos localmente em algo como http://localhost:8000/ e ele aponta para o back-end de desenvolvimento compartilhado. No passado, nós tínhamos apenas fazer sua própria autenticação no backend de desenvolvimento (obtendo as credenciais do usuário final e submetendo-o), mas gostaríamos de fazer com que fosse usado para usar o SSO para autenticação.

A questão surge de como podemos fazer isso sem que todos os desenvolvedores que desejam desenvolver localmente precisem configurar e personalizar seu próprio serviço de SSO. Especificamente, podemos usar o SSO dev / CI compartilhado e apontar para nossas implantações locais?

O que consideramos:

  • Use um arquivo de proxy / arquivo de hosts e tenha http(s)://sso.ci.company.com aponte para http(s)://localhost:8000 . Isso sobrecarrega a configuração local do HTTPS ou o direcionamento do SSO para um URL não HTTPS. Além disso, a configuração é um pouco dolorosa.
  • Solicite que nosso aplicativo local redirecione para o SSO com um argumento que se identifique e faça com que o SSO use isso para saber para onde redirecionar. Por exemplo, redirecione para https://sso.ci.company.com/?appUrl=localhost:8000 . Isso nos obriga a perfurar um redirecionamento aberto no SSO que teríamos que desativar para produção e é um pouco "estranho", mas funciona e pode ser inserido no aplicativo.
  • Basta executar o SSO localmente em todas as caixas de dev. Esta é basicamente a não-solução, pois exigiria muita configuração para chegar a um script "uma caixa que pode executar tudo", e ela nega uma de nossas valiosas vantagens no momento em que basicamente tudo que você precisa fazer é verificar o código em qualquer sistema e tê-lo em execução. Eu já vi isso antes de comumente (muitas vezes no topo de dev VMs); Eu gostaria apenas de explorar as opções com as quais estamos potencialmente mais próximos.

Existe uma solução para esse tipo de problema ou aspectos de nossas idéias que ainda não consideramos?

    
por Steven Xu 15.10.2013 / 03:43
fonte

1 resposta

3

Trabalhei anteriormente em um ambiente em que tivemos SSO e ambientes de desenvolvedores locais.

O principal problema que precisa ser trabalhado com SSO e ambientes de desenvolvedor é que o cookie de domínio precisa ser recuperado ao atingir o ambiente de desenvolvimento local.

Admito que parte disso tem a ver com a forma como montamos o ambiente (e foi há muitos anos que eu estava envolvido nisso). Era um ambiente poliglota com uma mistura de html estático, perl cgis antigo, um servidor weblogic para Java EE, um servidor iis para alguns aplicativos que precisavam ser executados com asp e algo que a engenharia executava. A forma como o SSO comunicou essas informações era que um proxy reverso colava no cabeçalho do http o nome de usuário autenticado e todo o acesso associado que tinham. Dessa forma, não importa quem tenha conseguido, eles podem olhar para os cabeçalhos e continuar de lá.

Primeiramente, o DNS foi configurado para que cada desenvolvedor tivesse um nome de host no domínio 'dev.company.com' - assim, 'sxu.dev.company.com' (para você) e 'jsmith.dev.comapny .com 'para John Smith. Todos esses nomes (CNAMES) apontavam para um único proxy reverso dev comum (o proxy reverso tinha muito pouco nele) que, então, examinava o nome do host virtual que estava sendo enviado e encaminhava o pedido para a máquina do desenvolvedor apropriado. Observe que as interações com o código SSO foram completamente contidas no proxy reverso, de modo que nenhuma biblioteca adicional precisou ser instalada em nenhum outro lugar.

A interação com a infraestrutura era simplesmente adicionar outra cname a common.dev.company.com sempre que tivéssemos uma nova contratação e, em seguida, adicionaríamos seu nome a um arquivo que fosse executado por meio de algumas macros m4 para gerar o apache adequado arquivo http.conf para o proxy reverso (que levou algum trabalho na primeira vez ).

Com essa idéia, você pode querer considerar a criação de um proxy reverso que atue apenas para encaminhar tudo para a máquina do desenvolvedor apropriado através de http (não importa o tipo de conexão recebida). https://sxu.ci.company.com/xyz vai para o proxy reverso, que lida com os https e os encaminha para sua caixa dev em http://10.1.2.3/xyz . A pegadinha com essa abordagem que você deve observar é que, se tiver algum caminho absoluto no código, ou o servidor do desenvolvedor tentar estar ciente de onde ele está instalado e do protocolo usado para gerar um link com o mesmo formato, as coisas podem ficar um pouco complicadas (isso é um termo técnico).

Isso evita o problema de configurar https localmente (apenas um servidor está executando https) ou modificar o servidor sso para ir para um URL não https. Você tem configurações diferentes em um lugar diferente.

Não tenho certeza se suas caixas locais dev responderão ao acesso diferente de localhost (sua configuração é válida), se assim for, elas precisarão ser modificadas porque a solicitação está vindo do proxy neste caso, em vez do navegador local.

Eu quero ressaltar o benefício colateral que isso significará que outros desenvolvedores podem atingir seu ambiente (você quer que alguém reproduza um bug enquanto você está observando os arquivos de log que você não sabe como repo) eles atingem o seu servidor).

A segunda opção é uma abordagem não-padrão (lembro-me de vários sistemas SSO de produção sendo configurados para permitir um conjunto limitado de parâmetros do tipo appUrl - em parte para que a pessoa externa pudesse usar o SSO e ir para uma página específica uma vez logado. Adicionar um mapeamento de 'dev- > localhost: 8000' permitiria isso, no entanto você precisará reconsiderar como resolver o problema de localhost não obter cookies da empresa.com Você provavelmente precisará modificar suas caixas locais para identificar como localhost.company.com para que isso funcione.

    
por 15.10.2013 / 04:32
fonte