Clase xv
•Descargar como PPT, PDF•
0 recomendaciones•422 vistas
El documento presenta una agenda sobre seguridad en ASP.NET, incluyendo políticas de seguridad, seguridad de código, características de seguridad de ASP.NET 2.0, membresía, modelo de proveedores, y controles de login. Explica conceptos como evidencia, políticas de seguridad, demandas y afirmaciones de permisos, y cómo utilizar controles como <asp:login> y <asp:createuserwizard>.
![Clase XV
•[nombre instructor]
•[fecha]](https://image.slidesharecdn.com/clasexv-130115120900-phpapp01/85/clase-xv-1-320.jpg)
Recomendados
Más contenido relacionado
Similar a Clase xv
Similar a Clase xv (20)
Más de Roberto Moreno Doñoro
Más de Roberto Moreno Doñoro (20)
Clase xv
- 1. Clase XV •[nombre instructor] •[fecha]
- 2. A genda Seguridad Políticas Seguridad de código Seguridad en ASP.NET Nuevas Características de Seguridad de ASP.NET 2.0 Membresía Modelo de Proveedores Controles de Login
- 3. A genda Seguridad Políticas Seguridad de código Seguridad en ASP.NET Nuevas Características de Seguridad de ASP.NET 2.0 Membresía Modelo de Proveedores Controles de Login
- 4. Políticas Descripción del uso de políticas Seguridad en .NET
- 5. Qué es evidenciar? Evidenciar consiste en la información a cerca de la entidad y origen de un assembly La seguridad del Framework .NET es un sistema que otorga permisos basados en la fuerza de evidencia Formas de evidencia Assembly Strong name Nombre simple de assembly Seguridad en .NET Criptografico hash Code location (URL) Firma Authenticode Zona de origen Fuerte Débil Fuerza relativa
- 6. Qué es Políticas de Seguridad? Políticas de seguridad de código de acceso controlan los permisos del código para acceder a los recursos La cantidad de acceso esta basado en la identidad del código y el origen La identidad del código y el origen es establecido por la evidencia Una política de seguridad hace juego con un tipo específico de evidencia para un conjunto de permisos Nothing Execution Seguridad en .NET Internet LocalIntranet Everything FullTrust Custom-defined
- 7. Qué es nivel de Políticas de seguridad? Políticas que pueden ser aplicadas a diferentes niveles para controlar acceso a recursos : •Enterprise •Machine •User •Application domain
- 8. Qué es una Demanda de Permisos? 1. Un assembly pide acceso a un método en un assembly 2. El assembly pasa la petición a un assembly del .NET Framework SomeAssembly 3. El sistema de seguridad demanda Grant: Execute permisos arriba de la pila 4. El sistema de seguridad concede el Call to WriteFile acceso o lanza una excepción YourAssembly Grant: ReadFile Seguridad en .NET Call to WriteFile Permission Demand Security system .NET Framework Assembly Security exception Grant access? Grant: ReadFile Access denied
- 9. Qué es afirmación de Permisos? El método Assert reduce el alcance de la demanda de permisos SomeAssembly Usa esto para asociar una aplicación .NET Grant: Execute Framework con código no administrado Call to NUMBER_Of_PROCESSORS Cuidado: El uso de Assert puede crear una FinanceCalculator vulnerabilidad en la Assert: Read system variable: seguridad NUMBER_OF_PROCESSORS Seguridad en .NET Call to NUMBER_Of_PROCESSORS Permission Demand Security system .NET Framework Assembly Grant: read the system variable: NUMBER_OF_PROCESSORS Grant access? Access granted
- 10. Otros Tipos de Chequeo de seguridad Para realizar esta acción: Use este método: Prevenir y permitir al código de Deny recibir permisos PermitOnly RevertAssert Desactivar llamadas dentro de la RevertDeny pila RevertPermitOnly RevertAll Seguridad en .NET Comparar dos permisos en la IsSubsetOf misma clase Unión Combinar e intersecar permisos Intersect
- 11. Cómo se demanda un permiso imperativo? Un puesto de demanda a un requerimiento de permiso específico de un llamador Para demandar un permiso imperativo: 1. Crear una nueva instancia del objeto permiso 2. Poner las propiedades sobre el objeto permiso Llamar al método de demanda de objeto en el Seguridad en .NET 3. bloque
- 12. Como se “Sostiene” (Asser t) un permiso imperativo Para sostener un permiso imperativo: 1. Crear una instancia del objeto permission 2. Llamar al método Assert sobre éste
- 13. Cómo usar Permisos Declarativos? Usar atributos para poner permisos declarativos Assert Demand Deny Permit Evitar añadir atributos de Demand y atributos Seguridad en .NET de Assert para el mismo método
- 14. Qué es un Link Demand? Un link demand especifica que el conjunto de permisos que directamente llama deben tener para llamar a su código Un link demand es chequeado durante la compilación JIT del llamador Una excepción resulta si el llamador no tiene los suficientes permisos Seguridad en .NET Es usado especialmente un link demand que requiere permisos de identidad Permite que cree un assembly privado que pueda ser llamado por un assembly que tenga la misma publicación
- 15. Qué es herencia de Demanda? Una herencia de demanda pude ser puesta en un una clase o método Una herencia de demanda requiere que A este nivel: su código tenga permisos específicos para: Class Heredar de la clase Seguridad en .NET Method Sobreescribir el método
- 16. Qué es la petición de permisos? La petición de permisos de Assembly son examinados en tiempo de carga por el .NET Framework Tipos de petición de permisos de Assembly Permisos Mínimos (RequestMinimum) El conjunto mínimo de permisos que el código necesita para correr Permisos Opcionales (RequestOptional) Seguridad en .NET Permisos que el código puede usar pero que puede correr efectivamente son ellos Permisos Rechazados (RequestRefused) Permisos que el código nunca concederá, incluso si la política de seguridad permite concederlos
- 17. Laboratorio •Seguridad de acceso del código Seguridad en .NET
- 18. Validando Logins if (Membership.ValidateUser (UserName.Text, Password.Text)) RedirectFromLoginPage (UserName.Text, RememberMe.Checked); Seguridad en .NET
- 19. Proveedores Nuevo modelo para almacenar y manejar estados Los almacenamientos se hacen adaptables a diferentes medios Usados por muchos servicios ASP.NET claves Servicio de Membresía Servicio de Administración de Roles y más Seguridad en .NET Los proveedores preconstruidos hacen que los estados de almacenamiento ASP.NET sean flexibles
- 20. El modelo de Proveedores Controles Otros controles Login LoginStatus LoginView Otros controles Login LoginStatus LoginView de Login de Login APIs de Membresia Membership Membership MembershipUser MembershipUser Proveedores de Membresía AccessMembershipProvider AccessMembershipProvider SqlMembershipProvider SqlMembershipProvider Otros proveedores Otros proveedores Seguridad en .NET Data de Membresía Otros Access SQL Server almacenamientos de datos
- 21. Demo •Configurando un Membership Provider Seguridad en .NET
- 22. Demo •Configurando Roles Management Seguridad en .NET
- 23. Login Controls Controles de Servidor No escritura de código, e.g. Login UI Integrado con las características de Seguridad <asp:login /> <asp:loginname /> <asp:loginstatus /> Seguridad en .NET <asp:loginview /> <asp:passwordrecovery /> <asp:createuserwizard /> <asp:changepassword />
- 24. <asp:CreateUserWizard /> Control Paso a Paso para crear un usuario : Podemos agregar pasos (e.g. address) Podemos modificar la plantilla de los pasos existentes Integración a características de seguridad: Integración con Membresía (Membership) NOTA: Puede crear un acceso a BD si el default Seguridad en .NET membership es cambiado. Tips Soporte para fácil reorganización de pasos Hereda de Wizard
- 25. <asp:Login /> IU Para Iniciar Sesión : Soporte para Auto Formato Tranformación a plantilla Integración: Forms Authentication para validad usuario Integración conMembership Seguridad en .NET Propiedades de presentación Configurable Presentación, e.g. back color, fore color Behavior, e.g. redireccionar a urls
- 26. <asp:LoginName /> Presenta el nombre del usuario Actual String con Formato, e.g. ‘Welcome, {0}!” Otras Presentaciones User.Identity.Name <asp:LoginStatus /> Presenta el Estado del Usuario Seguridad en .NET No autenticado: ‘Login’ autenticado: ‘Logout’ Basado en imagen o texto
- 27. <asp:LoginView /> La presentación varía por: Anonymous Usuario Autenticados Role Membership – Segmentos de página por rol Plantillas y Roles <loggedintemplate /> Seguridad en .NET <anonymoustemplate /> <rolegroups />
- 28. <asp:ChangePassword /> IU Para cambiar Password: Convertir a Plantilla Integración: Integración con Membership Modelo de presentación dual – uno para usuarios autenticados y otro para usuarios no autenticados Seguridad en .NET Propiedades de presentación configurables Presentación, e.g. back color, fore color
- 29. <asp:PasswordRecover y /> Recuperar Password Soporta autoformato Conversión a Plantilla Integración: Usa el proveedor de Membresía por fedecto Reglas de recuperación de Membership Seguridad en .NET Propiedades de presentación configurable Presentación, e.g. back color, fore color Configuración, e.g. redireccionar a urls
- 30. Laboratorio •Seguridad en ASP.NET 2.0
- 31. Recursos Dirección de guía de Seguridad para ASP.NET 2.0: http://msdn.microsoft.com/library/default.asp? url=/library/en-us/dnpag2/html/PAGPractices0001.asp Laboratorios de MSDN: http://lab.msdn.microsoft.com/ Más Recursos ASP.NET http://beta.asp.net Recursos y Noticias: www.programar.net www.willydev.net www.developersec.net
- 32. Exámen Recuperatorio de exámenes
Notas del editor
- El Microsoft .NET Framework se basa en el siguiente modelo de seguridad: Security policy levels: Nivel Enterprise, Nivel Equipo, Nivel Usuario, Aplicaciones de dominio. Una estructura de código de grupos. Un conjunto de permisos asociados a los códigos de grupos. Una evidencia, que provee información acerca de la identidad del código. Application domain host, que provee información del código al CLR. Cada nivel de política de seguridad tiene su propia estructura jerárquica de code groups que provee de un marco de trabajo para establecer y configurar las políticas de seguridad. Code groups mantiene información sobre el conjunto de permisos que son permitidos. El runtime usa esta información provista por un host confiable para determinar cuales code groups pertenecen al código, y cuales son los permisos permitidos.
- Microsoft .NET: Qué es evidenciar? Evidencia es la información que el Common Language Runtime utiliza para tomar decisiones basándose en la directiva de seguridad. La evidencia indica al motor de tiempo de ejecución que el código tiene una característica concreta. Entre los tipos de evidencia normales están las firmas digitales y la ubicación del origen del código, pero la evidencia puede tener también un diseño personalizado que represente otra información de importancia para la aplicación. Tanto los ensamblados como los dominios de aplicación reciben las concesiones de permisos según la evidencia. En la tabla siguiente se muestran los tipos normales de evidencia que puede presentar un host al motor de tiempo de ejecución. Evidencia Descripción Directorio de la aplicación El directorio de instalación de la aplicación. Hash Valor hash criptográfico, como SHA1. Editor Firma del editor de software, es decir, el autor de la firma Authenticode del código. Sitio Sitio de origen, por ejemplo, http://www.microsoft.com. Nombre seguro El nombre seguro criptográfico del ensamblado Dirección URL Dirección URL de origen. Zona Zona de origen, por ejemplo la zona de Internet. Además de los tipos de evidencia de la tabla, también se puede presentar evidencia definida por el sistema o la aplicación, al motor de tiempo de ejecución. Los hosts de dominios de aplicación de confianza pueden presentar evidencia sobre un ensamblado o un dominio de aplicación al motor de tiempo de ejecución. El motor de tiempo de ejecución utiliza esta información para evaluar las directivas de empresa, equipo y usuario (más una directiva de dominio de aplicación para los ensamblados, si la ha establecido el host del dominio de aplicación de confianza) y devolver el conjunto de permisos que se va a otorgar al ensamblado o al dominio de aplicación. Si un host de dominio de aplicación de confianza no tiene permiso para proporcionar evidencia, el ensamblado o el dominio de aplicación reciben los permisos otorgados al host. El motor de tiempo de ejecución recibe evidencia sobre los ensamblados de los hosts de dominios de aplicación de confianza o directamente del cargador. Alguna evidencia, como el lugar de origen del código, procede normalmente del host del dominio de aplicación de confianza porque sólo el host conoce esta información. Los hosts de dominios de aplicación de confianza pueden anular la evidencia proporcionada por el cargador y proporcionar la suya propia. Otra evidencia, como la firma digital de un ensamblado, es inherente al código y puede proceder del cargador o de un host de dominio de aplicación de confianza. Normalmente, el motor de tiempo de ejecución valida la firma digital de cada ensamblado cuando se carga el código. Si la firma digital es válida, el host de dominio de aplicación de confianza pasa la información de firma como evidencia al mecanismo de directiva del motor de tiempo de ejecución. Además, un ensamblado o un host de dominio de aplicación de confianza pueden proporcionar evidencia personalizada como un recurso que forma parte del ensamblado. Los administradores y los programadores pueden definir evidencia personalizada y extender la directiva de seguridad para que la reconozca y la utilice. El mecanismo de directiva del motor de tiempo de ejecución utiliza la evidencia del host de dominio de aplicación de confianza y del ensamblado para determinar la pertenencia de un fragmento de código a un grupo de código.
- Qué es políticas de seguridad? Un Named Permission set es un conjunto de permisos que el administrador puede asociar con un code group. Un Named Permission Set consiste de al menos un permiso y un nombre y descripción para el conjunto de permisos. Un administrador puede usar un Named Permission Set para establecer o modificar las políticas de seguridad para el code groups. Mas de un code groups puede estar asociado con el mismo Named Permission Set. La siguiente tabla muestra los nombres de los permisos incorporados provistos por CLR: Permission set Descripción Nothing Sin permisos (no puede correr el código) Execution Puede ejecutar el código pero no tiene permisos para usar recursos protegidos Internet Conjunto de permisos de directiva predeterminado, adecuado para contenido de origen desconocido. LocalInternet Conjunto de permisos de directiva predeterminado establecido en una empresa. Everything Todos los permisos estándar (integrados) excepto el permiso de omitir la comprobación. FullTrust Acceso completo a todos los recursos. No se puede modificar ninguno de los conjuntos de permisos con nombre integrados. Sin embargo, pueden copiarse y modificar la copia mediante el complemento Microsoft Management Console (MMC) de la herramienta Configuración de .NET Framework. Los administradores pueden definir conjuntos de permisos con nombres personalizados siempre y cuando tengan nombres distintos a los de los conjuntos de permisos integrados. Los conjuntos de permisos con nombre no pueden contener permisos de identidad porque los permisos de identidad derivan directamente de la evidencia y, por lo tanto, no son un producto de evaluación de directiva normal.
- Qué es nivel de políticas de seguridad? El Microsoft .NET Framework proporciona cuatro niveles de directiva de seguridad para calcular la concesión de permisos a un ensamblado o dominio de aplicación. Cada nivel contiene su propia jerarquía de grupos de código y conjuntos de permiso. El motor de tiempo de ejecución busca el punto de intersección de los conjuntos de permisos otorgados a un ensamblado de cada nivel al calcular el conjunto de permisos permitido . La concesión resultante es la suma de los permisos concedidos por todos los niveles participantes en una concesión de directiva. En la tabla siguiente se describen los cuatro niveles de directiva de seguridad proporcionados por la seguridad de .NET Framework. Tipo de directiva Especificada por Se aplica a Directiva de empresa Administrador Todo el código administrado de la empresa, donde se distribuye un archivo de configuración de empresa. Directiva de equipo Administrador Todo el código administrado del equipo. Directiva de usuario Administrador o usuario El código de todos los procesos asociados al usuario actual del sistema operativo cuando se inicie Common Language Runtime. Directiva de dominio de aplicación Código del host del dominio de aplicación Código administrado del dominio de aplicación del host. Los niveles de directiva están en una jerarquía, con la directiva de empresa en la parte superior, seguida por la directiva de equipo y la directiva de dominio de aplicación en la parte inferior. El motor de tiempo de ejecución se inicia en la parte superior de la jerarquía y se desplaza hacia abajo al calcular las concesiones de permisos. Los niveles de directiva inferiores no pueden aumentar los permisos concedidos en los niveles superiores, pero pueden reducir los permisos. De manera predeterminada, las directivas de usuario y dominio de aplicación son menos restrictivas que las directivas de equipo y empresa. La mayor parte de la directiva predeterminada se encuentra en el nivel de equipo. Para obtener más información sobre la configuración de seguridad predeterminada, vea Directiva de seguridad predeterminada . Al otorgar permisos a los ensamblados, el motor de tiempo de ejecución tiene en cuenta los requisitos de todas las directivas existentes (empresa, equipo, usuario y dominio de aplicación), junto con los permisos solicitados por el ensamblado. Al otorgar permisos a los dominios de aplicación, el motor de tiempo de ejecución utiliza las directivas de empresa, equipo y usuario.
- Qué es una demanda de permisos? Luego de que un assembly recibe un conjunto de permisos, el .NET Framework refuerza esos permisos. El refuerzo de permisos previene al código de acceder a recursos para los cuales no tiene permisos de acceso. Entender cómo funciona el motor de seguridad del .NET Framework es esencial para realizar un control programático sobre el proceso.
- Qué es afirmación de permisos? Afirmar un permiso modifica la forma en la que el .NET Framework realiza la verificación de seguridad. El método Assert: Este método permite a su código y al código que este llame, realizar acciones para las cuales su código tiene permisos pero que el código al que llamó no. Esto garantiza el poder utilizar otro código para realizar una operación para la cual el código invocante tiene permisos, pero el código invocado no puede realizarla por sí mismo. Si su código llama a Assert por un permiso en particular, cuando su código, o un código invocado por este, demanda ese permiso, se verifica si posee permisos para realizar la acción. Si usted trata de realizar un Assert de un permiso para el cual su código no está habilitado, se genera una SecurityException.
- Otros tipos de chequeo de seguridad Para prevenir que el código invocado, directa o indirectamente, reciba un permiso específico, usted puede usar el método Deny. Cuando el código invoca al método Deny por un permiso específico, toda demanda por ese permiso falla. Tales llamadas fallarán aunque el código posea esos permisos. La excepción a esta regla es cuando el invocador utiliza el método Assert en el código donde usa el método Deny. En este caso el Assert sobrescribe cualquier efecto del método Deny y el permiso es otorgado. Para permitir que el código invocado reciba un permiso específico, usted puede usar el método PermitOnly. Al igual que Deny, PermitOnly puede ser sobrescrito por Assert. La invocación de los métodos RevertAssert, RevertDeny y RevertPermitOnly, desactiva la llamada a Assert, Deny y PermitOnly respectivamente. La llamada al método RevertAll, desactiva cualquier llamada a Assert, Deny y PermitOnly. El método IsSubsetOf es usado para comparar dos permisos en la misma clase. Por ejemplo, si existe un FileIOPermission A que representa acceso de lectura a la carpeta C:\\TEMP, y un FileIOPermission B, que representa acceso de lectura a C:\\TEMP\\temp.txt, la llamada a B.IsSubsetOf(A) retorna verdadero. Para realizar la unión e intersección de dos permisos en la misma clase, use los métodos Union e Intersect, respectivamente. Por ejemplo, si existe un EnvironmentPermission A, representando acceso de lectura a la variable de ambiente TEMP y SystemRoot, y EnvironmentPermission B, representando acceso de lectura a las variables de ambiente USERNAME y TEMP, la unión de A y B es un objeto EnvironmentPermission con acceso lectura a TEMP, SystemRoot, y USERNAME. La invocación de Demand en este objeto, sólo procederá con éxito si el código posee permisos otorgados sobre las tres variables de ambiente.
- Cómo se demanda un permiso imperativo? Para determinar cuándo todos sus invocadores tienen otorgado determinada permiso, usted puede demandar el permiso de forma imperativa. Por ejemplo: El siguiente código demanda a un objeto FileIOPermission que representa derechos de lectura en el archivo c:\\testfile.txt FileIOPermission filePerm = new FileIOPermission(FileIOPermissionAccess.Read, "C:\\\\testfile.txt"); try { filePerm.Demand(); // si la demanda se cumple, el código continúa su ejecución aquí } catch (SecurityException se) { // si la demanda falla, el código continúa su ejecución aquí }
- Cómo se sostiene “Assert” un permiso imperativo? El siguiente código crea un objeto EnvironmentPermission que representa el permiso de lectura de la variable de ambiente NUMBER_OF_PROCESSORS , y entonces llama al método Assert. EnvironmentPermission envPerm = new EnvironmentPermission( EnvironmentPermissionAccess.Read, "NUMBER_OF_PROCESSORS"); envPerm.Assert();
- Cómo usar permisos declarativos? Usted puede insertar atributos de seguridad en sus clases o métodos para realizar el assert, demand, deny o permit only de ciertos permisos. Usted puede agregar más de un atributo en cada clase o método. Todos los permisos predefinidos en el .NET Framework, tienen su atributo correspondiente. La información de seguridad declarada mediante atributos de seguridad, es almacenada en los meta datos. Esta información es accedida por el sistema en tiempo de ejecución. Los atributos de seguridad son usados sólo para la seguridad declarativa. [Permission(SecurityAction, PublicProp1 = Value1…)] Ejemplo de un atributo demand: En el siguiente ejemplo, el atributo FileIOPermissionAttribute causa una demanda de lectura sobre C:\\TEMP cada vez que el método MyClass es invocado. Si la demanda falla, el método fallará con una SecurityException. Adicionalmente, el atributo EnvironmentPermissionAttribute realiza una demanda sobre la variable de ambiente USERNAME antes de que MyMethod pueda ser invocado satisfactoriamente. [FileIOPermission(SecurityAction.Demand, Read = "C:\\\\TEMP")] public class MyNewClass { … [EnvironmentPermission(SecurityAction.Demand, Read = "USERNAME")] public void MyMethod() { … } } Intente eliminar la práctica de utilizar un atributo para realizar la demanda de un permiso, y otro atributo para el assert del mismo permiso. Esta práctica puede derivar en resultados impredecibles debido a la secuencia en la cual los permisos son evaluados por el sistema de seguridad.
- Qué es un link demand? Un link demand indica los permisos que sólo el caller directo debe tener para invocar al código. El siguiente ejemplo, el caller MyClass debe poseer el strong name usado en el atributo StrongNameIdentityPermissionAttribute. [StrongNameIdentityPermission( SecurityAction.LinkDemand, PublicKey = "12789ADE…", Name = "MyApp", Version = "1.0.0.0")] public class MyNewClass { // MyNewClass sólo puede ser invocada por un assembly con el strong name // indicado en el atributo }
- Qué es una herencia de demanda? Usted puede incorporar herencia de demanda a nivel de clase para asegurarse que sólo el código con los permisos indicados pueda heredar de esta clase. La herencia de demanda indicada en un método, indica que el código debe poseer los permisos indicados para sobrescribir el método. El siguiente ejemplo usa la herencia de demanda para requerir que cualquier clase que herede de esta clase, deba poseer el permiso personalizado CustomPermission. Este permiso es un permiso hipotético y no existe en el .NET Framework. Esta demanda se realiza pasando el CustomPermission a la enumeración SecurityAction.InheritanceDemand. [CustomPermission(SecurityAction.InheritanceDemand)] public class MyNewClass { public MyNewClass() { } public virtual string ReadData() { // acceso a un recurso personalizado. } }
- Qué es la petición de permisos? Usted puede realizar el pedido de permisos agregando atributos a nivel de assembly en su código. Puede realizar varios pedidos utilizando varios atributos. Estos atributos varían dependiendo de los permisos pedidos. El siguiente ejemplo realiza una petición de permisos mínimos para invocar código no manejado: [assembly:SecurityPermission( SecurityAction.RequestMinimum, UnmanagedCode = true)]
- Notas para el instructor : El tiempo estimado para realizar el lab es de 1 hora. Lea el documento adjunto, para guiar a los alumnos en la resolución del laboratorio.
- Validar las credenciales de conexión no requiere la escritura de código para comprobar las credenciales contra alguna base de datos, Active Directory, o algún otro tipo de repositorio de credenciales. En ASP.NET 2.0, el servicio de membresías reduce la validación de nombres y de contraseñas de usuarios a una llamada de un único método. Otros métodos de la clase Membership pueden ser utilizados para realizar tareas adicionales tales como generación de nuevas contraseñas y enumeración de usuarios registrados
- Utilizar una base de datos de Access resulta adecuado cuando se está desarrollando una aplicación Web o creando una aplicación destinada a un grupo reducido de personas. Sin embargo, si se precisa crear una aplicación más robusta, resultará recomendable almacenar los nombres de usuario y las contraseñas en una base de datos escalable, por ejemplo, una base de datos de Microsoft SQL Server. Para almacenar la información de pertenencia a grupo en una base de datos de Microsoft SQL Server en lugar de en la predeterminada de Microsoft Access, será necesario modificar el proveedor de pertenencia a grupo predeterminado de la aplicación. El siguiente archivo Web.Config de la aplicación permite establecer AspNetSqlProvider como el proveedor de pertenencia a grupo predeterminado: <configuration> <system.web> <membership defaultProvider="AspNetSqlProvider" /> </system.web> </configuration Si no se desea actualizar el archivo Web.Config de la aplicación de forma manual, se pueden cambiar los proveedores con la herramienta de administración de sitios Web (que se analiza en la sección siguiente) o con el complemento de ASP.NET Microsoft Management Console (MMC) para los Servicios de Internet Information Server (IIS). Ambas herramientas ofrecen una interfaz descriptiva para la especificación del proveedor de pertenencia a grupo. A diferencia del proveedor de Microsoft Access, antes de utilizar el proveedor de SQL será preciso crear las tablas de base de datos y los procedimientos almacenados necesarios. Los objetos de la base de datos de SQL Server se pueden crear automáticamente ejecutando la herramienta aspnet_regsql desde la línea de comandos (consulte la figura 1). Esta herramienta crea de forma predeterminada una nueva base de datos llamada aspnetdb en la instancia local de SQL Server.
- La novedad más significativa que ofrece el marco ASP.NET 2.0 es básicamente que la seguridad funciona. Se puede comenzar a registrar y autenticar a los usuarios comparando la información de la base de datos inmediatamente después de habilitar la autenticación por formularios, sin necesidad de generar tablas de base de datos ni de escribir ningún código. Esto es posible porque el marco ASP.NET 2.0 utiliza el modelo de proveedores (en inglés) para la seguridad. El modelo de proveedores, que se utiliza ampliamente en el marco ASP.NET 2.0, ofrece un método estándar para conectar los componentes, que son los encargados de implementar los distintos servicios de la aplicación. El marco ASP.NET 2.0 emplea dos tipos de proveedores para la seguridad: el proveedor de pertenencia a grupo y el proveedor de función. El proveedor de pertenencia a grupo se utiliza para almacenar nombres de usuario y contraseñas, mientras que el proveedor de función se emplea para almacenar funciones de usuario. El proveedor de pertenencia a grupo predeterminado es AccessMembershipProvider . Almacena los nombres de usuario y las contraseñas en una base de datos de Microsoft Access. Esta base de datos se crea automáticamente en la carpeta Data de la aplicación. (Si la base de datos de Access se eliminara accidentalmente, se volvería a crear automáticamente la próxima vez que se intentara la conexión a la base de datos.) Siempre que se cree una aplicación Web, el proveedor de Access generará automáticamente todo lo necesario para comenzar a autenticar a los usuarios. El marco ASP.NET 2.0 se ofrece con dos proveedores de pertenencia a grupo: el predeterminado AccessMembershipProvider y un proveedor SqlMembershipProvider . Si se desea almacenar información de pertenencia a grupo en una base de datos de Microsoft SQL Server, se puede configurar la aplicación para que utilice SqlMembershipProvider sin necesidad de volver a escribir el código de la aplicación. (Los pasos a seguir para habilitar SqlMembershipProvider se describen en la siguiente sección.) También se puede crear un proveedor de pertenencia a grupo personalizado. Por ejemplo, se podría desear almacenar la información de pertenencia a grupo en un archivo XML, una base de datos de FoxPro o de Oracle, o incluso implementar un proveedor de pertenencia a grupo que recuperara la información mediante un servicio Web. Si la intención es crear un proveedor de pertenencia a grupo propio, se deberán implementar todos los métodos y propiedades de la clase MembershipProvider abstracta. (Un proveedor de pertenencia a grupo no es más que una instancia de la clase base MembershipProvider .)
- En ASP.NET 1.x, para poder editar las configuraciones había que modificar un archivo de configuración XML. En 2.0, hay dos nuevas herramientas, el componente ASP.NET dentro de las consolas de administración (MMC) y el Web Site Administration Tools , que lo habilita a configurar la mayoría de las opciones. Ambas herramientas representan un importante crecimiento para el uso y administración de sitios Web mantenidos por ASP.NET. ASP.NET 2.0 posee una mayor cantidad de herramientas que su antecesor. Gracias a las nuevas herramientas de monitoreo, unas pocas líneas en el Web.Config pueden ayudar a configurar a que nuestra aplicación escriba eventos dentro del registro de Windows cuando una validación falla, enviar un e-mail cuando un error de protección general sucede, etc. Además, usted puede extender las funcionalidades de los monitores de sistemas generando sus propios eventos de Web.
- Demostración 1: Configurando un Membership Provider En esta demostración, el instructor configurará un membership provider utilizando el archivo web.config . A continuación se detallan los pasos a seguir para llevar a cabo la demostración: Abrir el proyecto demo En el menú File , haga click en Open Web Site . En el cuadro de diálogo Open Web File , navegue hasta ubicar el proyecto \\\\ModSegAspNet\\[Lenguaje]\\Demo1 y haga click en Open . Configurar el Membership provider En el Solution Explorer , haga doble click en el web.config . El siguiente código muestra el elemento membership <defaultProvider> dentro del elemento system.web <membership defaultProvider="NWMembership"></membership> Escriba el siguiente código para agregar el elemento Providers dentro de la sección membership. <providers></providers> Escriba el siguiente código para agregar un nuevo provider en el elemento providers , usando el elemento add . <providers> <add connectionStringName="NWindConn" requiresUniqueEmail="false" requiresQuestionAndAnswer="false" name="NWMembership" type="System.Web.Security.SqlMembershipProvider" /> </providers> En el menú File , haga click en Save web.config Ver el resultado del código Haga click derecho en Source view del archivo login.aspx, y luego click en View in Browser . Haga click en el link I’m a new user . Escriba su nombre y password en los cuadros de texto User ID y Password y luego haga click en Add . Nota: El password debe poseer al menos ocho caracteres y tener al menos un caracter de cada uno de los siguientes items: Una letra del alfabeto en minúscula. Una letra del alfabeto en mayúscula. Un número. Un caracter especial. Escriba su nombre en el cuadro User ID y el mismo password en el cuadro Password , luego haga click en Log In para ver el resultado.
- Ver documentación adjunta Demostración 2: Configurando Roles Management En esta demostración, el instructor configurará el roles management agregando elementos roleManager y providers en el archivo web.config . A continuación se detallan los pasos a seguir para llevar a cabo la demostración: Abrir el proyecto demo En el menú File , haga click en Open Web Site . En la ventana Open Web Site , navegue hasta ubicar el proyecto \\\\ModSegAspNet\\[Lenguaje]\\Demo2 y haga click en Open . Configurar el role management Haga doble click en el archivo web.config en el Solution Explorer para abrir el archivo. Escriba el siguiente código para agregar un roleManager dentro del elemento system.web en el archivo web.config . <roleManager enabled="true" defaultProvider="NWMembership"></roleManager> Escriba el siguiente código para agregar el elemento Providers dentro de roleManager . <providers> </providers> Escriba el siguiente código para insertar un elemento add dentro del elemento Providers . <providers><add name="NWMembership" type="System.Web.Security.SqlRoleProvider" connectionStringName="NWindConn" /></providers> Haga click en File y luego en Save web.config . Preparar la base de datos para la información de roles Haga click en el menú Website y luego en ASP.NET Configuration para abrir la herramienta ASP.NET Web Site Administration Tool . En la ventana ASP.NET Web Site Administration Tool , haga click en el tab Security para crear o manejar roles. Haga click en el link Create or Manage roles para crear un nuevo rol. En el cuadro de texto New role name , escriba Admin , y luego haga click en Add Role para agregar el nuevo rol. Ver el resultado del código Haga click derecho en Source view del archivo login.aspx, y luego click en View in Browser . Haga click en I’m a new user . Escriba su nombre y password en los cuadros de texto User ID y Password y luego haga click en Add . Nota: El password debe poseer al menos ocho caracteres y tener al menos un caracter de cada uno de los siguientes items: Una letra del alfabeto en minúscula. Una letra del alfabeto en mayúscula. Un número. Un caracter especial. Seleccione Admin o User desde Role:Admin , y luego haga click en Add para elegir la categoría para el rol. Escriba su nombre en el cuadro User ID y el mismo password en el cuadro Password , luego haga click en Log In para ver el resultado.
- Son muchas las formas en las que se puede explorar la interfaz de administración Web. Si se desea crear una aplicación Web con Visual Studio .NET 2005, se puede abrir la herramienta seleccionando ASP.NET Configuration en el menú Website . Si lo que se desea es desarrollar una aplicación Web fuera de Visual Studio .NET, se puede tener acceso a la herramienta directamente solicitando la página especial WebAdmin.axd. Por ejemplo, si la aplicación se encuentra en un directorio virtual llamado MyWebApp en el equipo local, se puede abrir la herramienta de administración de sitios Web para la aplicación especificando la siguiente URL en el explorador de Internet. http://localhost/MyWebApp/WebAdmin.axd También se puede utilizar este último método para obtener acceso a la herramienta para una aplicación ya distribuida. En un segundo plano, la herramienta se compone de una serie de páginas ASP.NET que utilizan los controles Login estándar que se analizarán en la sección siguiente. Estas páginas se ubican en la carpeta inetpub\\wwwroot\\aspnet_webadmin. Si por cualquier motivo los archivos se eliminaran accidentalmente del servidor, se podrían reinstalar automáticamente ejecutando la herramienta aspnet_regiis. Esta última también se puede emplear para controlar el acceso a la herramienta de administración de sitios Web. Por ejemplo, con aspnet_regiis se puede restringir el acceso a ella exclusivamente al servidor local. Uso de los controles Login para crear páginas de seguridad estándar ASP.NET 2.0 contiene una serie de novedosos controles relacionados con la seguridad que se conocen en su conjunto como controles Login . Mediante estos controles Login , se pueden crear páginas estándar de registro, de inicio de sesión y de recuperación de contraseñas sin necesidad de escribir código. También se emplean para mostrar distinta información a los usuarios dependiendo de sus funciones y de su estado de autenticación en ese momento. Por ejemplo, el control LoginView permite definir las distintas plantillas que se muestran a los miembros de las diferentes funciones. Se puede emplear para mostrar una información a los miembros de la función de administrador y otra distinta a los miembros de la función de invitado. En un segundo plano, el control Login aprovecha toda la funcionalidad del modelo de proveedores. Si ha configurado la aplicación para que utilice AccessMembershipProvider , los controles Login realizarán automáticamente una consulta a la base de datos de Microsoft Access para recuperar la información de la pertenencia a grupo. Si se habilita SqlMembershipProvider , los controles utilizarán la base de datos de SQL Server configurada. Antes de utilizar cualquiera de los controles Login , se debe habilitar la autenticación por formularios para la aplicación. Se puede habilitar bien modificando el archivo de configuración Web de la aplicación, bien empleando la herramienta de administración de sitios Web.
- CreateUserWizard permite crear una página estándar de registro de usuarios. Simplemente agregando la siguiente etiqueta a la página, los nuevos usuarios podrán registrarse en el sitio Web. <asp:CreateUserWizard ID="CreateUserWizard1" Runat="server" /> La apariencia exacta de la interfaz generada por CreateUserWizard dependerá de la configuración del proveedor de pertenencia a grupo de la aplicación. Por ejemplo, los cuadros de texto de la pregunta y la respuesta para recuperar la contraseña sólo aparecen cuando el atributo requiresQuestionAndAnswer presenta el valor true. La página de registro que se muestra en la figura 4 se genera cuando se utiliza CreateUserWizard con el proveedor de pertenencia a grupo AspNetAccessProvider predeterminado. Una de las cosas más interesantes que permite hacer el control CreateUserWizard es enviar automáticamente un mensaje de correo electrónico de registro después de que el usuario ha completado todos los pasos del registro. Por ejemplo, se puede enviar al usuario un mensaje de agradecimiento por registrarse en el sitio Web. El mensaje puede contener información como el nombre de usuario y la contraseña del usuario registrado. También se puede configurar el mensaje enviado por medio del control CreateUserWizard mediante la asignación de valores a la propiedad MailDefinition del control. MailDefinition representa una instancia de la clase MailDefinition que contiene todas las propiedades necesarias para definir un mensaje de correo electrónico. Por ejemplo, el control CreateUserWizard enviará el contenido del archivo RegistrationEmail.txt como cuerpo del mensaje de correo electrónico de registro siempre que alguien complete el asistente de registro ( CreateUserWizard emplea el servidor de correo electrónico especificado en la sección de correo < smtpMail > del archivo de configuración Web al enviar mensajes de correo electrónico). <asp:CreateUserWizard ID="CreateUserWizard1" Runat="server"> <MailDefinition BodyFileName="~/RegistrationEmail.txt“ From="YourSite@YourDomain.com“ Subject="Thanks for registering!"> </MailDefinition> </asp:CreateUserWizard> Dentro del archivo RegistrationEmail.txt se pueden utilizar expresiones especiales, como < % UserName % > y < % Password % >, para sustituir el nombre de usuario y la contraseña del nuevo usuario registrado dentro del cuerpo del mensaje de correo electrónico. La funcionalidad de correo electrónico del control CreateUserWizard también puede resultar de utilidad en ejemplos de registro más complicados, por ejemplo, aquellos en los que es preciso validar la dirección de correo electrónico del usuario antes de permitirle el acceso a la aplicación Web. Si se habilita la propiedad AutoGeneratePassword del control CreateUserWizard , el control generará de forma aleatoria una contraseña para el usuario. La funcionalidad de correo electrónico del control CreateUserWizard permite enviar automáticamente al usuario la contraseña aleatoria. Si el usuario posteriormente la utiliza para autenticarse en la aplicación Web, se confirmará que el usuario ha facilitado una dirección de correo electrónico válida.
- Como ya se ha mencionado anteriormente, el control Login permite crear una página estándar de inicio de sesión agregando una simple etiqueta a una página. <asp:Login ID="Login1" Runat="server" /> El control Login genera automáticamente una interfaz de inicio de sesión estándar. En su forma predeterminada, la interfaz no resulta muy atractiva, pero se puede mejorar de forma muy rápida la apariencia del control Login en Visual Studio .NET 2005 haciendo clic con el botón secundario del mouse en el control y seleccionando AutoFormat . Observe cómo se crean cuadros de texto de nombre de usuario y contraseña, una casilla de verificación para recordar al usuario la próxima vez que inicie sesión y un botón para enviar la información. El control Login no sólo ofrece la interfaz, sino que funciona a la perfección. Al enviar el nombre de usuario y la contraseña con Login , el proveedor de pertenencia a grupo valida las credenciales automáticamente. La lista de propiedades asociadas con el control Login es interminable. La gran mayoría de ellas simplemente permite controlar ciertos aspectos de la apariencia de la interfaz de inicio de sesión. Por ejemplo, se pueden utilizar las distintas propiedades FailureText para tener un control sobre el contenido y la apariencia del texto que se muestra cuando se produce un error en el intento de inicio de sesión. Además, se pueden emplear las propiedades CreateUserUrl y PasswordRecoveryUrl para crear vínculos a una página de registro y una página de recuperación de contraseñas. Una de las propiedades más útiles que incluyen los controles Login es la propiedad VisibleWhenLoggedIn , que permite ocultar automáticamente el control Login cuando el usuario ya se ha autenticado. Por ejemplo, puede que se desee incluir el control Login en la parte superior de cada página de la aplicación Web. Con la propiedad VisibleWhenLoggedIn se podrá ocultar de forma automática el control Login tan pronto como el usuario se haya autenticado.
- Los controles LoginName y LoginStatus permiten mostrar información sobre el estado actual de la autenticación de un usuario. Después de que un usuario ha iniciado sesión en la aplicación, el control LoginName muestra su nombre de usuario registrado. Si un usuario no se autentica con la autenticación por formularios, el control LoginName no muestra nada. El control LoginName se puede declarar en una página de la siguiente manera: <asp:LoginName ID="LoginName1" Runat="server" /> LoginStatus , por su parte, permite que el usuario inicie o cierre sesión en la aplicación Web. El control muestra uno de dos vínculos. Si el usuario no se ha autenticado, se muestra un vínculo a la página Login.aspx. Si ya se ha autenticado, se muestra un vínculo que le permite cerrar sesión. El control LoginStatus se declara de esta forma: <asp:LoginStatus ID="LoginStatus1" Runat="server" />
- El último de los controles Login , el control LoginView , permite mostrar contenido distinto dependiendo de la función concreta del usuario. Por ejemplo, muchos sitios Web muestran información distinta en su página principal en función de si el usuario es nuevo o ya está registrado. Los nuevos usuarios pueden ver una descripción general del sitio Web, mientras que los ya registrados pueden ver la información que se ha creado específicamente para ellos. A continuación se muestra cómo se puede utilizar el control LoginView para mostrar contenido distinto a un usuario anónimo y a un usuario autenticado. <asp:LoginView ID="LoginView1" Runat="server"> <LoggedInTemplate> Welcome back <asp:LoginName ID="LoginName1" Runat="server" /> </LoggedInTemplate> <AnonymousTemplate> Welcome to our Web site! If you were a registered user, you could view some really interesting stuff right now! </AnonymousTemplate> </asp:LoginView> El usuario anónimo ve todo el contenido incluido en la plantilla AnonymousTemplate , mientras que el autenticado ve todo el contenido que incluye la plantilla LoggedInTemplate . Si habilita las funciones predeterminadas para la aplicación Web, puede utilizar el control LoginView para mostrar contenido que sólo puedan ver miembros con funciones específicas. Por ejemplo, imagine que utilizó la herramienta de administración de sitios Web para crear una nueva función llamada Administrators. En ese caso, podría utilizar el control LoginView para mostrar contenido que sólo puedan ver los miembros de dicha función, por ejemplo, como se muestra a continuación. <asp:LoginView ID="LoginView1" Runat="server"> <RoleGroups> <asp:RoleGroup Roles="Administrators"> <ContentTemplate> Secret stuff for administrators! </ContentTemplate> </asp:RoleGroup> </RoleGroups> <LoggedInTemplate> Welcome back <asp:LoginName ID="LoginName1" Runat="server" /> </LoggedInTemplate> <AnonymousTemplate> Welcome to our Web site! If you were a registered user, you could view some really interesting stuff right now! </AnonymousTemplate> </asp:LoginView> Los miembros de la función Administrators podrían ver cualquier contenido que incluyera la plantilla < ContentTemplate > asociada con el grupo de funciones de administrador. Un miembro de la función Administrators, sin embargo, no podría ver el contenido declarado en la plantilla LoggedInTemplate o en la plantilla Anonymous . Sólo se puede ver el contenido de una plantilla, incluso cuando se aplica más de una al usuario concreto.
- El control ChangePassword , como se puede suponer, permite a los usuarios cambiar sus contraseñas registradas. El control crea cuadros de texto en los que se puede facilitar la contraseña original y la nueva Al igual que los controles CreateUserWizard y PasswordRecovery , el control ChangePassword incluye una propiedad MailDefinition . Cuando se asignan valores a la propiedad MailDefinition , el control ChangePassword envía automáticamente un mensaje de correo electrónico al usuario cuando se cambia correctamente una contraseña. La etiqueta siguiente declara una instancia del control ChangePassword y define la propiedad MailDefinition . <asp:ChangePassword ID="ChangePassword1" Runat="server"> <MailDefinition BodyFileName="~/ChangePasswordEmail.txt“ From="YourSite@YourDomain.com“ Subject="Your Updated Password"> </MailDefinition> </asp:ChangePassword> La propiedad BodyFileName incluye la ruta a un archivo de texto que contiene el cuerpo del mensaje de correo electrónico que se envía al usuario. Dentro del archivo de texto, se pueden utilizar expresiones especiales como < % UserName % > y < % Password % > para mostrar el nombre de usuario y la contraseña modificada del usuario registrado en el mensaje de correo electrónico.
- El control PasswordRecovery permite que los usuarios de la aplicación Web puedan solicitar un mensaje de correo electrónico de recordatorio de su contraseña. Al igual que el control CreateUserWizard , las propiedades del mensaje de correo electrónico enviado al usuario se definen mediante la propiedad MailDefinition . Por ejemplo, la etiqueta siguiente agrega un control PasswordRecovery a una página que envía un mensaje de correo electrónico desde la cuenta de correo electrónico YourSite@YourDomain.com. <asp:PasswordRecovery ID="PasswordRecovery1" Runat="server"> <MailDefinition From="YourSite@YourDomain.com“ Subject="Password Reminder"> </MailDefinition> </asp:PasswordRecovery> El control PasswordRecovery tiene comportamientos diferentes, dependiendo de la configuración del proveedor de pertenencia a grupo predeterminado. Cuando el atributo enablePasswordRetrieval presenta el valor true y el atributo passwordFormat no tiene el valor Hashed , se envía la contraseña de texto sin cifrar original del usuario en el mensaje de correo electrónico. En el caso de cualquier otra combinación de valores de atributos, la contraseña se restablece en una secuencia de caracteres generada de forma aleatoria que se envía al usuario.