From: André Malo Date: Sun, 23 Oct 2016 20:34:37 +0000 (+0000) Subject: fix props, update transformation X-Git-Tag: 2.5.0-alpha~1066 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=5c38c3808e8d276e5b334dd138cbfe6b7cd3fd4e;p=apache fix props, update transformation git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1766316 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/expr.html.en b/docs/manual/expr.html.en index 3885f37ba2..058a8ec311 100644 --- a/docs/manual/expr.html.en +++ b/docs/manual/expr.html.en @@ -23,8 +23,7 @@
Apache > HTTP Server > Documentation > Version 2.5

Expressions in Apache HTTP Server

-

Available Languages:  edited  | - en  | +

Available Languages:  en  |  fr 

@@ -649,8 +648,7 @@ Header always set CustomHeader my-value "expr=%{REQUEST_URI} =~ m#^/special_path are available for versions 2.5.0 and later.

-

Available Languages:  edited  | - en  | +

Available Languages:  en  |  fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versión 2.5 del Servidor HTTP Apache

-
-
<-
-

Autenticación y Autorización

-
-

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

-
- -

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.

-
- -
top
-
-

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.

- - - -

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.

- -
top
-
-

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.

-
-
top
-
-

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.

-
top
-
-

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.

-
top
-
-

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.

-
top
-
-

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

-
top
-
-

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.

-
top
-
-

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.

- -
top
-
-

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.

- -

Note

-

The directives provided by mod_access_compat have - been deprecated by mod_authz_host. - Mixing old directives like Order, Allow or Deny with new ones like - Require is technically possible - but discouraged. The mod_access_compat module was created to support - configurations containing only old directives to facilitate the 2.4 upgrade. - Please check the upgrading guide for more - information. -

-
- - -
top
-
-

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.

-
top
-
-

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.

- -
-
-

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

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+ --> +Autenticación y Autorización - Servidor HTTP Apache Versión 2.5 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.5 del Servidor HTTP Apache

+
+
<-
+

Autenticación y Autorización

+
+

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

+
+ +

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.

+
+ +
top
+
+

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.

+ + + +

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.

+ +
top
+
+

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.

+
+
top
+
+

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.

+
top
+
+

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.

+
top
+
+

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.

+
top
+
+

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

+
top
+
+

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.

+
top
+
+

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.

+ +
top
+
+

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.

+ +

Note

+

The directives provided by mod_access_compat have + been deprecated by mod_authz_host. + Mixing old directives like Order, Allow or Deny with new ones like + Require is technically possible + but discouraged. The mod_access_compat module was created to support + configurations containing only old directives to facilitate the 2.4 upgrade. + Please check the upgrading guide for more + information. +

+
+ + +
top
+
+

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.

+
top
+
+

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.

+ +
+
+

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

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+//--> \ No newline at end of file diff --git a/docs/manual/howto/auth.html.fr b/docs/manual/howto/auth.html.fr index cec7303415..81af68f1ea 100644 --- a/docs/manual/howto/auth.html.fr +++ b/docs/manual/howto/auth.html.fr @@ -30,6 +30,8 @@  ko  |  tr 

+
Cette traduction peut être périmée. Vérifiez la version + anglaise pour les changements récents.

L'authentification est un processus qui vous permet de vérifier qu'une personne est bien celle qu'elle prétend être. L'autorisation diff --git a/docs/manual/howto/auth.xml.fr b/docs/manual/howto/auth.xml.fr index aa5a8d5eb6..314eadf944 100644 --- a/docs/manual/howto/auth.xml.fr +++ b/docs/manual/howto/auth.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/howto/auth.xml.ja b/docs/manual/howto/auth.xml.ja index 824e813389..8c7ca837c9 100644 --- a/docs/manual/howto/auth.xml.ja +++ b/docs/manual/howto/auth.xml.ja @@ -1,7 +1,7 @@ - + + + -How-To / Tutoriales - Servidor HTTP Apache Versión 2.5 - - - - - - -

-

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versión 2.5 del Servidor HTTP Apache

-
-
<-
-

How-To / Tutoriales

-
-

Idiomas disponibles:  en  | - es  | - fr  | - ja  | - ko  | - zh-cn 

-
-
-
top
-
-

How-To / Tutoriales

- - - -
-
Autenticación y Autorización
-
-

Autenticación es un proceso en el cual se verifica - que alguien es quien afirma ser. Autorización es cualquier - proceso en el que se permite a alguien acceder donde quiere ir, - o a obtener la información que desea tener.

- -

Ver: Autenticación, Autorización

-
-
- -
-
Control de Acceso
-
-

Control de acceso hace referencia al proceso de restringir, o - garantizar el acceso a un recurso en base a un criterio arbitrario. - Esto se puede conseguir de distintas formas.

- -

Ver: Control de Acceso

-
-
- -
-
Contenido Dinámico con CGI
-
-

El CGI (Common Gateway Interface) es un método por el cual - un servidor web puede interactuar con programas externos de - generación de contenido, a ellos nos referimos comúnmente como - programas CGI o scripts CGI. Es un método sencillo para mostrar - contenido dinámico en tu sitio web. Este documento es una - introducción para configurar CGI en tu servidor web Apache, y de - inicio para escribir programas CGI.

- -

Ver: CGI: Contenido Dinámico

-
-
- -
-
Ficheros .htaccess
-
-

Los ficheros .htaccess facilitan una forma de - hacer configuraciones por-directorio. Un archivo, que - contiene una o más directivas de configuración, se coloca en un - directorio específico y las directivas especificadas solo aplican - sobre ese directorio y los subdirectorios del mismo.

- -

Ver: .htaccess files

-
-
- -
-
HTTP/2 con httpd
-
-

HTTP/2 es la evolución del protocolo de capa de aplicación más conocido, HTTP. - Se centra en hacer un uso más eficiente de los recursos de red sin cambiar la - semántica de HTTP. Esta guía explica como se implementa HTTP/2 en httpd, - mostrando buenas prácticas y consejos de configuración básica. -

- -

Ver: Guía HTTP/2

-
-
- - -
-
Introducción a los SSI
-
-

Los SSI (Server Side Includes) son directivas que se colocan - en las páginas HTML, y son evaluadas por el servidor mientras - éste las sirve. Le permiten añadir contenido generado - dinámicamente a una página HTML existente, sin tener que servir - la página entera a través de un programa CGI u otro método - dinámico.

- -

Ver: Server Side Includes (SSI)

-
-
- -
-
Directorios web Por-usuario
-
-

En sistemas con múltiples usuarios, cada usuario puede tener - su directorio "home" compartido usando la directiva - UserDir. Aquellos - que visiten la URL http://example.com/~username/ - obtendrán contenido del directorio del usuario "username" - que se encuentra en el directorio "home" del sistema.

- -

Ver: - Directorios Web de Usuario (public_html)

-
-
- -
-
Guía de Proxy Inverso
-
-

Apache httpd ofrece muchas posibilidades como proxy inverso. Usando la - directiva ProxyPass así como - BalancerMember puede crear - sofisticadas configuraciones de proxy inverso que proveen de alta - disponibilidad, balanceo de carga, clustering basado en la nube y - reconfiguración dinámica en caliente.

- -

Ver: Guía de Proxy Inverso

-
-
- -
-
-

Idiomas disponibles:  en  | - es  | - fr  | - ja  | - ko  | - zh-cn 

-

How-To / Tutoriels

Langues Disponibles:  en  | + es  |  fr  |  ja  |  ko  | @@ -154,6 +155,7 @@

Langues Disponibles:  en  | + es  |  fr  |  ja  |  ko  | diff --git a/docs/manual/howto/index.html.ja.utf8 b/docs/manual/howto/index.html.ja.utf8 index a4cf0cf7df..b2def11fc4 100644 --- a/docs/manual/howto/index.html.ja.utf8 +++ b/docs/manual/howto/index.html.ja.utf8 @@ -24,6 +24,7 @@ Apache > HTTP サーバ > ドキュメンテーション > バージョン 2.5

How-To / チュートリアル

翻訳済み言語:  en  | + es  |  fr  |  ja  |  ko  | @@ -116,6 +117,7 @@

翻訳済み言語:  en  | + es  |  fr  |  ja  |  ko  | diff --git a/docs/manual/howto/index.html.ko.euc-kr b/docs/manual/howto/index.html.ko.euc-kr index 3c7adb5395..9a0887efba 100644 --- a/docs/manual/howto/index.html.ko.euc-kr +++ b/docs/manual/howto/index.html.ko.euc-kr @@ -24,6 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5

How-To / ÅõÅ丮¾ó

°¡´ÉÇÑ ¾ð¾î:  en  | + es  |  fr  |  ja  |  ko  | @@ -108,6 +109,7 @@

°¡´ÉÇÑ ¾ð¾î:  en  | + es  |  fr  |  ja  |  ko  | diff --git a/docs/manual/howto/index.html.zh-cn.utf8 b/docs/manual/howto/index.html.zh-cn.utf8 index 6f1f57566d..754b7c9637 100644 --- a/docs/manual/howto/index.html.zh-cn.utf8 +++ b/docs/manual/howto/index.html.zh-cn.utf8 @@ -24,6 +24,7 @@ Apache > HTTP 服务器 > 文档 > 版本 2.5

常见操作/教程

可用语言:  en  | + es  |  fr  |  ja  |  ko  | @@ -105,6 +106,7 @@

可用语言:  en  | + es  |  fr  |  ja  |  ko  |