Felices fiestas! _____
De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Damián Herrera Enviado el: Jueves, 13 de Diciembre de 2007 11:34 a.m. Para: [email protected] Asunto: [puntonet] Current User Hola Pablo, Creo que la idea se entendió. No quiero seguir con este thread porque creo que hablamos de entornos muy distintos. Lo mio aplica a aplicaciones empresariales. Por lo que vi, vos trabajas en un ISP y tu contexto es muy distinto al mio. Si queres, algún día nos juntamos y lo hablamos mejor. No soy amigo de largos mails explicando mi opinión :) Abrazo grande y felices fiestas!!!! ya casi estamos!!! Damián Herrera _____ De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Pablo A. Allois Enviado el: Jueves, 13 de Diciembre de 2007 09:02 a.m. Para: [email protected] Asunto: [puntonet] Current User Ay Damian, me haces leer y escribir temprano, no es justo. A ver, contame, en ese modelo, si el usuario Pepe Gonzalez, tiene que acceder a dos aplicaciones, vas a crear a Pepe Gonzalez en dos aplicaciones y le vas a dar permisos en la aplicacion ? Fijate las repsuestas entre lineas. Me parecen dos modelos validos que se adaptan mejor uno u otro a distintos entornos. Pero, sinceramente mi opinion, es que las aplicaciones web deberian poder adaptarse a ambos modelos, con poco laburo podemos hacer que funcionen en ambos modelos. Y dejar que el cliente, IT y/o Seguridad de la oganizacion elija que se adapta mejor. Creo que te hice leer menos en esta :D Saludos! _____ De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Damián Herrera Enviado el: Miércoles, 12 de Diciembre de 2007 06:03 p.m. Para: [email protected] Asunto: [puntonet] Current User 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. [PAA] Decime cual no queda clara, y trato de explicarme mejor 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. [PAA] No te ahorras tareas administrativas, lo que propongo lo administras con grupos y solo tenes que agregar el usuario al grupo correspondiente. 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. [PAA] Mira Damian, lo que haces me parece bueno de tu parte, otro programador (en general) ni se hubiera preocupado por los recursos del servidor, pero no es bueno que nadie deje sin recursos el servidor en horario productivo, te trae problemas a nivel IT de la empresa ... pero es para otro thread. Te digo que con la experiencia que tengo con bases de datos, que en algunos troubleshootings es imprescindible agarrar al usuario que ejecuto la mala consulta ... pero tambien se que se puede salvar esto con un buen logging de la aplicacion. "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. [PAA] Si, si aislas procesos y los haces correr con usuarios diferentes evitas ese problema. Pero es valido en un entorno con un servidor con pocos websites ... si tenes un servidor con varios websites, ya no lo podes hacer. En resumen, ambas opciones son validas en ciertas circunstancias. No quiero escribir mucho :) [PAA] Me too 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
