L'article auquel vous avez lié pourrait être utilisé pour cela, mais il y a quelques mises en garde.
La réauthentification du serveur d'applications en tant qu'utilisateur différent de Kerberos n'est probablement pas réaliste. De ma connaissance de Kerberos (certes limitée), il est conçu de telle sorte que l'interaction de l'utilisateur final est nécessaire pour effectuer une authentification. L'utilisateur fait la poignée de main avec le serveur d'application sur HTTP - il n'y a pas vraiment un mécanisme pour leur demander de s'authentifier de nouveau avec la base de données elle-même. Toutefois, vous pouvez utiliser leurs hooks pour envoyer des commandes "SET SESSION AUTHORIZATION TO ..." à PostgreSQL si votre serveur d'applications effectue ses connexions à la base de données en tant que superutilisateur. Cela ne ré-authentifie pas réellement, change juste le rôle d'autorisation de session temporairement. Vous pouvez également utiliser l'une des innombrables solutions «stocker des informations de session dans la base de données» (variables personnalisées, variables globales PL/Perl, etc.) et utiliser leurs crochets pour travailler avec. C'est en fait ce que leur solution Oracle semble faire, il définit l'identifiant client qui est juste une variable globale dans dbms_util quelque part qui est inclus dans les vues montrant les sessions en cours (et postgresql 9.0 a un "nom d'application" qui joue le même rôle)