Hola Pablo, Huy es largo :) Para mi el esquema de seguridad esta divido en tres niveles: usuario de la aplicación, usuario del proceso y usuario de motor de base de datos. En realidad no para mi, si no para MS en http://www.microsoft.com/spanish/msdn/arquitectura/BuildSecNetApps/html/Secu rityGuide-LandingPage.mspx También el modelo que vos planteas es correcto, pero no me queda del todo claro cuales serian sus ventajas. 1. Entonces tengo un modelo de autenticación en web: windows, forms o passport. 2. Tengo un usuario, que puede ser ASPNET u otro, que corre el proceso de asp.net. 3. El usuario con el cual me conecto al motor de base de datos por medio de suplantación de identidades. En el nivel 1, manejo yo (Asp.Net) el nivel de autorización en base a un esquema de permisos por funciones de Asp.Net. En el nivel 2, solo configuro el nivel de autorización que requiere la aplicación a un único usuario (ASPNET u otro en general). A este usuario le puedo sacar permisos para que no se conecte por la red a mi servidor, con lo cual creo otro punto más de control. En el nivel 3, tengo otro usuario para base de datos. Aquí generalmente ejecuto stored procedures, con lo cual tengo otro nivel de control (solo puede ejecutar procedimientos existentes). Entonces, de esta manera, ahorro en tareas de administración cada vez que necesito crear un usuario de la aplicación. Porque solo creo sus credenciales en el primer nivel. No toco los permisos del servidor. No toco los permisos del motor de base de datos. No necesito licencias para muchos usuarios de SQL Server, con dos me alcanza. Por otro lado, cuando tengo problemas en la base de datos, cuando un usuario me bloquea la base, busco porque llego a bloquearla. Busco que puntos de control en todo el sistema fallaron. De este modo yo establecí un sistema con bloqueos de procesos (a nivel asp.net), que permiten que determinadas consultas las pueda hacer solo un usuario a la vez, dado que cuando se producen estos procesos no hay recursos suficientes. O simplemente son transaccionales para todo el sistema y debo bloquear parte de la base de datos. "Y también, 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." Este tema es de la configuración que tengas de application pooling, si aíslas el proceso no habría inconvenientes. Pero aplica para los dos esquemas. No quiero escribir mucho :) Abrazo grande! Damián Herrera
_____ De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Pablo A. Allois Enviado el: Miércoles, 12 de Diciembre de 2007 05:17 p.m. Para: [email protected] Asunto: [puntonet] Current User 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
