安全难道不是一个横切的问题吗？

Question

我正在从事一个具有非常详细的安全要求的项目。老实说，如果提议的模式与任何情报/安全机构一样复杂，我也不会感到惊讶。现在，我已经读到，将安全性与业务逻辑结合起来是关注点的混合，因此是要避免的做法。

然而，所有抽象安全性的尝试都失败了，或者造成了像以前一样混乱的“抽象”。安全性是否可能如此具体以至于成为业务规则的一部分？在某些违反安全的情况下，只隐藏数据，而在其他情况下，则会终止会话，而在其他情况下，则会触发默认值以供使用。这是许多符合安全要求的要求。

我的基本问题是:我是否可以在一个特殊的情况下(即合并安全性是健全的)，还是我不理解抽象安全性的一些基本内容？

编辑：

tl;dr (就我所理解的答案而言)：身份验证(您是谁)在很大程度上是一个横切的关注点，应该进行抽象，而授权(您可以做什么)是业务逻辑。由于缺乏这种词汇，而且只有“安全”一词(或者可能无法理解两者之间的区别)，这就导致了我的困惑。

Answer 1

安全性分为两部分:身份验证和授权。身份验证是一个非常具体的用例。如何从一组不受信任的用户中确定用户是可信的。我认为这是横切的；您需要将未经身份验证的用户排除在您的系统或系统的一个子集之外。

授权(用户可以做某事)在很大程度上是一条业务规则。它可以(而且经常)非常具体，并且与每个用例不同。谁来决定什么角色能做什么？嗯，生意上有。没人能替你回答这个问题。

在Csla.Net 4框架中，这正是授权的处理方式；作为一种专门的业务规则。您甚至不限于“用户在角色”或“用户有权限”。您可以制定更复杂的规则“如果工作流步骤尚未超过此特定步骤，用户可以编辑此字段。”

Answer 2

我想一个例外的情况是，如果您的业务逻辑是某种类型的安全服务，那么是的。但是，我认为您的问题可能是您混淆了用户授权和身份验证。

当然，身份验证应该有一组与它相关的规则，但是最终的结果应该是识别用户和创建会话。

授权将与我们确定用户角色的权限以及该角色规定的权限分开。

典型的示例是，身份验证返回一个用户对象并将其存储在会话中。用户有1到多个角色。一个角色可能拥有1到多个特权。业务逻辑方法可能是sendEmail。此方法查询用户对象是否具有特定特权，如果存在，请执行某些操作，如果不执行其他操作，则执行其他操作。

编辑:在我看来，当涉及到用户时，安全性应该始终是一个横切的关注点，但是，如果您的业务逻辑涉及非用户对象的属性、这些对象的CRUD或管理其他用户，那么它就符合您的业务需求，因此也就是业务逻辑。