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.