Autenticación y Autorización

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.

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 te preguntará por una contraseña, y después te pedirá que la vuelvas a escribir para confirmarla:

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:

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:

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 proveedior de autenticación C In Apache 2.2 a provider-based authentication mechanism was introduced to decouple the actual authentication process from authorization and supporting functionality. One of the side benefits was that authentication providers could be configured and called in a specific order which didn't depend on the load order of the auth module itself. This same provider based mechanism has been brought forward into authorization as well. What this means is that the Require directive not only specifies which authorization methods should be used, it also specifies the order in which they are called. Multiple authorization methods are called in the same order in which the Require directives appear in the configuration.

With the introduction of authorization container directives such as <RequireAll> and <RequireAny>, the configuration also has control over when the authorization methods are called and what criteria determines when access is granted. See Authorization Containers for an example of how they may be used to express complex authorization logic.

By default all Require directives are handled as though contained within a <RequireAny> container directive. In other words, if any of the specified authorization methods succeed, then authorization is granted.

Using authorization providers for access control

Authentication by username and password is only part of the story. Frequently you want to let people in based on something other than who they are. Something such as where they are coming from.

The authorization providers all, env, host and ip let you allow or deny access based on other host based criteria such as host name or ip address of the machine requesting a document.

The usage of these providers is specified through the Require directive. This directive registers the authorization providers that will be called during the authorization stage of the request processing. For example:

Require ip address
        

where address is an IP address (or a partial IP address) or:

Require host domain_name
        

where domain_name is a fully qualified domain name (or a partial domain name); you may provide multiple addresses or domain names, if desired.

For example, if you have someone spamming your message board, and you want to keep them out, you could do the following:

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

Visitors coming from that address will not be able to see the content covered by this directive. If, instead, you have a machine name, rather than an IP address, you can use that.

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

And, if you'd like to block access from an entire domain, you can specify just part of an address or domain name:

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

Using <RequireAll> with multiple <Require> directives, each negated with not, will only allow access, if all of negated conditions are true. In other words, access will be blocked, if any of the negated conditions fails.

Access Control backwards compatibility

One of the side effects of adopting a provider based mechanism for authentication is that the previous access control directives Order, Allow, Deny and Satisfy are no longer needed. However to provide backwards compatibility for older configurations, these directives have been moved to the mod_access_compat module.

Authentication Caching

There may be times when authentication puts an unacceptable load on a provider or on your network. This is most likely to affect users of mod_authn_dbd (or third-party/custom providers). To deal with this, HTTPD 2.3/2.4 introduces a new caching provider mod_authn_socache to cache credentials and reduce the load on the origin provider(s).

This may offer a substantial performance boost to some users.

More information

You should also read the documentation for mod_auth_basic and mod_authz_host which contain some more information about how this all works. The directive <AuthnProviderAlias> can also help in simplifying certain authentication configurations.

The various ciphers supported by Apache for authentication data are explained in Password Encryptions.

And you may want to look at the Access Control howto, which discusses a number of related topics.