Representación de ASP.NET
Cuando se utiliza la representación, las aplicaciones ASP.NET se pueden ejecutar, opcionalmente, con la identidad del cliente en cuyo nombre funcionan. Normalmente, esto se hace así para evitar problemas de autenticación y autorización en el código de la aplicación ASP.NET. En su lugar, Servicios de Microsoft Internet Information Server (IIS) realiza la autenticación del usuario y pasa un símbolo autenticado (token) a la aplicación ASP.NET o bien, si no puede autenticar al usuario, pasa un símbolo no autenticado. En ambos casos, la aplicación ASP.NET representa el símbolo (token) recibido si está habilitada la representación. La aplicación ASP.NET, que ahora representa al cliente, se basa entonces en la configuración de archivos y directorios NTFS para permitir o denegar el acceso. Asegúrese de que el espacio de archivos del servidor tiene un formato NTFS para que se puedan establecer los permisos de acceso.
De forma predeterminada, la representación está deshabilitada. Para que exista compatibilidad con ASP, el usuario debe habilitar explícitamente la representación. Si la representación está habilitada para una aplicación, ASP.NET representa siempre al símbolo (token) de acceso que proporciona IIS para extensiones ISAPI. Este símbolo puede ser un símbolo (token) de usuario autenticado o el símbolo de un usuario anónimo (como IUSR_MACHINENAME). La representación se produce independientemente del tipo de autenticación que se utilice en la aplicación.
Sólo se representa el código de la aplicación; la compilación y la configuración se leen como el símbolo (token) de proceso. El resultado de la compilación se pone en el directorio "Archivos temporales de ASP.NET". La cuenta que se representa necesita acceso de lectura/escritura a este directorio. Si una aplicación está en un recurso compartido de Convención de nomenclatura universal (UNC), ASP.NET representará siempre al símbolo proporcionado a IIS para tener acceso al recurso compartido, a menos que se utilice una cuenta configurada. Si se proporciona una cuenta configurada explícita, ASP.NET preferirá utilizar esa cuenta antes que el símbolo UNC de IIS. Si se desea que las aplicaciones utilicen la representación por solicitud, simplemente se deben configurar para representar al usuario que hace la solicitud.
De forma predeterminada, la representación está deshabilitada en el nivel del equipo y, a menos que se reemplace, todos los dominios de la aplicación heredan esta configuración. Se puede habilitar la representación mediante la colocación de un archivo de configuración en el directorio raíz de la aplicación. Para obtener más información sobre el sistema de configuración de ASP.NET, vea Configuración de ASP.NET.
Como ocurre con las otras directivas de configuración, esta directiva se aplica jerárquicamente. Las aplicaciones anidadas de la jerarquía respetan esta directiva, a menos que se reemplace explícitamente. El valor predeterminado de esta configuración es el siguiente:
<impersonation enable="false"/>
Un archivo de configuración mínimo para permitir la representación de una aplicación puede ser similar al del ejemplo siguiente:
<!-- Web.config file. -->
<identity impersonate="true"/>
También se puede utilizar la compatibilidad con nombres para ejecutar una aplicación como una identidad configurable. Por ejemplo:
<identity impersonate="true" userName="contoso\Jane" password="pass"/>
Esto permite ejecutar toda la aplicación como contoso\Jane, independientemente de la identidad de la solicitud y siempre que la contraseña sea correcta. Este tipo de representación se puede delegar en otro equipo.
La identidad del usuario representado se puede leer mediante programación, tal y como se muestra en el siguiente ejemplo.
Dim username As String = System.Security.Principal.WindowsIdentity.GetCurrent().Name
[C#]
String username = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
En el anterior ejemplo, se almacenan userName y password en texto no cifrado en el archivo de configuración. Aunque IIS no transmitirá archivos .config como respuesta a la solicitud de un agente de usuario, los archivos de configuración se pueden leer de otro modo, por ejemplo por un usuario autenticado con credenciales correctas en el dominio que contiene el servidor. Para garantizar una mayor seguridad, la sección de identidad admite el almacenamiento de los atributos userName y password codificados en el registro, tal y como se muestra en el siguiente ejemplo.
userName="registry:HKLM\Software\AspNetIdentity,Name"
password="registry:HKLM\Software\AspNetIdentity,Password"
La parte de la cadena detrás de la palabra clave registry y delante de la coma indica el nombre de la clave del Registro que abre ASP.NET. La parte situada detrás de la coma contiene un solo valor de cadena del que ASP.NET leerá las credenciales. La coma es necesaria y las credenciales deben almacenarse en el subárbol HKLM. Si el formato de configuración no es correcto, ASP.NET no iniciará el proceso de trabajo y se seguirá la actual ruta de acceso al código de error de la creación de cuenta.
Las credenciales deben tener el formato REG_BINARY, que contiene el resultado de una llamada a la función CryptProtectData de la API de Windows. Puede crear las credenciales codificadas y almacenarlas en el registro con la aplicación de consola Establecer registro de ASP.NET (Aspnet_setreg.exe), que utiliza CryptProtectData para realizar la codificación. Para descargar Aspnet_setreg.exe, junto con el código fuente de Visual C++ y la documentación, visite el sitio Web www.asp.net y busque "aspnet_setreg".
Para configurar el acceso a la clave, almacene las credenciales codificadas de modo que se conceda acceso únicamente a los administradores y al SISTEMA. Dado que la clave la leerá el proceso de ASP.NET que se ejecuta como SISTEMA, establezca los siguientes permisos:
Administradores:F
SISTEMA:F
PROPIETARIO DE CREADOR:F
ProcessAccount:R
De este modo, se obtienen dos líneas de defensa para proteger los datos:
- Los permisos ACL requieren que la identidad que obtiene acceso a los datos sea la de un administrador.
- Un agresor debe ejecutar código en el servidor (CryptUnprotectData) para recuperar las credenciales de la cuenta.