Escolha da abordagem de autenticação para aplicativo financeiro no PostgreSQL

Acho que você está confundindo autenticação e autorização .

Concordo plenamente que é sensato manter o modelo de segurança no banco de dados, especialmente porque o LedgerSMB foi projetado tendo em mente o acesso de vários clientes. A menos que você planeje usar 3 camadas com uma camada de middleware, faz todo o sentido ter usuários como funções de banco de dados, especialmente para algo como um aplicativo de contabilidade.

Isso não significa que você precisa autenticar os usuários no banco de dados usando um método de autenticação suportado pelo PostgreSQL. Seus usuários de banco de dados, funções e concessões podem ser usados ​​para autorização somente se você quiser.

Veja como funciona para uma interface do usuário da web, por exemplo:

• janeconecta-se ao servidor web ui e autentica usando qualquer método desejado, por exemplo, handshake de certificado de cliente HTTPS X.509 e autenticação DIGEST. O servidor agora tem uma conexão de um usuário que ele aceita é realmente jane.

• O servidor se conecta ao PostgreSQL usando um nome de usuário/senha fixo (ou Kerberos ou o que você quiser), autenticando-se no servidor db como o usuário webui. O servidor db confia webuipara autenticar seus usuários, portanto webui, recebeu GRANTs apropriados (veja abaixo).

• Nessa conexão o servidor usa SET ROLE jane;para assumir o nível de autorização do usuário jane. Até que RESET ROLE;ou outro SET ROLEseja executado, a conexão está operando com os mesmos direitos de acesso que janee SELECT current_user()etc reportará jane.

• O servidor mantém a associação entre a conexão do banco de dados em que se encontra SET ROLEe janea sessão web do usuário jane, não permitindo que essa conexão PostgreSQL seja utilizada por outras conexões com outros usuários sem um novo SET ROLEmeio.

Agora você está autenticando fora do servidor, mas mantendo a autorização no servidor. Pg precisa saber quais usuários existem, mas não precisa de senhas ou métodos de autenticação para eles.

Ver:

• SET SESSION AUTHORIZATION
• SET ROLE
• GRANT

Detalhes

O servidor webui controla a execução das consultas e não permite a janeexecução de SQL bruto (espero!), Portanto jane, não pode ser feito RESET ROLE; SET ROLE special_admin_user;pela interface do usuário da web. Para maior segurança, eu adicionaria um filtro de instrução ao servidor que rejeitou SET ROLEe RESET ROLE, a menos que a conexão estivesse ou entrasse em um pool de conexões não atribuídas.

Você ainda está livre para usar autenticação direta para Pg em outros clientes; você pode misturar e combinar livremente. Você apenas tem que dar GRANTao webuiusuário os direitos de SET ROLEusuários que podem fazer login via web e, em seguida, dar a esses usuários quaisquer CONNECTdireitos normais, senhas, etc. que desejar. Se você quiser torná-los apenas na web, REVOKEseus CONNECTdireitos no banco de dados (e de public).

Para facilitar essa divisão de autenticação/autorização, tenho uma função especial para assume_any_usercada GRANTusuário recém-criado. Em seguida, chego GRANT assume_any_userao nome de usuário real usado por coisas como um front-end da Web confiável, dando a eles o direito de se tornarem qualquer usuário que desejarem.

É importante criar assume_any_useruma NOINHERITfunção, para que o webuiusuário ou o que quer que seja não tenha privilégios próprios e só possa atuar no banco de dados quando for SET ROLEpara um usuário real. Sob nenhuma circunstância deve webuiser um superusuário ou proprietário do banco de dados .

Se você estiver fazendo um pool de conexões, poderá usar SET LOCAL ROLEpara definir a função somente dentro de uma transação, para que possa retornar as conexões ao pool após COMMITou ROLLBACK. Cuidado, isso RESET ROLEainda funciona, então ainda não é seguro deixar o cliente executar qualquer SQL que desejar.

SET SESSION AUTHORIZATIONé a versão relacionada, mas mais forte deste comando. Não requer associação de função, mas é um comando apenas de superusuário. Você não deseja que sua interface do usuário da web se conecte como um superusuário. Ele pode ser revertido com RESET SESSION AUTHORIZATION, SET SESSION AUTHORIZATION DEFAULTou SET SESSION AUTHORIZATION theusernamepara recuperar os direitos de superusuário, para que também não seja uma barreira de segurança que reduza os privilégios.

Um comando que funcionasse como SET SESSION AUTHORIZATION, mas fosse irreversível e funcionaria se você fosse um membro da função, mas não um superusuário, seria ótimo. Neste ponto, não há um, mas você ainda pode separar autenticação e autorização muito bem se for cuidadoso.

Exemplo e explicação

CREATE ROLE dbowner NOLOGIN;
CREATE TABLE test_table(x text);
INSERT INTO test_table(x) VALUES ('bork');
ALTER TABLE test_table OWNER TO dbowner;

CREATE ROLE assume_any_user NOINHERIT NOLOGIN;
CREATE ROLE webui LOGIN PASSWORD 'somepw' IN ROLE assume_any_user;

CREATE ROLE jane LOGIN PASSWORD 'somepw';
GRANT jane TO assume_any_user;
GRANT ALL ON TABLE test_table TO jane;

CREATE ROLE jim LOGIN PASSWORD 'somepw';
GRANT jim TO assume_any_user;

Agora conecte como webui. Observe que você não pode fazer nada, test_tablemas pode e , SET ROLEem seguida , pode acessar :janetest_table

$ psql -h 127.0.0.1 -U webui regress
Password for user webui:

regress=> SELECT session_user, current_user;
 session_user | current_user 
--------------+--------------
 webui        | webui
(1 row)



regress=> SELECT * FROM test_table;
ERROR:  permission denied for relation test_table

regress=> SET ROLE jane;
SET

regress=> SELECT session_user, current_user;
 session_user | current_user 
--------------+--------------
 webui        | jane
(1 row)

regress=> SELECT * FROM test_table;
  x   
------
 bork
(1 row)

Observe que pode webui , mesmo quando já foi dado e mesmo que não tenha sido autorizado a assumir a função . define seu ID de usuário efetivo, mas não remove sua capacidade de outras funções, isso é uma propriedade da função à qual você se conectou, não sua função efetiva atual. Conseqüentemente, você deve controlar cuidadosamente o acesso aos comandos e . Não há, AFAIK, nenhuma maneira de obter uma conexão permanente , tornando-se verdadeiramente o usuário-alvo, embora certamente seja bom ter.SET ROLEjimSET ROLEjanejaneGRANTjimSET ROLESET ROLESET ROLERESET ROLESET ROLE

Comparar:

$ psql -h 127.0.0.1 -U webui regress
Password for user webui:

regress=> SET ROLE jane;
SET

regress=> SET ROLE jim;
SET
regress=> SELECT session_user, current_user;
 session_user | current_user 
--------------+--------------
 webui        | jim
(1 row)

para:

$ psql -h 127.0.0.1 -U jane regress
Password for user jane:

regress=> SET ROLE webui;
ERROR:  permission denied to set role "webui"
regress=> SET ROLE jim;
ERROR:  permission denied to set role "jim"

Isso significa que SET ROLEnão é exatamente o mesmo que fazer login como uma determinada função, algo que você deve ter em mente.

webuinão pode SET ROLE, dbownerpois não foi GRANTeditado corretamente:

regress=> SET ROLE dbowner;
ERROR:  permission denied to set role "dbowner"

portanto, por si só, é bastante impotente, só pode assumir os direitos de outros usuários e somente quando esses usuários tiverem acesso à web ativado.