我正在开发一个具有非常详细的安全要求的项目。如果提议的模型与任何情报/安全机构一样复杂，我真的不会感到惊讶。现在我已经读到，将安全性与业务逻辑结合起来是一种混合的关注点，因此需要避免这种做法。
但是，所有抽象安全性的尝试要么失败，要么像以前一样创建“抽象”。安全性是否可能如此具体，以至于成为业务规则的一部分？在某些违反安全性的情况下，仅屏蔽数据，而在其他情况下将终止会话，而在其他情况下，它将触发要使用的默认值。有许多要求可以满足安全要求。
我的基本问题是：我是否可能处于特殊情况（即合并安全性的情况）或者我不了解抽象安全的基本情况？
修改
tl; dr（我理解他们的答案）：身份验证（你是谁）是一个跨领域的问题，应该被抽象，而授权（你能做什么）是业务逻辑。缺乏这种词汇，只有“安全”一词（或者可能没有理解两者之间的区别）导致我的困惑。
答案 0 :(得分：2)
我认为，如果您的业务逻辑是某种安全服务，则会出现例外情况。但是我认为您的问题可能是您将用户授权与身份验证混淆。
当然，身份验证应该有一组与之关联的规则，但最终结果应该是，识别用户和创建会话。
授权将与我们确定用户角色以及该角色布置的权限分开。
典型的示例是Authentication返回User对象并将其存储在会话中。用户有1到多个角色。角色可能具有1到多个权限。业务逻辑方法可能是sendEmail。此方法向User对象查询特定权限，如果存在则执行某些操作，如果不执行其他操作。
编辑：在我看来，安全性应始终是用户的一个交叉问题，但是如果您的业务逻辑涉及非用户的对象属性，这些对象的CRUD或管理其他用户，那么它就会崩溃符合您的业务需求，因此是业务逻辑。
答案 1 :(得分：2)
安全分为两部分;身份验证和授权。身份验证是一个非常具体的用例。如何确定用户是否受到一组不受信任的用户的信任。我认为这是跨领域的;您需要将未经身份验证的用户保留在系统或系统的一部分之外。
授权（用户可以做某事）是一项非常商业规则。它可以（并且经常是）非常具体和不同的每个用例。谁决定哪些角色可以做什么？嗯，业务确实如此。没有人可以为你回答这个问题。
在Csla.Net 4框架中，这正是授权的处理方式;作为一项专门的商业规则。您甚至不限于“用户在角色中”或“用户有权限”。您可以制定更复杂的规则“如果工作流程步骤尚未超过此特定步骤，则用户可以编辑此字段。”