将应用程序最终用户映射到数据库用户的每种方法有哪些优点？

将应用程序最终用户映射到数据库用户似乎有三种常用方法.

一对一映射: 每个应用程序用户(bob,nancy和fred)也获得相应的数据库用户帐户(bob nancy和fred).

N到M映射: 每个应用程序用户都映射到代表其角色的数据库用户.当fred映射到'manager'数据库用户时,bob和nancy映射到'clerk'数据库用户.

N到1映射: 每个应用程序用户都映射到单个数据库用户(app_user),并且只在应用程序层管理标识.

似乎#3是Web应用程序开发中最常见的. 为什么没有更加强调其他两个选项？

Oracle鼓励像#2这样的技术使用其代理身份验证功能,原因如下:

有限的信任模型 -控制代表中间层可以连接的用户,以及中间层可以为用户承担的角色

可扩展性 - 通过支持轻量级用户会话并消除重新验证客户端的开销

通过将真实用户的身份保存到数据库,并启用对代表真实用户采取的操作的审计来实现问责制

Oracle的代理身份验证文档

除了更简单的管理之外,Web服务器上的选项3还具有性能优势; 这允许连接池 - 即可以连续重复使用少量的物理数据库连接来为大量应用用户提供服务.这被称为" 可信子系统 "模型 - 即您的app-server验证外部呼叫者,但随后app-server本身被用作向下呼叫的身份.这里最大的问题是,对于审计等,您需要不断告诉数据库谁做出当前的更改(类似USER_NAME(),SUSER_SNAME()不再有用) - 当然,这相对容易欺骗.

如果Web服务器使用每个用户的安全性,则这是不可能的 - 因此您基本上必须禁用连接池.建立连接的行为(相对)昂贵,因此这将对性能产生重大影响.您不希望在请求之间保持(每用户)连接,因为这会导致巨大的池和大量打开的连接(也很昂贵).

它们之间的"每个角色"选项站点 - 但很少有角色真正互相排斥,这使得这很难实现.

对于直接与数据库通信的客户端应用程序,选项1是最简单的维护,因为您不需要将任何特殊帐户详细信息分发给客户端.池同样不是问题,因为客户端的机器仅充当1个用户.