Sle*_*led 7 architecture security
我正在开发一个具有非常详细的安全要求的项目.如果提议的模型与任何情报/安全机构一样复杂,我真的不会感到惊讶.现在我已经读过,将安全性与业务逻辑结合起来是一种混合的关注点,因此需要避免这种做法.
然而,所有抽象安全性的尝试要么失败,要么像以前一样创建"抽象".安全性是否可能如此具体以至于它成为业务规则的一部分？在某些违反安全性的情况下,仅屏蔽数据,而在其他情况下将终止会话,而在其他情况下,它将触发要使用的默认值.有许多要求可以满足安全要求.
我的基本问题是:我是否可能处于特殊情况(即合并安全性的情况)或者我不了解抽象安全性的基本内容？
编辑:
tl; dr(我理解他们的答案):身份验证(你是谁)是一个跨领域的问题,应该被抽象,而授权(你能做什么)是业务逻辑.缺乏这种词汇,只有"安全"一词(或者可能没有理解两者之间的区别)导致我的困惑.
安全性分为两部分；身份验证和授权。身份验证是一个非常具体的用例。如何从一组不受信任的用户中确定某个用户是受信任的。我认为这是交叉的；您需要将未经身份验证的用户排除在您的系统或系统的子集之外。
授权（用户可以做某事）在很大程度上是一项业务规则。对于每个用例来说，它可以（而且通常）非常具体且不同。谁决定哪些角色可以做什么？嗯，生意确实如此。没有人能为你回答这个问题。
在 Csla.Net 4 框架中，这正是处理授权的方式；作为专门的业务规则。您甚至不限于“用户处于角色”或“用户拥有权限”。您可以制定更复杂的规则“如果工作流程步骤尚未超过此特定步骤，用户可以编辑此字段”。
| 归档时间： |
|
| 查看次数： |
758 次 |
| 最近记录： |