首先介绍一下背景。
LedgerSMB 项目是一个在 PostgreSQL 上运行的开源财务会计软件项目。我们在用户定义的函数中实现了大量的业务逻辑，它们充当程序对象方法和数据库行为之间的主要映射工具。目前我们使用数据库用户作为身份验证用户，部分是出于选择（这允许集中的安全逻辑，以便可以编写其他工具并重用授予用户的权限），部分是必要的（在我们从 SQL-Ledger 分叉之后，有用于在该代码库上改进安全性的选项并不多）。
这让我们可以访问 PostgreSQL 可以访问的合理数量的单点登录选项，从 LDAP 到 Kerberos 5。我们甚至可以在涉及密码的地方使用 PAM。它还允许我们在与其他应用程序集成或允许其他客户端界面时重用权限。对于财务会计应用程序来说，这似乎是一场胜利。
有明显的成本。对于 Web 应用程序，我们可以支持的 http 身份验证类型非常有限。例如，DIGEST 完全出局了。BASIC 可以工作，我们可以很容易地实现 KRB5（我计划支持它并在 1.4 中开箱即用）。非常强大的身份验证措施无法直接对此进行适当管理，尽管我们可能会在必要时将它们填充（例如 BASIC + 客户端 SSL 证书，其 cn 与用户名和特定的根 ca 匹配）。
与此同时，我们遇到了相当多的批评，主要来自开发人员，偶尔来自 dba 的批评，他们告诉我应用程序应该是安全屏障，而不是数据库。我的观点仍然是，较小的安全边界通常更好，业务逻辑和安全逻辑的重用是相辅相成的，我觉得重用业务逻辑而不在同一级别重用安全逻辑是危险的的程序。
我在这里错过了任何主要的权衡吗？有没有我没有考虑的问题？