Hola Damian,
Primero, a mi modo de ver impersonalizacion es un tema autenticacion, me
parece que nos referimos a diferentes scopes de la seguridad. Un scope para
dentro de la aplicacion web, el otro para los recursos que usa la
aplicacion.
Como todo hay que evaluarlo en cada caso, pero en rasgos generales
considero que lo mas adecuado es impersonate=true y me planteo como
excepciones los caso en que uso impersonate=false.
La razon por la que me parece mas seguro impersonate=true es que puedo
hacer mas granular la seguridad de los recursos que utilizan los web sites.
Y ahi vamos con un ejemplo para que quede claro:
Tengo un Server con dos web sites, con impersonate=false, tengo que
darle permisos al usuario aspnet o network service en las dos bases de datos
que usan.
Tengo un Server con dos web sites, con impersonate=true, tengo que darle
permisos a los usuarios, segun la base de datos que necesitan.
La otra razon, es que me parece mas clara la seguridad con
impersonate=true ... el usuarioA tienen permisos a la base de datos A porque
la necesita usar la aplicacionA.
En cambio, con impersonate=false ... el usuarioA no tiene permisos a la
base de datos A, pero aspnet los tiene porque los dos websites trabajan con
las bases de datos. No me parece, desde el punto de vista de administracion
muy prolijo.
Tambien, cuando tenes queries que se comen una base de datos, haces
sp_who y decis, ... ya se quien fue .... aspnet, saquenle el teclado a ese
usuario... resulta ser que no podes identificar quien disparo una consulta
en la aplicacion que genero el exceso de utilizacion de recursos, y ni
siquiera podes identificar que aplicacion web lo genero.
Y tambien, si administras la seguridad con un impersonate=false, ante un
fallo de seguridad en una aplicacion web, el danio lo pueden hacer en los
recursos de todas las aplicaciones web.
Es mi humilde opinion, sinceramente no es un parametro que me guste
poner en false.
Ya me hiciste escribir, ahora de escarmiento, termina de leer el mail y
contame porque te gusta impersonate=false.
Saludos!
_____
De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Damián
Herrera
Enviado el: Miércoles, 12 de Diciembre de 2007 04:44 p.m.
Para: [email protected]
Asunto: [puntonet] Current User
Hola Pablo,
Perfecto. Sorry, pero a mi entender, en tu respuesta no esta clara la
diferencia entre autenticación e impersonalización. Para el problema que
tiene Ray no hace falta impersonalizar y no lo recomendaría. Solo eso :)
Por otro lado, de chusma nomás, ¿en que ambientes necesitaste impersonar con
autenticación windows? Me llamo la atención este tipo de esquema en base a
tu mail.
Saludos,
Damián Herrera
_____
De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Pablo A.
Allois
Enviado el: Miércoles, 12 de Diciembre de 2007 02:58 p.m.
Para: [email protected]
Asunto: [puntonet] Current User
Si Damian, a eso me referia con:
"Si, cambias el parametro y estas en un entorno productivo, tene cuidado,
porque podes recibir un acceso denied debido a que tu aplicacion web se va a
ejecutar como otro usuario que puede no tener permisos a recursos que
utilice tu aplicacion. "
Saludos!
_____
De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Damián
Herrera
Enviado el: Miércoles, 12 de Diciembre de 2007 01:19 p.m.
Para: [email protected]
Asunto: [puntonet] Current User
Hola Pablo,
Tengan cuidado con eso porque pasamos sin darnos cuenta de un tema de
Autenticación a uno de Impersonate. Si queres saber el usuario que inicio
session en tu web app tenes que usar:
System.Web.HttpContext.Current.User.Identity.Name
Mas allá del tipo de autenticación: Windows, Forms o Passport.
Hacer impersonalización basada en la autenticación windows es un esquema muy
distinto. Hay que pensar de antemano todas las autorizaciones que deben
tener las identidades que inicien session.
Saludos,
Damián Herrera
_____
De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Pablo A.
Allois
Enviado el: Miércoles, 12 de Diciembre de 2007 12:45 p.m.
Para: [email protected]
Asunto: [puntonet] Current User
Estas corriendo con identity impersonate=false, por eso lo que hagas lo que
haces con el usuario que esta corriendo el worker process (ApplicationPool,
el exe) .
Si le pones identity impersonate = true, lo que ejecute tu aplicacion web lo
va a hacer con el usuario logueado.
El usuario logueado puede ser:
- El usuario anonimo configurado en el website
- El usuario que ingresa sus credenciales, si tenes seguridad integrada,
basic o realm en el website
Si, cambias el parametro y estas en un entorno productivo, tene cuidado,
porque podes recibir un acceso denied debido a que tu aplicacion web se va a
ejecutar como otro usuario que puede no tener permisos a recursos que
utilice tu aplicacion. Desde el punto de vista de la seguridad, me parece lo
mas sano el identity impersonate=true.
Saludos!
_____
De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de HV-Raynier
Rivero Mayo
Enviado el: Miércoles, 12 de Diciembre de 2007 12:17 p.m.
Para: [email protected]
Asunto: [puntonet] Current User
Hola Colegas:
Tengo una aplicación que en uno de sus formularios inserta a modo de traza
el usuario que guardó determinado registro, como:
<authentication mode=Windows />
usé:
Environment.UserDomainName.ToLower().ToString() + "\\" +
Environment.UserName.ToString();
El tema es que debugueando cuando inserto la encuesta se graba en la BD el
usuario con el que tengo iniciada la sesión, hasta ahí todo bien, pero
cuando publico en IIS se registra en la traza el usuario para el servicio
que es ASPNET.
¿alguna idea cómo saber realmente el current user que esté logueado? Gracias
de antemano
Saludos,
Ray
