Skip Navigation Links
Novas Tecnologias
Ferramentas Adicionais
Ferramentas Adicionais
Detalhes de hosting e/ou: tem que ser muito macho
Data:11/30/2007

Translate this page now :





Categories: Tecnologia , Servidores

Gostou do texto ? Vote e dê sua opinião! Pontuação atual :
Adicione aos Favoritos!
BlogBlogs Rec6 Linkk Ueba Technorati Delicious DiggIt! StumbleUpon

Veja Também



(Originalmente publicado no TheSpoke dia 13/09 )

Estou aplicando um treinamento de ASP.NET Avançado. Adoro treinamentos avançados. São mais interessantes (não que os básicos também não sejam) e por estarem sendo menos executados, são mais imprevisíveis.

Durante as explicações de NLBS, explicações que faço diretamente no IIS, alguém comentou sobre o fato de que jamais deixariam a senha de SA ser utilizada para conexão ao banco.

Pronto. Bastou ter tempo em uma aula e outra para pensar e resolvi que seria legal falar sobre a configuração da string de conexão com autenticação integrada, sendo que eu próprio não previa esse tópico, mas achei que valia a pena e estava certo, a aula foi interessante e os alunos viram algo que de outra forma dificilmente veriam (isso hoje seria explicado onde ? Em um curso de IIS ? Mal explicado, além de que dificilmente os desenvolvedores iriam fazer um curso de IIS...)

Mas tem que ser macho mesmo para resolver aplicar um determinado tópico assim, repentinamente. As chances de você ter um problema são muito grandes, vide Murphy.

Sempre acontece o inesperado, desta vez não foi diferente.

O site, em um diretório virtual, estava configurado para guardar sessão em banco, no SQLServer.

A string de conexão foi alterada para conexão integrada. Tudo conforme esperado, ele assume o usuário Network Services que está no application pool do IIS 6.

Troco o usuário para um user personalizado dentro do grupo IIS_WPG e faço funcionar. Muito legal, tudo funcionando que é uma maravilha.

Mas o application pool contém muitas aplicações, então o usuário precisaria ter acesso ao banco de todas elas. E para separar ? Criar muitos pools não é bom, gera excesso de processos/threads. Então adiciona-se o identity impersonate no web.config, volta-se o usuário do application pool para network services e altera-se o usuário anônimo para um usuário personalizado.

O fato de usarmos o identity impersonate faz com que o ASPNET passe a assumir a identidade do usuário anônimo do IIS e não mais a identidade do application pool (que agora voltou a ser network services).

Então tudo funcionando maravilhosamente bem, certo ?

Errado. Executei o exemplo sobre uma configuração de sessão armazenada em banco, a string de conexão de sessão estava configurada com segurança integrada.

Resumindo o resultado inesperado : O acesso ao banco de sessão acontece ANTES do identity impersonate com usuário anônimo do IIS, isso faz com que o identity impersonate com usuário anônimo do IIS seja válido para todo o site, mas não para o controle de sessão em banco, nesse caso ele continua usando a identidade do application pool para o controle de sessão em banco.

Só isso ?

Na aula só. Mas fiquem atentos : O identity impersonate para o usuário anônimo do IIS só acontece após determinados eventos da sequencia de chamada ao servidor, tal como o acesso ao banco do ambiente de sessão. Então se você construir um httpModule para interceptar algum evento específico, deve ter atenção ao fato de que aquele httpModule talvez não rode com a mesma identidade que o resto do site, dependendo do evento que você está interceptando.

Interessante... pois é, mas não para por ai.

É óbvio que não ia deixar de explicar que essa configuração toda não funciona para windows authentication. Pois se resolvemos utilizar windows authentication em nossa aplicação e ao mesmo tempo utilizamos o identity impersonate acabaremos por personificar o usuário que está no browser, este usuário irá acessar o banco e na melhor das hipóteses perderemos MUITA escalabilidade ao jogar fora o pooling de conexões.

A solução neste caso é usar o identity impersonate com a especificação de usuário e senha. Neste caso a identidade do usuário personificado ficará dentro do web.config. Poderemos então usar windows authentication livremente e nossa aplicação personificará o usuário indicado no web.config, não o usuário windows.

Certo ? Errado.

Alguns alunos resolveram passar a teoria para a prática e colocar a identidade do usuário ali, só para ver mais um ataque de Murphy.

Não é que o comportamento do identity impersonate muda quando o id e senha do usuário é especificado ? Com o ID e senha do usuário especificados a "sequencia de eventos" muda e no final temos que o identity impersonate se sobrepõe ao usuário do application pool, com isso passamos a ter um usuário único para o acesso ao banco de sessão e ao banco da aplicação.

Resumindo : Podemos usar a identidade do application pool para tudo, mas teremos um usuário único para muitas aplicações o que muitas vezes não é um nível de segurança aceitável. Então utilizamos o identity impersonate e passamos a utilizar o usuário anônimo do IIS, sendo que este terá que ser personalizado para um usuário de domínio, mas o usuário anônimo do IIS só será "incorporado" a aplicação após um (in)determinado evento na sequencia de execução da página, consequentemente não sendo utilizado para sessões em banco entre outras coisas. Porém se inserirmos o ID e senha do usuário no identity impersonate passamos a utilizar um usuário único novamente para todas as "partes" da aplicação, ou pelo menos todas que identifiquei.

Só isso ?

Não. Isso é no IIS 6. No IIS 5 era diferente. No IIS 6 configurado para compatibilidade com IIS 5 é diferente. No IIS 7 é diferente.

Depois, quando passo batido no curso básico pela explicação de string de conexão integrada, apenas dizendo que são necessárias configurações no servidor web mas que esse não é o foco do curso no momento, ainda tem gente que me olha com cara de bunda achando que estou sonegando informação.

Livros

Que tal visitar nossa loja de livros e analisar alguns livros sobre o IIS 5, 6 e até mesmo o IIS 7 ?



Categories: Tecnologia , Servidores


Nome :
E-mail:
Comentarios :
 
 
Os Últimos Comentários
Nenhum comentário foi realizado ainda. Seja o primeiro !
Dicas
Dica do Dia
Receba Dicas Por Email
E-mail :  
 


 (help)
Aceito receber informativos do devASPNet, informações de eventos e treinamentos

Veja Quais Informativos Você Receberá

Pesquisar Dicas
Pesquisar Artigos, Dicas e Noticias

Banco de Dados
Algumas Entrevistas
Links Importantes

Búfalo Informática, Treinamento e Consultoria
R. Alvaro Alvim, 37/920 Centro - Cinelândia - Rio de Janeiro Cep: 20031-010
Tel : (21) 2262-1368 (21) 9240-5134 E-mail : Contato@bufaloinfo.com.br