Autenticación y Autorización

Idiomas disponibles: en | + es | + fr | + ja | + ko | + tr

Esta traducción podría estar + obsoleta. Consulte la versión en inglés de la + documentación para comprobar si se han producido cambios + recientemente.

+ +

Autenticación es cualquier proceso por el cuál se verifica que uno es + quien dice ser. Autorización es cualquier proceso en el cuál cualquiera + está permitido a estar donde se quiera, o tener información la cuál se + quiera tener. +

+ +

Para información de control de acceso de forma genérica visiteHow to de Control de Acceso.

Módulos y Directivas Relacionados
Introducción
Los Prerequisitos
Conseguir que funcione
Dejar que más de una persona + entre
Posibles Problemas
Método alternativo de almacenamiento de las + contraseñas
Uso de múltiples proveedores
Más allá de la Autorización
Cache de Autenticación
Más información

Consulte también

Comentarios

Módulos y Directivas Relacionados

+ +

Hay tres tipos de módulos involucrados en los procesos de la autenticación + y autorización. Normalmente deberás escoger al menos un módulo de cada grupo.

+ +

Modos de Autenticación (consulte la directiva + AuthType ) +
- mod_auth_basic
- mod_auth_digest
+
Proveedor de Autenticación (consulte la directiva + AuthBasicProvider y + AuthDigestProvider) + +
- mod_authn_anon
- mod_authn_dbd
- mod_authn_dbm
- mod_authn_file
- mod_authnz_ldap
- mod_authn_socache
+
Autorización (consulte la directiva + Require) +
- mod_authnz_ldap
- mod_authz_dbd
- mod_authz_dbm
- mod_authz_groupfile
- mod_authz_host
- mod_authz_owner
- mod_authz_user
+

+ +

A parte de éstos módulos, también están + mod_authn_core y + mod_authz_core. Éstos módulos implementan las directivas + esenciales que son el centro de todos los módulos de autenticación.

+ +

El módulo mod_authnz_ldap es tanto un proveedor de + autenticación como de autorización. El módulo + mod_authz_host proporciona autorización y control de acceso + basado en el nombre del Host, la dirección IP o características de la propia + petición, pero no es parte del sistema proveedor de + autenticación. Para tener compatibilidad inversa con el mod_access, + hay un nuevo modulo llamado mod_access_compat.

+ +

También puedes mirar el how-to de Control de Acceso , donde se plantean varias formas del control de acceso al servidor.

+ +

Introducción

Si se tiene información en nuestra página web que sea información + sensible o pensada para un grupo reducido de usuarios/personas, + las técnicas que se describen en este manual, le servirán + de ayuda para asegurarse de que las personas que ven esas páginas sean + las personas que uno quiere.

+ +

Este artículo cubre la parte "estándar" de cómo proteger partes de un + sitio web que muchos usarán.

+ +

Nota:

Si de verdad es necesario que tus datos estén en un sitio seguro, + considera usar mod_ssl como método de autenticación adicional a cualquier forma de autenticación.

Los Prerequisitos

Las directivas que se usan en este artículo necesitaran ponerse ya sea + en el fichero de configuración principal del servidor ( típicamente en + la sección + <Directory> de httpd.conf ), o + en cada uno de los ficheros de configuraciones del propio directorio + (los archivos .htaccess).

+ +

Si planea usar los ficheros .htaccess , necesitarás + tener en la configuración global del servidor, una configuración que permita + poner directivas de autenticación en estos ficheros. Esto se hace con la + directiva AllowOverride, la cual especifica + que directivas, en su caso, pueden ser puestas en cada fichero de configuración + por directorio.

+ +

Ya que estamos hablando aquí de autenticación, necesitarás una directiva + AllowOverride como la siguiente: +

+ +

AllowOverride AuthConfig

+ + +

O, si solo se van a poner las directivas directamente en la configuración + principal del servidor, deberás tener, claro está, permisos de escritura + en el archivo.

+ +

Y necesitarás saber un poco de como está estructurado el árbol de + directorios de tu servidor, para poder saber donde se encuentran algunos + archivos. Esto no debería ser una tarea difícil, aún así intentaremos + dejarlo claro llegado el momento de comentar dicho aspecto.

+ +

También deberás de asegurarte de que los módulos + mod_authn_core y mod_authz_core + han sido incorporados, o añadidos a la hora de compilar en tu binario httpd o + cargados mediante el archivo de configuración httpd.conf. Estos + dos módulos proporcionan directivas básicas y funcionalidades que son críticas + para la configuración y uso de autenticación y autorización en el servidor web.

Conseguir que funcione

Aquí está lo básico de cómo proteger con contraseña un directorio en tu + servidor.

+ +

Primero, necesitarás crear un fichero de contraseña. Dependiendo de que + proveedor de autenticación se haya elegido, se hará de una forma u otra. Para empezar, + usaremos un fichero de contraseña de tipo texto.

+ +

Este fichero deberá estar en un sitio que no se pueda tener acceso desde + la web. Esto también implica que nadie pueda descargarse el fichero de + contraseñas. Por ejemplo, si tus documentos están guardados fuera de + /usr/local/apache/htdocs, querrás poner tu archivo de contraseñas en + /usr/local/apache/passwd.

+ +

Para crear el fichero de contraseñas, usa la utilidad + htpasswd que viene con Apache. Esta herramienta se + encuentra en el directorio /bin en donde sea que se ha + instalado el Apache. Si ha instalado Apache desde un paquete de terceros, + puede ser que se encuentre en su ruta de ejecución.

+ +

Para crear el fichero, escribiremos:

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords rbowen +

+ +

htpasswd te preguntará por una contraseña, y después + te pedirá que la vuelvas a escribir para confirmarla:

+ +

+ $ htpasswd -c /usr/local/apache/passwd/passwords rbowen + New password: mypassword + Re-type new password: mypassword + Adding password for user rbowen +

+ +

Si htpasswd no está en tu variable de entorno "path" del + sistema, por supuesto deberás escribir la ruta absoluta del ejecutable para + poder hacer que se ejecute. En una instalación por defecto, está en: + /usr/local/apache2/bin/htpasswd

+ +

Lo próximo que necesitas, será configurar el servidor para que pida una + contraseña y así decirle al servidor que usuarios están autorizados a acceder. + Puedes hacer esto ya sea editando el fichero httpd.conf + de configuración o usando in fichero .htaccess. Por ejemplo, + si quieres proteger el directorio + /usr/local/apache/htdocs/secret, puedes usar las siguientes + directivas, ya sea en el fichero .htaccess localizado en + following directives, either placed in the file + /usr/local/apache/htdocs/secret/.htaccess, o + en la configuración global del servidor httpd.conf dentro de la + sección <Directory + "/usr/local/apache/htdocs/secret"> , como se muestra a continuación:

+ +

<Directory "/usr/local/apache/htdocs/secret">
+AuthType Basic
+AuthName "Restricted Files"
+# (Following line optional)
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+Require user rbowen
+</Directory>

+ + +

Vamos a explicar cada una de las directivas individualmente. + La directiva AuthType selecciona el método + que se usa para autenticar al usuario. El método más común es + Basic, y éste es el método que implementa + mod_auth_basic. Es muy importante ser consciente, + de que la autenticación básica, envía las contraseñas desde el cliente + al servidor sin cifrar. + Este método por tanto, no debe ser utilizado para proteger datos muy sensibles, + a no ser que, este método de autenticación básica, sea acompañado del módulo + mod_ssl. + Apache soporta otro método más de autenticación que es del tipo + AuthType Digest. Este método, es implementado por el módulo mod_auth_digest y con el se pretendía crear una autenticación más + segura. Este ya no es el caso, ya que la conexión deberá realizarse con mod_ssl en su lugar. +

+ +

La directiva AuthName + establece el Realm para ser usado en la autenticación. El + Realm tiene dos funciones principales. + La primera, el cliente presenta a menudo esta información al usuario como + parte del cuadro de diálogo de contraseña. La segunda, que es utilizado por + el cliente para determinar qué contraseña enviar a para una determinada zona + de autenticación.

+ +

Así que, por ejemple, una vez que el cliente se ha autenticado en el área de + los "Ficheros Restringidos", entonces re-intentará automáticamente + la misma contraseña para cualquier área en el mismo servidor que es marcado + con el Realm de "Ficheros Restringidos" + Por lo tanto, puedes prevenir que a un usuario se le pida mas de una vez por su + contraseña, compartiendo así varias áreas restringidas el mismo Realm + Por supuesto, por razones de seguridad, el cliente pedirá siempre por una contraseña, + siempre y cuando el nombre del servidor cambie. +

+ +

La directiva AuthBasicProvider es, + en este caso, opcional, ya que file es el valor por defecto + para esta directiva. Deberás usar esta directiva si estas usando otro medio + diferente para la autenticación, como por ejemplo + mod_authn_dbm o mod_authn_dbd.

+ +

La directiva AuthUserFile + establece el path al fichero de contraseñas que acabamos de crear con el + comando htpasswd. Si tiene un número muy grande de usuarios, + puede ser realmente lento el buscar el usuario en ese fichero de texto plano + para autenticar a los usuarios en cada petición. + Apache también tiene la habilidad de almacenar información de usuarios en + unos ficheros de rápido acceso a modo de base de datos. + El módulo mod_authn_dbm proporciona la directiva AuthDBMUserFile. Estos ficheros pueden ser creados y + manipulados con el programa dbmmanage y htdbm. + Muchos otros métodos de autenticación así como otras opciones, están disponibles en + módulos de terceros + Base de datos de Módulos disponibles.

+ +

Finalmente, la directiva Require + proporciona la parte del proceso de autorización estableciendo el o los + usuarios que se les está permitido acceder a una región del servidor. + En la próxima sección, discutiremos las diferentes vías de utilizar la + directiva Require.

Dejar que más de una persona + entre

Las directivas mencionadas arriba sólo permiten a una persona + (especialmente con un usuario que en ej ejemplo es rbowen) + en el directorio. En la mayoría de los casos, se querrá permitir el acceso + a más de una persona. Aquí es donde la directiva + AuthGroupFile entra en juego.

+ +

Si lo que se desea es permitir a más de una persona el acceso, necesitarás + crear un archivo de grupo que asocie los nombres de grupos con el de personas + para permitirles el acceso. El formato de este fichero es bastante sencillo, + y puedes crearlo con tu editor de texto favorito. El contenido del fichero + se parecerá a:

+ +

+ GroupName: rbowen dpitts sungo rshersey +

+ +

Básicamente eso es la lista de miembros los cuales están en un mismo fichero + de grupo en una sola linea separados por espacios.

+ +

Para añadir un usuario a tu fichero de contraseñas existente teclee:

+ +

+ htpasswd /usr/local/apache/passwd/passwords dpitts +

+ +

Te responderá lo mismo que anteriormente, pero se añadirá al fichero + existente en vez de crear uno nuevo. (Es decir el flag -c será + el que haga que se genere un nuevo + fichero de contraseñas).

+ +

Ahora, tendrá que modificar su fichero .htaccess para que sea + parecido a lo siguiente:

+ +

AuthType Basic
+AuthName "By Invitation Only"
+# Optional line:
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group GroupName

+ + +

Ahora, cualquiera que esté listado en el grupo GroupName, + y tiene una entrada en el fichero de contraseñas, se les + permitirá el acceso, si introducen su contraseña correctamente.

+ +

Hay otra manera de dejar entrar a varios usuarios, que es menos específica. + En lugar de crear un archivo de grupo, sólo puede utilizar la siguiente + directiva:

+ +

Require valid-user

+ + +

Usando ésto en vez de la línea Require user rbowen + permitirá a cualquier persona acceder, la cuál aparece en el archivo de + contraseñas, y que introduzca correctamente su contraseña. Incluso puede + emular el comportamiento del grupo aquí, sólo manteniendo un fichero de + contraseñas independiente para cada grupo. La ventaja de este enfoque es + que Apache sólo tiene que comprobar un archivo, en lugar de dos. La desventaja + es que se tiene que mantener un montón de ficheros de contraseña de grupo, y + recuerde hacer referencia al fichero correcto en la directiva + AuthUserFile.

Posibles Problemas

Debido a la forma en que se especifica la autenticación básica, + su nombre de usuario y la contraseña deben ser verificados cada vez + que se solicita un documento desde el servidor. Esto es, incluso si + se vuelve a cargar la misma página, y para cada imagen de la página (si + provienen de un directorio protegido). Como se puede imaginar, esto + ralentiza las cosas un poco. La cantidad que ralentiza las cosas es + proporcional al tamaño del archivo de contraseñas, porque tiene que + abrir ese archivo, recorrer lista de usuarios hasta que llega a su nombre. + Y tiene que hacer esto cada vez que se carga una página.

+ +

Una consecuencia de esto, es que hay un limite práctico de cuantos + usuarios puedes introducir en el fichero de contraseñas. Este límite + variará dependiendo de la máquina en la que tengas el servidor, + pero puedes notar ralentizaciones en cuanto se metan cientos de entradas, + y por lo tanto consideraremos entonces otro método de autenticación + en ese momento. +

Método alternativo de almacenamiento de las + contraseñas

+ +

Debido a que el almacenamiento de las contraseñas en texto plano tiene + el problema mencionado anteriormente, puede que se prefiera guardar + las contraseñas en otro lugar como por ejemplo una base de datos. +

+ +

Los módulos mod_authn_dbm y mod_authn_dbd son + dos módulos que hacen esto posible. En vez de seleccionar la directiva de fichero + AuthBasicProvider , en su lugar + se puede elegir dbm o dbd como formato de almacenamiento.

+ +

Para seleccionar los ficheros de tipo dbm en vez de texto plano, podremos hacer algo parecido a lo siguiente:

+ +

<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider dbm
+    AuthDBMUserFile "/www/passwords/passwd.dbm"
+    Require valid-user
+</Directory>

+ + +

Hay otras opciones disponibles. Consulta la documentación de + mod_authn_dbm para más detalles.

Uso de múltiples proveedores

+ +

Con la introducción de la nueva autenticación basada en un proveedor y + una arquitectura de autorización, ya no estaremos restringidos a un único + método de autenticación o autorización. De hecho, cualquier número de + los proveedores pueden ser mezclados y emparejados para ofrecerle + exactamente el esquema que se adapte a sus necesidades. + En el siguiente ejemplo, veremos como ambos proveedores tanto el fichero + como el LDAP son usados en la autenticación: +

+ +

<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file ldap
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    Require valid-user
+</Directory>

+ + +

En este ejemplo el fichero, que actúa como proveedor, intentará autenticar + primero al usuario. Si no puede autenticar al usuario, el proveedor del LDAP + será llamado para que realice la autenticación. + Esto permite al ámbito de autenticación ser amplio, si su organización + implementa más de un tipo de almacén de autenticación. + Otros escenarios de autenticación y autorización pueden incluir la + mezcla de un tipo de autenticación con un tipo diferente de autorización. + Por ejemplo, autenticar contra un fichero de contraseñas pero autorizando + dicho acceso mediante el directorio del LDAP.

+ +

Así como múltiples métodos y proveedores de autenticación pueden + ser implementados, también pueden usarse múltiples formas de + autorización. + En este ejemplo ambos ficheros de autorización de grupo así como + autorización de grupo mediante LDAP va a ser usado: +

+ +

<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    AuthGroupFile "/usr/local/apache/passwd/groups"
+    Require group GroupName
+    Require ldap-group cn=mygroup,o=yourorg
+</Directory>

+ + +

Para llevar la autorización un poco más lejos, las directivas + de autorización de contenedores tales como + <RequireAll> + and + <RequireAny> + nos permiten aplicar una lógica de en qué orden se manejará la autorización dependiendo + de la configuración y controlada a través de ella. + Mire también Contenedores de + Autorización para ejemplos de cómo pueden ser aplicados.

+ +

Más allá de la Autorización

+ +

El modo en que la autorización puede ser aplicada es ahora mucho más flexible + que us solo chequeo contra un almacén de datos (contraseñas). Ordenando la + lógica y escoger la forma en que la autorización es realizada, ahora es posible +

+ +

Aplicando la lógica y ordenación

Controlar el cómo y en qué orden se va a aplicar la autorización ha + sido un misterio en el pasado. En Apache 2.2 un proveedor del + mecanismo de autenticación fue introducido para disociar el proceso actual + de autenticación y soportar funcionalidad. + Uno de los beneficios secundarios fue que los proveedores de autenticación + podían ser configurados y llamados en un orden especifico que no dependieran + en el orden de carga del propio modulo. + Este proveedor de dicho mecanismo, ha sido introducido en la autorización + también. Lo que esto significa es que la directiva + Require + no sólo especifica que método de autorización deberá ser usado, si no + también especifica el orden en que van a ser llamados. Múltiples + métodos de autorización son llamados en el mismo orden en que la directiva + Require aparece en la + configuración. +

+ +

+ Con la Introducción del contenedor de directivas de autorización tales como + <RequireAll> + y + <RequireAny>, + La configuración también tiene control sobre cuándo se llaman a los métodos + de autorización y qué criterios determinan cuándo se concede el acceso. + Vease + Contenedores de autorización + Para un ejemplo de cómo pueden ser utilizados para expresar una lógica + más compleja de autorización. +

+ +

+ Por defecto todas las directivas + Require + son manejadas como si estuvieran contenidas en una directiva + <RequireAny>. + En otras palabras, Si alguno de los métodos de autorización + especificados tiene éxito, se concede la autorización. +

+ + + +

Uso de los proveedores de autorización para + el control de acceso

+ +

+ La autenticación de nombre de usuario y contraseña es sólo parte + de toda la historia que conlleva el proceso. Frecuentemente quiere + dar acceso a la gente en base a algo más que lo que son. + Algo como de donde vienen. +

+ +

+ Los proveedores de autorización all, + env, host y ip + te permiten denegar o permitir el acceso basándose en otros + criterios como el nombre de la máquina o la IP de la máquina que + realiza la consulta para un documento. +

+ +

+ El uso de estos proveedores se especifica a través de la directiva + Require. + La directiva registra los proveedores de autorización que serán llamados + durante la solicitud de la fase del proceso de autorización. Por ejemplo: +

+ +

Require ip address
+

+ + +

+ Donde address es una dirección IP (o una dirección IP parcial) + o bien: +

+ +

Require host domain_name
+

+ + +

+ Donde domain_name es el nombre completamente cualificado de un nombre + de dominio (FQDN) (o un nombre parcial del dominio); + puede proporcionar múltiples direcciones o nombres de dominio, si se desea. +

+ +

+ Por ejemplo, si alguien envía spam a su tablón de mensajes y desea + mantenerlos alejados, podría hacer lo siguiente:

+ +

<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>

+ + +

+ Visitantes que vengan desde esa IP no serán capaces de ver el contenido + que cubre esta directiva. Si, en cambio, lo que se tiene es el nombre de + la máquina, en vez de la dirección IP, podría usar: +

+ +

<RequireAll>
+    Require all granted
+    Require not host host.example.com
+</RequireAll>

+ + +

+ Y, si lo que se quiere es bloquear el acceso desde un determinado dominio + (bloquear el acceso desde el dominio entero), puede especificar parte + de la dirección o del propio dominio a bloquear: +

+ +

<RequireAll>
+    Require all granted
+    Require not ip 192.168.205
+    Require not host phishers.example.com moreidiots.example
+    Require not host ke
+</RequireAll>

+ + +

+ Usando <RequireAll> + con múltiples directivas <Require>, cada una negada con un not, + Sólo permitirá el acceso, si todas las condiciones negadas son verdaderas. + En otras palabras, el acceso será bloqueado, si cualquiera de las condiciones + negadas fallara. +

+ + + +

Compatibilidad de Control de Acceso con versiones + anteriores

+ +

+ Uno de los efectos secundarios de adoptar proveedores basados en + mecanismos de autenticación es que las directivas anteriores + Order, + Allow, + Deny y + Satisfy ya no son necesarias. + Sin embargo, para proporcionar compatibilidad con configuraciones antiguas, + estas directivas se han movido al módulo mod_access_compat. +

+ +

Nota:

+ Las directivas proporcionadas por mod_access_compat + han quedado obsoletas por mod_authz_host. Mezclar + directivas antiguas como + Order, + Allow ó + Deny con las nuevas + como + Require + es técnicamente posible pero desaconsejable. El módulo + mod_access_compat se creó para soportar configuraciones + que contuvieran sólo directivas antiguas para facilitar la actualización + a la versión 2.4. + Por favor revise la documentación de + actualización para más información al + respecto. +

+ + +

Cache de Autenticación

+ Puede haber momentos en que la autenticación ponga una carga + inaceptable en el proveedor (de autenticación) o en tu red. + Esto suele afectar a los usuarios de mod_authn_dbd + (u otros proveedores de terceros/personalizados). + Para lidiar con este problema, HTTPD 2.3/2.4 introduce un nuevo proveedor + de caché mod_authn_socache para cachear las credenciales + y reducir la carga en el proveedor(es) original. +

+ Esto puede ofrecer un aumento de rendimiento sustancial para algunos usuarios. +

Más información

+ +

+ También debería leer la documentación para + mod_auth_basic y mod_authz_host + la cuál contiene más información de como funciona todo esto. + La directiva <AuthnProviderAlias> puede también ayudar + a la hora de simplificar ciertas configuraciones de autenticación. +

+ +

+ Los diferentes algoritmos de cifrado que están soportados por Apache + para la autenticación se explican en + Cifrado de Contraseñas. +

+ +

+ Y tal vez quiera ojear la documentación de "how to" + Control de Acceso donde se mencionan temas + relacionados.

+ +