我对技术困境感到困惑，我们团队中的两个人推荐了两种不同的安全模型，每种模式各有利弊。
绿地看起来像这样： 我们有一个asp.net Web应用程序，与业务层交谈，与数据库通信。
*其中一个要求是能够让更高级别的用户将业务层权限委派给其他用户。
其中一个人正在游说互联网用户将他们的凭证一直传递到数据库的能力，以便连接可以使用实际的sqlserver帐户进行查询等。（我喜欢的一些方面 - 审计例如）
现有的替代方法是简单地使用数据库中的用户套件，密码，角色，资源表，并在业务层中管理安全性。
可能是因为我来自java到oracle背景，在大多数情况下，您使用连接池提供已使用服务类型帐户进行身份验证的连接。我们的互联网客户从未拥有实际的数据库帐户。
我认为在mssql服务器提供的内置凭证存储中管理可委托的安全性（由互联网用户）似乎充满了危险的安全性，我是否存在缺陷？
有人有任何建议吗？
答案 0 :(得分：2)
您可以拥有潜在用户，以及这些用户可以立即使用哪些用户？
例如，如果您有100,000个用户，并且数千个可以一次联机，那么您将需要打开1000个数据库连接才能为所有用户提供服务，因为每个用户只能使用自己的连接。为每个事务设置和拆除连接非常昂贵，并且会使应用程序变慢。
就个人而言，我会选择连接池，并且每个互联网用户都没有数据库用户帐户。这就是通常构建Web应用程序的方式。
Oracle细粒度访问控制之类的东西可能会为您提供安全的中间立场，您可以在会话中设置“互联网用户”，然后数据库确保互联网用户只能根据规则访问允许的内容。数据库。
答案 1 :(得分：2)
在大多数Web应用程序中，安全模型是在业务逻辑层定义的，而不是数据层。
例如，我在Stack Overflow上编辑帖子的能力不受我读/写“posts”表的能力控制 - 事实上，你甚至可能没有设计一个允许你实现的数据库模式此级别的数据库级安全性。相反，有一个业务逻辑层，它将我的权限与我想要采取的行动进行比较（我假设）;安全性在业务逻辑层实现。
我坦率地看到将凭证传递到数据库层几乎没有任何好处 - 如果不知何故我绕过了控制谁可以编辑SO帖子的业务逻辑，数据库“读/写”控件不会阻止它，并且审计对你没有帮助。
我看到了很多缺点 - 尤其是你将授权逻辑分成两个（业务逻辑和数据库），并引入各种娱乐失败模式，同时在业务逻辑层和数据库层同步帐户（用户更改密码或离开网站）。我无法想象你是如何仔细测试和调试所有这些 - 如果最终用户收到与其数据库权限相关的错误会发生什么？