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 apache2.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 apache2.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 apache2.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 apache2.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 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.

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.