Administración de miembros y funciones de Microsoft ASP.NET 2.0 con IIS, 1 Parte: Información general sobre seguridad y configuración

Noviembre de 2005

Publicado: 30 de Enero de 2006

Peter Kellner
http://peterkellner.net/(en inglés)

Este artículo se aplica a:
Microsoft ASP.NET 2.0
Microsoft Visual Studio 2005
Servicios de Internet Information Server (IIS) de Microsoft

Resumen: éste es el primero de dos artículos en los que Peter Kellner examina la creación de una aplicación para administrar las bases de datos de pertenencia de Microsoft ASP.NET 2.0. En este artículo en concreto se centra en la seguridad de la solución para garantizar que sólo los administradores con los permisos adecuados puedan obtener acceso a los datos. (7 páginas impresas.)

En esta página

Resumen Resumen
Introducción Introducción
Consideraciones relativas a la seguridad Consideraciones relativas a la seguridad
Seguridad basada en funciones en un sitio Web de ASP.NET 2.0 Seguridad basada en funciones en un sitio Web de ASP.NET 2.0
Conclusión Conclusión
Acerca del autor Acerca del autor

Resumen

Éste es el primero de dos artículos en los que se describe el uso y la configuración seguros de una solución de tres niveles para la administración de la pertenencia y las funciones de ASP.NET. En este primer artículo se tratará la configuración, el uso y, lo que es más importante, la seguridad de la solución, y se ofrecerá información general sobre el modo de implementarla en una solución Web típica de Microsoft ASP.NET 2.0. Se tratarán los objetos Membership y Roles, pero no se ahondará en sus estructuras internas. La administración de miembros y funciones no resulta muy distinta a la administración de los datos de un origen de datos simple. En el segundo artículo, en cambio, se describirá en detalle el mecanismo interno de estos controles y objetos, de modo que los desarrolladores puedan crear los suyos propios a través de técnicas similares.

Introducción

ASP.NET 2.0 amplía la autenticación del usuario directamente hasta el dominio de programación de la aplicación. El uso de una referencia de biblioteca de .NET estándar (system.web.security) permite a los desarrolladores incluir en sus aplicaciones autenticación completa con escaso trabajo adicional. Teniendo esto en cuenta, es importante recordar que se necesita un cierto nivel de diligencia para minimizar la posibilidad de poner en peligro la seguridad de la aplicación que se cree durante el uso de la misma.

En este artículo se ofrece información general sobre los distintos mecanismos de seguridad y se muestra una configuración de seguridad de ejemplo que resultan esenciales para crear un entorno seguro para aplicaciones Web. ASP.NET 2.0 proporciona numerosas opciones de configuración diferentes que pueden o no ser necesarias en función de los requisitos de seguridad. A lo largo de este artículo se mencionarán los pros y los contras de estas opciones de configuración.

Consideraciones relativas a la seguridad

Protección del entorno físico

A menudo se afirma que la seguridad de un equipo termina en el interruptor de alimentación de su panel frontal. Independientemente de cuál sea la seguridad del equipo desde el sistema operativo, la protección física es esencial. Es necesario tener claro que cualquiera que tenga acceso físico al equipo siempre puede poner en peligro su integridad de uno u otro modo.

Para obtener más información sobre las prácticas adecuadas recomendadas para garantizar la seguridad del entorno físico de un equipo, consulte este artículo (en inglés) en Microsoft TechNet.

Protección del entorno del dominio

En primer lugar, la configuración de cuentas, contraseñas y privilegios se debe realizar de acuerdo a prácticas adecuadas. Por ejemplo, si un usuario que no dispone de privilegios puede obtener acceso directo a la base de datos que contiene los datos seguros que utiliza la aplicación Web, puede poner en peligro su seguridad.

Para obtener más información sobre cómo garantizar la seguridad del entorno del dominio de un equipo, en los siguientes artículos (en inglés) que se muestran en la página principal de seguridad de Microsoft encontrará recomendaciones y sugerencias que le serán de gran utilidad.

Protección del entorno .NET

El entorno .NET permite establecer la seguridad de acceso al código, lo que significa que se pueden asociar bibliotecas de sistema y aplicación individuales a niveles de confianza diferentes. Este aspecto puede ser muy importante, por ejemplo, en entornos de alojamiento compartido en los que se ejecutan varias aplicaciones Web. Todas las aplicaciones Web con propietarios potencialmente diferentes pueden necesitar aislamiento y protección frente a las demás. Asimismo, sin este aislamiento, cada aplicación Web podría afectar a funciones fundamentales del sistema.

En este artículo, se asumirá que el usuario de ASP.NET (el usuario en nombre del cual se ejecuta IIS) utiliza el nivel más alto de confianza. Éste sería probablemente el caso de una aplicación Web que se ejecutase en un entorno dedicado. Para obtener más información sobre cómo se puede utilizar la seguridad del código para mejorar la seguridad de un servidor Web, consulte el artículo de MSDN Using Code Access Security with ASP.NET (en inglés).

Relación entre ASP.NET e IIS

ASP.NET admite tres proveedores de autenticación cuando funciona con IIS: la autenticación por formularios, que utiliza lógica específica de aplicación; la autenticación de Passport, un servicio de autenticación centralizado de Microsoft; y la autenticación de Windows, que utiliza la autenticación proporcionada directamente a través de IIS. En este artículo se utiliza la autenticación predeterminada para los proyectos de ASP.NET, es decir, la autenticación por formularios. El modo de autenticación se especifica en el archivo web.config. Las opciones de sintaxis disponibles son las siguientes.

<authentication mode = "{Windows|Forms|Passport|None}">
</authentication>

El flujo que se sigue cuando un usuario inicia sesión desde un cliente Web se muestra en el diagrama de flujo que se incluye en este artículo.

Es necesario tener en cuenta que este artículo se escribió en 2001 y el flujo que muestra corresponde a IIS 5.1, no al actual IIS 6.0 o posterior.

Figura 1. Flujo de seguridad entre IIS y ASP.NET

Seguridad basada en funciones en un sitio Web de ASP.NET 2.0

Instalación y configuración iniciales

Archivo web.config: Elementos no modificados de forma frecuente

Ciertos parámetros que repercuten en la ejecución general de una aplicación Web de ASP.NET 2.0 se establecen en el archivo web.config. Entre los parámetros de ejemplo se incluyen una referencia al proveedor (o base de datos) de pertenencia, la eficacia de la contraseña requerida y si es o no necesaria una dirección de correo electrónico para registrarse. A continuación se muestra la sección correspondiente del archivo web.config con valores de ejemplo para una configuración de seguridad minimalista. Para obtener más información, busque el tema correspondiente a la pertenencia en la ayuda de Visual Studio 2005. En ella encontrará datos detallados sobre cada uno de los parámetros de seguridad.

<providers>
 <remove name="AspNetSqlMembershipProvider"/>
 <add name="AspNetSqlMembershipProvider" 
   type="System.Web.Security.SqlMembershipProvider, 
   System.Web, Version=2.0.0.0, Culture=neutral, 
   PublicKeyToken=b03f5f7f11d50a3a" 
   connectionStringName="LocalSqlServer"  
   enablePasswordRetrieval="false" 
   enablePasswordReset="true" 
   requiresQuestionAndAnswer="true" 
   applicationName="/" 
   requiresUniqueEmail="false" 
   minRequiredPasswordLength="1" 
   minRequiredNonalphanumericCharacters="0" 
   passwordFormat="Hashed" 
   maxInvalidPasswordAttempts="5" 
   passwordAttemptWindow="10" 
   passwordStrengthRegularExpression="
   commentTimeout="/>
</providers>

Además de la sección de web.config mostrada anteriormente, el archivo machine.config contiene la cadena de conexión predeterminada de la base de datos asociada a la pertenencia. En web.config se puede configurar una cadena de conexión diferente. Para agregar seguridad adicional, se puede codificar la cadena de conexión y cifrar la contraseña de la base de datos de pertenencia. Se han escrito numerosos artículos acerca de sus ventajas e inconvenientes. En las guías de inicio rápido de Microsoft (en inglés) encontrará ejemplos interesantes sobre cómo utilizar el cifrado en el archivo web.config.

Archivo web.config: Seguridad de las páginas .aspx

A cada una de las páginas Web de una aplicación Web se le puede asignar un nivel de seguridad diferente. Para ello, se especifica la función requerida para obtener acceso a la página. La sintaxis del archivo web.config es muy directa. Por ejemplo, en el siguiente fragmento del archivo web.config se especifica que a la página Web MembershipGrid.aspx sólo podrán obtener acceso aquellos usuarios cuya función sea la de administrador.

<system.web>
  <location path="MembershipGrid.aspx" >
    <system.web>
      <authorization >
      <allow roles="Administrators"/>
      </authorization>
    </system.web>
  </location>
</system.web>

Asimismo, éste sería el archivo web.config si se deseara, por ejemplo, especificar que sólo una función determinada podría obtener acceso a todas las páginas de un subdirectorio. En este caso, sólo un usuario con función de administrador podría obtener acceso a todos los archivos contenidos en la ruta ~/AdminDir.

<system.web>
  <location path="AdminDir" >
    <system.web>
      <authorization >
      <allow roles="Administrators"/>
      </authorization>
    </system.web>
  </location>
</system.web>

Archivo web.config: Mecanismo interno de seguridad de las páginas .aspx

A menudo es necesario proporcionar una mayor seguridad que la descrita anteriormente. Es decir, puede que sea preciso proteger un control como un botón o una página aspx. Para ello, se debe cambiar mediante programación el atributo asociado al control afectado. Por ejemplo, si es necesario ocultar un botón de eliminación según la función del usuario, se deberán realizar dos acciones: en primer lugar, se debe agregar un método ShowButtonBasedOnRole a la clase de código subyacente de la página Web. Con esto se debería devolver true si el usuario tiene autorización para la función solicitada, y false si el usuario no se incluye en ella.

protected bool ShowButtonBasedOnRole(string RoleOfInterest)
{
return User.IsInRole(RoleOfInterest);   
}

A continuación, en la página aspx real, se debe establecer el atributo de visibilidad del botón en función del método de código subyacente ShowButtonBasedOnRole. El aspecto de la declaración real del botón es el siguiente.

<asp:Button
 ID="Button1" runat="server" Text="Button"
 Visible='<%# (bool) ShowDeleteRowBasedOnRole("administrator") %>'> />

Si un botón se basara en cualquiera de las distintas funciones establecidas, se podría cambiar el parámetro pasado a una cadena y se comprobarían todas las funciones antes de devolver una respuesta de si se asigna o no el usuario a una de ellas.

Uso de la página aspx de administración de miembros y funciones

Para utilizar la página aspx incluida en este proyecto (Membership.aspx) es necesario realizar varias acciones. En primer lugar, las dos clases de datos de los archivos del proyecto del artículo se deben copiar e incluir en el directorio del proyecto de destino app_code. Estos dos archivos son MembershipDataObject.cs y RoleDataObject.cs. A continuación, el archivo aspx Membership.aspx y su página de código subyacente Membership.aspx.cs se deben mover al proyecto actual.

Es muy importante proteger esta página del acceso de usuarios que no tengan asignada la función de administrador. De lo contrario, cualquier usuario podría modificar la información de inicio de sesión de otro. Para ello, es preciso asegurarse de que la página Membership.aspx está protegida en el archivo web.config. A continuación se muestran varias líneas de ejemplo de un archivo web.config con las que se puede llevar a cabo esta acción.

<system.web>
  <location path="Membership.aspx" >
    <system.web>
      <authorization >
      <allow roles="Administrators"/>
      </authorization>
    </system.web>
  </location>
</system.web>

Una vez protegida la página, es imposible que un usuario que no tenga asignada la función de administrador en la cuenta de usuario actual pueda obtener acceso a ella.

El mejor modo de realizar esta acción es ejecutar el código siguiente una vez y, a continuación, quitar el código del servidor Web. Podría incluirse, por ejemplo, en el evento de carga de página de una página Web de ASP.NET. Tras llamar a la página, ésta se debe eliminar del servidor. Llegados a este punto, sólo podrán obtener acceso a la página de administración de pertenencia aquellos usuarios que inicien sesión como administrador con la correspondiente contraseña.

Roles.CreateRole("Administrator");
Roles.CreateRole("User");
Roles.CreateRole("Guest");
Membership.CreateUser("admin", "some strong password here");
Roles.AddUserToRole("admin", "Administrator");

Conclusión

En resumen, después de leer este artículo debe tener los conocimientos básicos necesarios para crear su propia aplicación de ASP.NET de tres niveles. Asimismo, ahora dispone de dos objetos que puede utilizar libremente para encapsular miembros y funciones. Puede, por ejemplo, utilizar el control DetailView y, en tan sólo unos minutos, crear una interfaz DetailView completa para los miembros que exploran, insertan, actualizan y eliminan miembros. Anímese a intentarlo.

En este artículo, se han omitido específicamente los detalles de las implementaciones de adición, actualización y eliminación de miembros y funciones. Si examina el código fuente, comprobará que he utilizado las API de un modo muy directo. Describir dichas llamadas en detalle no supondrá mayor ventaja, ya que estoy seguro de que si aún está leyendo este artículo, al igual que yo, estará conociendo este tema a medida que avanza.

Este año tuve la suerte de asistir al evento MS TechEd celebrado en Orlando y a la conferencia PDC que tuvo lugar en Los Ángeles, donde pude realizar numerosas preguntas al equipo de ASP.NET. En concreto, me gustaría agradecer a Brad Millington y Stefan Schackow su amabilidad al responder a todas mis cuestiones durante esas semanas, y a Jeff King y Brian Goldfarb por su ayuda en la mejora de este artículo. Se puede decir que este artículo es la forma que tengo de agradecerles su ayuda, ya que he contribuido en cierta medida a que no tengan que responder a tantas preguntas en el futuro.

Acerca del autor

Peter Kellner fundó 73rd Street Associates en 1990, donde elaboró con éxito sistemas de programación clínica universitaria, administración de compañías de seguros y administración de centros médicos "llave en mano" para más de 500 clientes de Estados Unidos. Diez años más tarde, en 2000, 73rd Street Associates fue adquirida por una compañía de seguros de gran envergadura y Peter dio una nueva orientación laboral a su vida como consultor de software independiente. Entre las tecnologías en las que se encuentra involucrado en este momento se encuentran ASP.NET, Oracle, Java, VOiP y pronto SQL Server. Cuando no está inmerso en su trabajo, Peter pasa la mayor parte de su tiempo libre montando en bicicleta. Ya ha visitado gran parte del mundo; recientemente, él y su esposa Tammy recorrieron Estados Unidos, desde California a Georgia, en tan sólo 27 días.

El sitio del blog de Peter es http://peterkellner.net/ (en inglés). Encontrará este artículo y el código publicado en la sección de descarga.

Mostrar: