涉及域逻辑的域安全 [英] Domain security involving domain logic
问题描述
与应用程序的域逻辑一起，我试图概述安全模型。我坚持要求阻止我将安全性视为对域逻辑的跨领域关注。这是我的情况。
Together with my application's domain logic I am trying to outline the security model. I am stuck with a requirement that prevents me from considering security just a cross-cutting concern over my domain logic. Here follows my situation.
系统中的用户可能会被允许创建某种对象，例如过滤器。我引入了一个称为 CREATE_FILTER的权限，并且该用户是否被允许创建过滤器，这取决于管理员是否向该用户分配了这种权限。好的。
A user in my system can potentially be allowed to create a certain kind of objects, say, 'filters'. I introduce a permission called 'CREATE_FILTER', and a user is either allowed to create filters or not, depending on whether the admin assigned such a permission to this user, or not. Ok.
现在，当用户可以创建的过滤器数量有限时，考虑一个更复杂的要求。因此，例如管理员应该能够设置允许任何用户创建的过滤器的最大数量，甚至更复杂，以便分别为用户分配最大数量，例如，将User1的值设为3，将User2的值设为5，依此类推。因此，为了向用户授权创建过滤器，安全系统不足以检查用户是否分配了这样的权限，而是必须以复杂的方式分析域模型以查看有多少个过滤器已经由用户创建来做出决定。为了使事情变得更复杂，我们可以想象最大限额将取决于用户在其帐户上的存款金额或其他。
Now consider a more complex requirement when the number of filters a user can create is limited. So, e.g. the admin should be able to set max number of filters any user is allowed to create, or even more complex, to assign max numbers individually to users, say value of 3 to User1, 5 to User2 and so on. So, the security system, in order to authorize filter creation to a user, is not sufficient to check whether a user has such a permission assigned, but has to analyze the domain model in a complex way in order to look how many filters there are already created by the user to make the decision. To make things more complex, we can imagine that the max limit will depend on the amount of money user has on their account, or something.
我想在概念上进行区分（至少在我看来），这样复杂的安全性逻辑是否纯粹与安全性有关（当然这将取决于域模型），或者这已经是域逻辑本身的完整部分了吗？在分配/删除权限无济于事时（因为其域状态取决于授权决定而不是分配的权限），保留权限概念是否有意义？例如，拥有一个复杂的许可概念是否会成为一种可行的方法，它不仅允许仅凭其存在的事实就允许某项行动，而是会涉及一些复杂的决策逻辑？
I want to conceptually separate (at least in my mind), whether such a complicated security logic purely pertains to security (which will of course depend on the domain model) or is this already a full-fledged part of the domain logic itself? Does it make sense to keep a 'permission' concept, when assigning/removing permissions does not help much (since it's domain state on which depends authorization decision rather than assigned permissions)? Would it be a way to go, say, to have a complicated permission concept which not simply allows an action by a mere fact of its existence but would rather involve some complex decision making logic?
推荐答案
这是您可以解决此问题的一种方法...
Here's one way you could handle this ...
一方面，您有一个安全模型（可能是ddd语音中的有限上下文）可以解决通过向角色（用户）分配权限的问题，这可能是通过使用角色间接实现的。我会设想上限（最大数字）是与分配的权限相关联的属性。
On one side you have a security model (might be a bounded context in ddd speak) that is solving the problem of assigning permissions to subjects (users), maybe indirectly through the use of roles. I would envision upper boundaries (max numbers) to be an attribute associated with the assigned permission.
该模型还有一个查询部分。但是，它只能回答简单的问题：
There's also a query part to this model. Yet, it can only answer "simple" questions:
- 此用户具有创建过滤器的权限吗？
- 该用户可以创建多少个过滤器？
有些人甚至会说此查询部分完全是一个单独的模型。
Some would even say this query part is a separate model altogether.
另一方面，除了用户John Doe只能创建3个过滤器这些讨厌的要求外，您的应用程序模型在很大程度上是安全性的。顺便说一句，在这一点上我们仍然是在谈论用户，而不是在这个特定用例中扮演特定角色的人，这令人怀疑。无论如何，回到我们如何将其分开的地方。假设我们有一个分层的方法，并且我们有一个前面带有授权服务的应用程序服务。授权服务的责任是回答以下问题：是否允许该用户执行此操作？是或否？如果答案是否定的，则停止处理。这是一个非常幼稚的版本（C＃）。
On the other end you have your application's model which is largely "security" free apart from these pesky requirements along the lines of "user John Doe can only create 3 filter". As an aside, it's doubtful we're still speaking of a "user" at this point, but rather of a person acting in a certain role in this particular use case. Anyway, back to how we could keep this somewhat separate. Suppose we have a somewhat layered approach and we have an application service with an authorization service in front. The responsibility of the authorization service is to answer the question "is this user allowed to perform this operation? yes or no?" and stop processing if the answer is no. Here's a very naive version of that (C#).
public class FilterAuthorizationServices :
Handles<CreateFilter>
{
public FilterAuthorizationServices(FilterRepository filterRepository) { ... }
public void Authorize(Subject subject, CreateFilter message)
{
if(!subject.HasPermissionTo("CreateFilter"))
{
throw new NotAuthorizedException("...");
}
if(filterRepository.CountFiltersCreatedBy(subject.Id) >
subject.GetTheMaximumNumberOfFiltersAllowedToCreate())
{
throw new NotAuthorizedException("...");
}
}
}
注意应用程序服务的方式这里甚至没有提到。它可以专注于调用实际的域逻辑。但是，授权服务同时使用上述模型的查询部分（由Subject体现）和应用程序的模型（由FilterRepository体现）来满足授权请求。这样做没什么问题。
Notice how the application service is not even mentioned here. It can concentrate on invoking the actual domain logic. Yet, the authorization service is using both the query part of the above model (embodied by the Subject) and the model of the application (embodied by the FilterRepository) to fulfill the authorization request. Nothing wrong with doing it this way.
如果该模型可以某种方式提供当前创建的数量，您甚至可以更进一步，放弃对应用程序模型的需求过滤器添加到安全模型。但这对您来说可能是一座桥梁，因为这将导致评估动态表达式的路径（不一定是一个不好的地方）。如果您想去那里，我建议您创建一个迷你DSL来定义所需的表达式和相关代码，以对其进行解析和评估。
You could even go a step further and ditch the need for the application's model if that model could somehow provide the "current number of created filters" to the security model. But that might be a bridge too far for you, since that would lead down the path of evaluating dynamic expressions (which wouldn't necessarily be a bad place to be in). If you want to go there, may I suggest you create a mini DSL to define the required expressions and associated code to parse and evaluate them.
如果您想经纪人授权，您可以查看类似XACML（ https：//www.oasis- open.org/committees/tc_home.php?wg_abbrev=xacml ），尽管您必须首先克服对XML的恐惧；-）
If you'd like brokered authorization you could look at something like XACML (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml) though you'll have to overcome your fear of XML first ;-)
这篇关于涉及域逻辑的域安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
