Aplicativo Web - Autenticação de usuário em domínios

Question

Um cliente nosso nos procurou para desenvolver uma aplicação e, como sempre, o escopo cresce a cada dia.

Inicialmente, começou como um aplicativo dedicado confinado à rede corporativa.A autenticação do usuário foi estabelecida adquirindo o login do usuário no Windows e utilizando um banco de dados SQLServer para hospedar os direitos de acesso.Tudo muito simples.

Eles agora querem o seguinte:
- Aplicativo para ser baseado na Web
- Aplicativo a ser hospedado fora da rede corporativa
- Autenticação de usuário para funcionar da mesma forma (sem uso de senhas, apenas logins do Windows)

Para complicar ainda mais, eles desejam que as diversas funções do aplicativo possam ser utilizadas por outro aplicativo que apenas dispara solicitações HTTP.
- O usuário faz login na rede corporativa
- Usuário lança aplicativo corporativo
- O usuário processa detalhes do cliente
- O usuário clica em um botão
- O aplicativo corporativo dispara uma solicitação HTTP para nosso aplicativo web hospedado
- A solicitação HTTP incluiu a autenticação necessária e os detalhes do cliente
- A autenticação do usuário é concluída 'automaticamente' (sem envolvimento humano)
- Os dados do cliente são transmitidos com segurança

Eles estão muito interessados ​​em que façamos isso por eles, pois nossa abordagem inicial era exatamente o que eles queriam.Eles ainda querem que façamos isso, embora esses aplicativos da web hospedados não sejam nossa especialidade.Então agora abordo os especialistas;
- Alguém tem algum conselho sobre como abordar isso?
- Alguém tem algum aviso sobre as possíveis armadilhas a evitar?

Answer 1

Basicamente, eles estão falando sobre acesso federado.Você hospedaria um ponto de autenticação dentro de sua rede que, por sua vez, encaminharia um token para seu aplicativo, que o analisaria e permitiria (ou interromperia o acesso).Isto é bastante normal, e a MS fornece uma boa base para isso no Quadro de Genebra.Isso também funcionará para chamadas de serviço da Web, desde que eles possam alterar seu aplicativo para usar o WSFed como protocolo e conversar com um serviço de token de segurança que emite silenciosamente o token de autenticação.Na maioria dos casos, você usará SAML para isso.Ele também tem a vantagem adicional de os detalhes de autenticação nunca saírem de sua rede corporativa.

A sugestão de autenticação baseada em certificado é interessante, mas requer mais trabalho na implementação de uma infraestrutura PKI.Isso pode custar caro.

CardSpace não funciona - não é silencioso como eles parecem querer.OpenID também não é inicial, mas também não é silencioso.

Pontos extras se você estiver olhando para o Azure - os bits de autenticação do Azure também usam SAML/WSFed nos bastidores e contêm pedaços de Genebra.Portanto, se você migrasse para a nuvem, cada um de seus clientes teria apenas que configurar uma página de login em sua rede - tudo o que você teria que fazer é confiar que essa página emitirá tokens de autenticação para você e os analisará de acordo com suas regras.

Answer 2

Talvez comunicação WCF com autenticação baseada em certificado, ou seja,aos usuários externos que utilizam o serviço, a empresa lhes fornece um certificado válido.Isso não exigiria uma senha de nome de usuário, mas levaria o usuário diretamente.

Answer 3

Você já deu uma olhada SAML?

Answer 4

Confira Windows CardSpace uma vez que se integra ao login do Windows e permite o cenário SSO necessário.

Answer 5

Dependendo de como seu aplicativo é construído, você pode mexer no machineKey em seu web.config para permitir chamadas AJAX com logon único (SSO).Isso envolveria um pequeno aplicativo asp.net na rede corporativa apenas para distribuir tokens de autenticação e redirecionar para seu aplicativo hospedado.

Se os dois aplicativos compartilharem o mesmo machineKey, o sistema de autenticação asp.net permitirá que os usuários entrem em seu aplicativo hospedado.

Existem problemas com esta abordagem:

• Você introduz outra dependência em seu sistema (o aplicativo de autenticação na rede corporativa). Será um aplicativo simples, mas você enfrentará problemas ao tentar diagnosticar problemas se não tiver acesso.
• Você precisa que seu serviço hospedado esteja no mesmo domínio que o aplicativo de autenticação (para que o tíquete de autenticação no cookie HTTP seja transmitido).
• Você também precisará de um certificado SSL para seu serviço hospedado para proteger as informações.(Não é realmente uma desvantagem em si, você provavelmente gostaria de fazer isso de qualquer maneira.)
• Como você e seu cliente terão uma machineKey compartilhada, você vinculará uma instância do seu aplicativo a esse cliente específico.

Answer 6

Eu usaria um provedor/servidor OpenID privado para isso.