O seguinte parece ser uma situação bastante comum, mas não vi nenhuma solução.
Eu tenho um banco de dados PostgreSQL contendo exibições específicas para o $user
, a fim de restringir os dados dependendo de alguma lógica ACL específica do banco de dados. O banco de dados é normalmente acessado por meio de JDBC e, em particular, em JSP para uma interface da web. Os usuários fazem login no site com autenticação de senha usando LDAP.
O que eu gostaria é de usar as visualizações de dentro da conexão JDBC com o banco de dados. Mas normalmente essa conexão intermediária é criada usando um usuário genérico, e não específico para a pessoa conectada ao site. Acredito que no Oracle a abordagem "correta" seja Proxy Authentication , mas AFAIAA não há equivalente para PostgreSQL. Então, o que fazer em vez disso?
Algumas ideias vêm à mente:
- Dê a todas as contas de banco de dados dos usuários a mesma senha e, em seguida, crie uma conexão JDBC específica do usuário usando essa senha genérica (isso parece tão errado ...)
- Armazene a senha de login do usuário em algum lugar do site, para reutilizar ao criar uma conexão de banco de dados (novamente, isso parece muito errado)
Alguma outra sugestão (espero que melhor)?
A solução usual é autenticar o usuário no aplicativo da web e, em seguida, emitir um
SET ROLE
ouSET SESSION AUTHORIZATION
"tornar-se" o usuário em uma sessão JDBC que já está autenticada com o banco de dados usando um nome de usuário fixo.Em ambos os casos, o
DISCARD ALL
comando que deve ser executado por qualquer pool de conexão ao retornar conexões ao pool redefinirá automaticamente a autorização. Certifique-se de que seu pool de conexões seja executadoDISCARD ALL
em conexões retornadas .Estes são muito parecidos com o primeiro dos três casos de "autenticação de proxy" fornecidos no documento Oracle vinculado.
O PostgreSQL não suporta as outras duas formas, onde a autenticação do cliente é passada para o banco de dados. Seria relativamente simples de apoiar, mas ninguém o queria o suficiente para implementá-lo ou financiar o trabalho necessário para que outra pessoa o implementasse.
SET ROLE
Para usar
SET ROLE
, você deve se conectar ao banco de dados como um usuário que tenha participação em todas as funções de usuário, mas o usuário pode não ter privilégios. O usuário do banco de dados deve ter aNOINHERIT
opção definida comALTER ROLE
ou atCREATE ROLE
time. Então, você normalmente cria usuários do webapp como funções de banco de dados das quais o usuário do webapp é membro, por exemplo(O
ROLE mywebapp
é equivalente a executar um subseqüenteGRANT newusername TO mywebappuser;
).SET SESSION AUTHORIZATION
Para usar
SET SESSION AUTHORIZATION
, você deve se conectar como superusuário, o que geralmente é indesejável, pois dá controle total ao usuário do webapp.Ao contrário
SET ROLE
, não há nenhum requisito para associações de grupo.