Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La autenticación es el proceso de identificación de quién es el cliente, normalmente para determinar si el cliente es apto para acceder a un recurso. El protocolo HTTP admite la autenticación como medio para negociar el acceso a un recurso seguro.
La solicitud inicial de un cliente suele ser una solicitud anónima, no contiene ninguna información de autenticación. Las aplicaciones de servidor HTTP pueden denegar la solicitud anónima al indicar que se requiere autenticación. La aplicación de servidor envía encabezados WWW-Authentication para indicar los esquemas de autenticación admitidos. En este artículo se describen varios esquemas de autenticación para HTTP y se describe su compatibilidad con Windows Communication Foundation (WCF).
Esquemas de autenticación HTTP
El servidor puede especificar varios esquemas de autenticación entre los que elegir el cliente. En la tabla siguiente se describen algunos de los esquemas de autenticación que se encuentran habitualmente en las aplicaciones de Windows:
| Esquema de autenticación | Descripción |
|---|---|
| Anónimo | Una solicitud anónima no contiene ninguna información de autenticación. Anonymous equivale a conceder acceso a todos los usuarios al recurso. |
| Básico | La autenticación básica envía una cadena codificada en Base64 que contiene un nombre de usuario y una contraseña para el cliente. Base64 no es una forma de cifrado y debe considerarse igual que enviar el nombre de usuario y la contraseña en texto no cifrado. Si es necesario proteger un recurso, considere encarecidamente la posibilidad de usar un esquema de autenticación distinto de la autenticación básica. |
| Resumen | La autenticación implícita es un esquema de desafío-respuesta destinado a reemplazar a la autenticación básica. El servidor envía una cadena de datos aleatorios denominado nonce al cliente como desafío. El cliente responde con un hash que incluye el nombre de usuario, la contraseña y nonce, entre información adicional. La complejidad que introduce este intercambio y el hash de datos hace más difícil el robo y el reutilizar las credenciales del usuario con este esquema de autenticación. La autenticación digest requiere el uso de cuentas de dominio de Windows. El ámbito de síntesis es el nombre de dominio de Windows. Por consiguiente, no puede usar un servidor que se ejecute en un sistema operativo que no admita los dominios de Windows, como Windows XP Home Edition, con autenticación implícita. Por el contrario, cuando el cliente se ejecuta en un sistema operativo que no admite dominios de Windows, se debe especificar explícitamente una cuenta de dominio durante la autenticación. |
| NTLM | La autenticación NT LAN Manager (NTLM) es un esquema de desafío-respuesta que representa una variación más segura de la autenticación Digest. NTLM usa credenciales de Windows para transformar los datos de desafío en lugar del nombre de usuario y la contraseña sin codificar. La autenticación NTLM requiere varios intercambios entre el cliente y el servidor. El servidor y los servidores proxy intermedios deben admitir conexiones persistentes para completar correctamente la autenticación. |
| Negociar | El sistema de autenticación Negotiate selecciona automáticamente entre el protocolo Kerberos y la autenticación NTLM, según disponibilidad. El protocolo Kerberos se usa si está disponible; De lo contrario, se intenta NTLM. La autenticación Kerberos mejora significativamente en NTLM. La autenticación Kerberos es tanto más rápida como NTLM y permite el uso de la autenticación mutua y la delegación de credenciales en máquinas remotas. |
| Windows Live ID | El servicio HTTP subyacente de Windows incluye la autenticación mediante protocolos federados. Sin embargo, los transportes HTTP estándar en WCF no admiten el uso de esquemas de autenticación federados, como Microsoft Windows Live ID. La compatibilidad con esta característica está disponible actualmente mediante la seguridad de mensajes. Para más información, consulte Federación y tokens emitidos. |
Elegir un esquema de autenticación
Al seleccionar los posibles esquemas de autenticación para un servidor HTTP, algunos elementos que se deben tener en cuenta son los siguientes:
Tenga en cuenta si el recurso debe protegerse. El uso de la autenticación HTTP requiere transmitir más datos y puede limitar la interoperabilidad con los clientes. Permitir el acceso anónimo a los recursos que no necesitan estar protegidos.
Si el recurso debe protegerse, tenga en cuenta qué esquemas de autenticación proporcionan el nivel de seguridad necesario. El esquema de autenticación estándar más débil que se describe aquí es autenticación básica. La autenticación básica no protege las credenciales del usuario. El esquema estándar de autenticación más seguro es la autenticación Negotiate, que da como resultado el protocolo Kerberos.
Un servidor no debe presentar, por ejemplo, en los encabezados de WWW-Authentication), ningún esquema que no esté preparado para aceptar o que no proteja adecuadamente el recurso protegido. Los clientes pueden elegir entre cualquiera de los esquemas de autenticación que presenta el servidor. Algunos clientes tienen como valor predeterminado un esquema de autenticación débil o el primer esquema de autenticación de la lista del servidor.