|
New feature to add scram and cert authentication method support in Pgpool-II.
Apart from supporting the new authentication methods the commit also includes
the following enhancements and changes in the authentication framework
of Pgpool-II
Different auth methods for frontend and backend for user session
================================================================
Now it possible to use different authentication method for client
application and backend PostgreSQL servers.
For example, a client application can use scram-sha-256 to connect to Pgpool-II
which in turn can use trust or md5 authentication to connect to
PostgreSQL backend for the same session.
Use MD5 and SCRAM without pool_passwd
=====================================
New configuration parameter allow_clear_text_frontend_auth, enables the Pgpool-II
to use clear-text-password authentication with frontend clients when pool_passwd
file does not contains the password for the connecting user.
For example: suppose PostgreSQL servers has a user named "some_user" which can
connect to database using SCRAM authentication, Now for this "some_user" to
connect to PostgreSQL using SCRAM through Pgpool-II we must have the some_user's
password stored in the pool_passwd file, but if in some case when pool_passwd does
not have the entry of "some_user" and allow_clear_text_frontend_auth is enabled
in the pgpool.conf then Pgpool-II will ask the connecting frontend to use
clear-text-password auth method for authentication, and after receiving the
password from the client, Pgpool-II will use that password to authenticate with
backend using the required SCRAM auth.
Note: allow_clear_text_frontend_auth only works when pool_hba.conf is not enabled.
Encrypted passwords in pool_passwd file
=======================================
Since the SCRAM authentication method explicitly guards against the
man-in-middle type attacks, so to use such authentication methods Pgpool-II
requires the PostgreSQL user password to authenticate with the backend.
But as storing the clear text password in the "pool_passwd" file is never a good
idea, so now you can store the AES256-CBC encrypted password in the "pool_passwd".
To store the AES encrypted password in the "pool_passwd" the password is first
encrypted using the AES256 encryption with the user provided key and then the
encrypted password is base64 encoded and AES prefix is added to
the encoded string.
New pg_enc utility to create encrypted passwords
================================================
A new utility pg_enc is added to create AES encrypted passwords. The utility
works similar in most ways as pg_md5 utility, with a some small differences,
pg_enc also requires the key for encrypting the password entries. later that
same key is required by Pgpool-II to decrypt the passwords to be used for
authentication.
Note: Pgpool-II must be build with ssl (--with-openssl) support to use
this encrypted password feature.
Providing encryption key to Pgpool-II
=====================================
If you have AES encrypted passwords stored in the pool_passwd file, then
Pgpool-II will require the decryption key to decrypt the passwords before
using them, Pgpool-II tries to read the decryption key at startup from
the pgpoolkey file.
By default the Pgpool-II will look for the pgpoolkey file in user's home
directory or the file referenced by environment variable PGPOOLKEYFILE.
You can also specify the key file using the (-k, --key-file=KEY_FILE)
command line argument to the Pgpool-II binary.
Encrypted Passwords in pgpool.conf
==================================
The commit also allows to specify the AES encrypted password in the pgpool.conf
file for healh_check_user, sr_check_user, wd_lifecheck_user and recovery_user
users, Additionally if the password field for any of these users is left blank
in pgpool conf then Pgpool-II will first try to get the password for that user
from pool_passwd file before using the empty password for the connection.
So now pgpool.conf can be made password free and single pool_passwd file can be
used to store all passwords for internal and external user connection
Documentation updates and regression test cases for the
feature are also part of the commit.
Thanks to jesperpedersen <jesper.pedersen@redhat.com> for helping
in documentation and testing for the feature
|
