Como autenticar um usuário através da troca de certificados?

Question

Eu tenho um aplicativo da web A onde um usuário precisa se autenticar por meio de um método de nome de usuário / senha ( link ). Uma conexão segura é estabelecida (HTTPS) com o servidor A.

Então, esses caras querem algum tipo de "truque" para usar esse mesmo usuário autenticado para abrir um URL diferente ( link ) e ainda ter certeza de que a autenticação não está quebrada. Em outras palavras, eles não querem que o usuário insira suas credenciais novamente para o webappB. Além disso, este novo webappB não deve ser acessível a usuários não autenticados.

O WebappB está sendo executado no Tomcat e pode estar hospedado no mesmo servidor em uma porta diferente #. Nosso trabalho poderia ser muito mais fácil se o webappA tivesse um sistema de autenticação bem conhecido como o LDAP, mas eles não o fazem. WebappA é da Empresa A e WebappB é da empresa B.

Existe alguma possibilidade de que isso funcione? Eu pessoalmente não vejo como, então eu posso tentar com vocês. Estou livre para instalar qualquer mod ou servidor do Apache que eu precise.

    

Answer 1

Isso não é muito complicado, supondo que ambos os aplicativos possam acessar dados de sessão semelhantes. Mas só se você pode mexer com o código um pouco. Já que você está falando sobre diferentes empresas que fornecem o software, a segunda parte pode não ser possível.

Basicamente, quando uma sessão é iniciada com AppA , o nome de usuário / senha é verificado em alguma fonte (seja um banco de dados, servidor IMAP, servidor LDAP, o que for), essa não é a parte importante do processo. Depois da primeira coleta de nome de usuário / senha, um token de sessão é emitido. AppA verifica o token da sessão no acesso e se for válido; carrega a sessão (por isso não requer nome de usuário / senha toda vez que você faz alguma coisa).

Para que isso funcione, você precisa de AppB para (a) poder acessar a sessão token (fácil, é provável que seja armazenado como um cookie), < em> (b) acessa os dados da sessão que listam os tokens válidos e os relacionados ao usuário (se o usuário não estiver incluído no token no cookie) e (c) cria uma sessão no AppB sem nome de usuário / senha inicie ou valide com a sessão existente.

Acesso ao token de sessão:

Isso deve ser apenas uma questão de ler os cookies fornecidos para AppB . Contanto que AppA emita o cookie sem um valor restritivo de path (baixo risco, pois a Empresa A não pode conhecer todas as pastas em que AppA poderia operar).

Acesso aos dados da sessão:

Normalmente, um aplicativo armazena informações de sessão em algum tipo de tabela de banco de dados. O único truque pode estar aprendendo o nome de usuário associado a uma sessão (o token pode incluir nome de usuário ou algum tipo de ID ou nenhum). A validade da sessão, conforme definida por AppA , deve ser obedecida por AppB

Criar sessão do AppB:

Provavelmente a parte mais complicada, se AppB tiver injeção de dependência no módulo de autenticação (incluindo início da sessão, detecção de sessão e término de sessão), é apenas uma questão de fazer com que o aplicativo leia o mesmo token de sessão como AppA , compare / valide os dados da sessão e traduza e amplie, se necessário. Observação a menos que ambos os aplicativos sejam modificados, você também vai querer que AppB adie logins e possivelmente logouts para AppA

Segurança:

Se AppA usar um cookie para armazenar / recuperar informações de sessão sem um aviso de valor de caminho, qualquer outra parte do mesmo site também poderá ver esse cookie. Se algum site for exibido em http , incluindo imagens, folhas de estilo e javascript, este cookie de sessão será exposto e poderá ser obtido por sniffing de software (como firesheep) ou hardware. A exibição de conteúdo estático de um servidor diferente (ou mesmo servidor com um nome diferente) ajuda a atenuar isso.