Autenticación del Cliente

Los usuarios permitidos para el establecimiento de la conexión a la base de datos son controlados por un archivo sencillo en el directorio raíz de su base de datos, llamado pg_hba.conf. En cuanto corre initdb para la creación del clúster de la base de datos, es creado un fichero pg_hba.conf con los valores por omisión.
Los permisos que existen por omisión dependen de cómo fue invocado initdb. Por omisión, los nuevos clústers son creados con el tipo trust con el cual, cualquier usuario local puede conectarse a la base de datos. Sin embargo, algunos empaquetadores de PostgreSQL pueden cambiar esto. Por ejemplo, si usa 'service initdb' en Red Hat para crear el clúster, éste llama a initdb de la siguiente manera:
 initdb --pgdata='$PGDATA' --auth= 'ident sameuser'
El cual usa el no particularmente popular método ident para averiguar si un usuario está permitido conectarse, lo cual suele ser frustrante para quienes no son conscientes de ello.
Una instalación típica recomendada para el acceso desde la red de la base de datos toma la dirección local LAN y sólo permite los clientes que se autentiquen usando una contraseña encriptada a través de MD5. La siguiente entrada en en el pg_hba.conf ilustrará algo como esto:
 # TIPO BASE_DE_DATOS USUARIO CIDR-DIRECCIÓN MÉTODO
 host all all 192.168.1.0/24 md5
Esto sólo permite conectarse a los clientes con las direcciones IP de la red 192.168.1.0 -- 192.168.1.255 y sólo si proveen la contraseña correcta para el usuario. Observe que un acceso de la red como éste puede establecerse sólo si está permitido en el parámetro listen_addresses de postgresql.conf.
Las contraseñas de los usuarios de la base de datos son aplicadas cuando se crea el usuario con 
CREATE ROLE y pueden ser modificadas con la orden ALTER ROLE. createuser puede ser una herramienta muy útil para ayudar en este sentido.
Hay una pequeña trampa aquí: puesto que para la creación de un nuevo rol se requiere que la conexión a la base de datos sea como un superusario, ¿cómo se pueden empezar a crear usuarios? Un enfoque común es comenzar con un pg_hba.conf que confía sólo a los usuarios que se conectan localmente:
 # Sólo conexiones locales para el socket de Unix
 local all all trust
 # IPv4 local connections:
 host all all 127.0.0.1/32 trust
Si la base de datos está configurada de esta forma, cualquiera logueado en el sistema puede ahora conectarse al servidor a su voluntad, así que no desea conservar esta configuración por mucho tiempo. Lo que puede hacer ahora es usar la orden ALTER ROLE para asignar una contraseña fuerte al superusuario postgres. Una vez que lo haya hecho, puede detener el servicio (pg_ctl stop), cambiar todos los "trust" por "md5", agregar su rango o bloque de red completo a pg_hba.conf, y cambiar el parámetro listen_address de postgresql.conf. Cuando lo inicie nuevamente, ya tendrá una cuenta de superusuario de la cual conoce la contraseña, con la cual puede crear las cuentas para sus usuarios regulares.
=== Ejemplos ===
==== Ejemplo 1 ====
Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde el ordenador con IP 10.0.0.100, y método de autentificación md5:
 host test001 test 10.0.0.100 255.255.255.255 md5
Esta misma entrada se podría escribir también con la máscara de red en notación CIDR:
 host test001 test 10.0.0.100/32 md5
==== Ejemplo 2 ====
Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde todos los ordenadores de la red 10.0.0.0, con mascara de red 255.255.255.0 (254 ordenadores en total) y método de autentificación md5:
 host test001 test 10.0.0.0 255.255.255.0 md5
Esta misma entrada se podría escribir también con la mascara de red en notación CIDR:
 host test001 test 10.0.0.0/24 md5
==== Ejemplo 3 ====
Acceso por tcp/ip (red), encríptado, a todas las bases de datos de nuestro cluster, como usuario test desde el ordenador con IP 10.0.0.100, y el ordenador 10.1.1.100 y método de autentificación md5 (necesitamos dos entradas en nuestro fichero pg_hba.conf):
 hostssl all test 10.0.0.100 255.255.255.255 md5
 hostssl all test 10.1.1.100 255.255.255.255 md5
==== Ejemplo 4 ====
Denegar el acceso a todos las bases de datos de nuestro cluster al usuario test, desde todos los ordenadores de la red 10.0.0.0/24 y dar acceso al resto del mundo con el método md5:
 host all test 10.0.0.0/24 reject
 host all all 0.0.0.0/0 md5
=== Autenticación LDAP===
Postgresql nos permite comprobar los usuarios contra un sistema LDAP, aunque si bien esto es posible, hay que tener en cuenta que el usuario igualmente debe existir en la base datos.
Parámetros que hay que considerar al realizar una petición de autenticación a un servidor de LDAP:
 Parámetros 	Descripción
 ldapserver 	IP o dominio del servidor ldap a conectarse.
 ldapprefix 	El nombre de usuario.
 ldapsuffix 	El sufijo que continua al nombre de usuario, que concluiría para formar el “dn”.
 ldapport 	Puerto al que se va a conectar al servidor ldap, en caso de no ser especificado se utiliza el
 puerto por default, 389.
 ldaptls 	Debe setearse en 1 si se quiere que la petición de autenticación hacia el servidor ldap se
 realize utilizando encriptación TLS.
Ejemplo del uso de la autenticación LDAP:
host all all 127.0.0.1/24 ldap ldapserver="localhost" ldapprefix="uid=" ldapsuffix=",dn=testing-et,dc=com,dc=cu"
===Artículos relacionados===
* PostgreSQL y pam_ldap por Adrian Nida
* Autenticación NSS con libnss_pgsql por David Ford
* Autenticando Clientes PostgreSQL por SecurityProNews (2002-05-21)
* Autenticación LDAP contra AD (en inglés) por Joey Wang (2007-04-13)
Category:Español