BizTalk 2004 Server - Tecnología, Tips y Programación por Sergio ...

cifra el desafío usando este hash como
clave para el proceso de encriptación,
con lo que se obtiene otro hash único
para ese valor de desafío y ese usuario.
Este nuevo hash generado se envía
al servidor junto con el nombre de
usuario por la misma conexión por
donde se recibió (ésta se mantiene en
estado keep alive), lo cual asegura la
autenticidad del servidor.
6. El servidor envía el hash recibido, el
nombre de usuario y el valor de desafío
al controlador primario de dominio
(de haberlo). El PDC cifra el
desafío con el hash del usuario que se
guarda en la base de datos SAM del
sistema o en el Directorio Activo.
7. Si el hash generado en el PDC coincide
con el que envió el cliente quiere
decir que la autenticación ha tenido
éxito y se envía la página solicitada
en caso de que el usuario tenga
permisos suficientes.
Algún lector en este punto podría
preguntar: si lo único que se conoce del
usuario es su hash que por definición no
se puede descifrar, ¿por qué no enviarlo
directamente en lugar de obtener uno
nuevo a partir de éste y del desafío? Si
se hiciese de este modo cualquiera
podría interceptar el hash del usuario y
luego utilizarlo para hacerse pasar por
él, tal y como pasaba en el método anterior.
Con el método descrito sólo puede
autenticarse aquel que tenga el hash
y el desafío enviado por el servidor, que
cambia en cada ocasión, con lo que las
cosas se complican. Para entenderlo
mejor se podría asimilar en cierto modo
a un algoritmo de clave pública en el
que la contraseña del usuario sería una
clave privada y el desafío enviado por el
servidor una clave pública que va cambiando
aleatoriamente.
Internet Explorer efectúa todo el
proceso de modo transparente usando
el nombre y la contraseña que el usuario
utilizó para entrar en la máquina
cliente, y sólo si falla en este primer
intento muestra un cuadro de diálogo
para pedir otros datos diferentes. Este
hecho puede hacer que parezca que a
veces un acceso a IIS ha sido anónimo
cuando no es así en realidad.
La autenticación integrada de
Windows posee la limitación adicional
de no funcionar a través de conexiones
proxy, por lo que habrá que tenerlo en
cuenta en caso de que nuestros usuarios
las utilicen.
En definitiva, siempre que podamos
deberemos usar la autenticación integrada.
Sin embargo esto sólo será posible
si se accede directamente al servidor
(sin usar un Proxy o un cortafuegos)
y en sistemas con Windows 2000
o superior. Debido a estas restricciones
en la práctica este método se usa sólo en
Intranets, dejando para Internet normalmente
la autenticación básica.
SSL y Certificados digitales
Una buena opción para habilitar la
autenticación de usuarios segura e independiente
del navegador consiste en
combinar el método de autenticación
básica descrito anteriormente con un
certificado digital de servidor. De este
modo el usuario se asegura de que se
está comunicando con el servidor adecuado,
y por otro lado se consigue que
la información en claro que circula normalmente
codificada como base64 se
transmita ahora cifrada gracias al uso
del algoritmo de clave pública que conlleva
el uso de este tipo de certificados.
Del mismo modo, en entornos que
requieran una alta seguridad se puede
exigir a los usuarios el empleo de certificados
digitales en el lado del cliente.
Puede obtener información detallada
sobre este proceso consultando el
artículo “Configuración de sitio Web
seguro con Certificado de clientes” de
Pedro Gómez en el número 4 de mayo
de 2004 de dotNetManía.
Suplantación de usuarios
IIS no es más que otra aplicación
que se ejecuta sobre el sistema operativo,
por lo que es éste en última instancia
el que se ocupa del nivel más bajo de
la cadena de la seguridad. En el caso que
nos ocupa dicho nivel lo constituye el
sistema de archivos.
En Windows, cada proceso se ejecuta
dentro de su propio contexto de
seguridad. Cuando un proceso accede
al sistema de archivos NTFS los permisos
se le otorgan en función del contexto
en el que se ejecute. Normalmente
si un proceso lanza otro subproceso éste
se ejecutará bajo el mismo contexto de
seguridad. Existen casos sin embargo en
los que, por razones de seguridad, un
proceso puede producir otros procesos
que trabajen bajo condiciones de seguridad
diferentes. Esto es lo que ocurre
con IIS. Éste trabaja bajo el contexto de
seguridad del sistema, esto es, como si
se tratase del usuario System. Sin embargo
cuando IIS ejecuta una aplicación
ASP/ASP.NET, inicia un nuevo proceso
bajo un contexto de seguridad diferente,
efectuando lo que se denomina
una suplantación de usuario. De este
modo si el código de servidor de una
página (o alguno de los componentes
que ésta emplee) intenta acceder al disco
duro u otro recurso del sistema, lo
hará con los permisos del usuario al que
está suplantando el proceso bajo el que
se ejecuta, es decir, bajo el contexto de
seguridad de dicho usuario. Este párrafo,
aunque algo enrevesado, es fundamental
para entender las implicaciones
de seguridad en el sistema de archivos.
Suplantación de usuarios en ASP