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.
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.
Si de verdad es necesario que tus datos estén en un sitio seguro, 
    	considera usar 
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 
    .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 
Ya que estamos hablando aquí de autenticación, necesitarás una directiva 
    	
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 
    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.
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 
    	/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:
Si /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:
Vamos a explicar cada una de las directivas individualmente.
    	La directiva Basic, y éste es el método que implementa 
    AuthType Digest. Este método, es implementado por el módulo 
La directiva 
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 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
    
La directiva 
Finalmente, la directiva 
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 
    
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:
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:
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
    
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.
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 , 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:
Hay otras opciones disponibles. Consulta la documentación de
    
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:
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:
Para llevar la autorización un poco más lejos, las directivas 
    	de autorización de contenedores tales como
    
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
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 
        	
        	Con la Introducción del contenedor de directivas de autorización tales como
	        
        	Por defecto todas las directivas 
        	
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
        	
Donde address es una dirección IP (o una dirección IP parcial) o bien:
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:
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:
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:
        	Usando 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.
        
        	Uno de los efectos secundarios de adoptar proveedores basados en 
        	mecanismos de autenticación es que las directivas anteriores
	        
	        	Las directivas proporcionadas por 
		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 
Esto puede ofrecer un aumento de rendimiento sustancial para algunos usuarios.
    	También debería leer la documentación para
    	
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.