如果您询问一般架构或最佳实践问题,我建议您查看基于声明的身份验证。特别是Active Directory 联合身份验证服务(ADFS)。
基本上,您似乎需要比仅基于组更精细地控制用户可以执行的操作。组成员有时可能非常广泛。例如,并非“用户”中的每个人都可能具有相同的权限,“销售”中的每个人都不会具有相同的访问权限。但是,您不想创建诸如“销售 - 经理”、“销售 - 员工”、“销售 - 高管”等组。这很快就会变得笨拙。而且,无论您花多少时间来设计完美的组分配,几年后一切都会改变,因为某些销售经理将被允许做一些其他销售经理不能做的事情。
为了解决这个问题,使用了基于声明的身份验证。无需在组成员级别指定权限,您只需在代码中检查用户是否具有特定的“声明”。您可以发疯并创建对您的应用程序有意义的尽可能多的声明。您可以提出“可以更改出生日期”、“可以授权支付超过 1000 美元”等声明。
声明仅附加到您的用户身份,可通过线程的当前原则获得。
现在,如何为用户分配您询问的这些“声明”?好吧,如果您使用的是 ADFS,无论如何都可以。您显然可以根据 AD 组成员身份进行操作。您可以根据数据库查找来执行此操作。如果您愿意,您可以在一天中的某个时间或一年中的某个月份执行此操作。
关键是,现在您的索赔签发和索赔执行是完全独立的,可以独立更改而不会相互影响。你的代码只是说“嘿,这个人有一个索赔,让他支付超过 1000 美元,所以我会让他这样做。为什么他有这个索赔,我不知道也不关心”。然后,您的 ADFS 可以根据它认为合适的任何标准发出声明。例如“如果用户是 Managers 组的成员,或者在安全数据库的 SuperUsers 表中有一个条目,或者被命名为 'Tim Timsky',则允许他花费超过 1000 美元”
因此,要回答您关于“仅在限制我的选择的群体层面上思考”的问题,当然不必这样做。如果您正在开始一个新的绿地项目,ADFS 等新工具会更轻松地为您提供很多选择。
但当然它有一个警告,那就是所有抽象都以增加复杂性为代价。这是您要引入系统的另一部分。您可以解耦您的应用程序并引入更高层的抽象和功能。但是该层是否值得引入取决于您计划如何使用该应用程序。如果您认为应用程序永远不必区分“管理器”和“用户”,那么基于声明的身份验证就太过分了。但是,如果您觉得随着时间的推移,您的应用程序中将有不同的点点滴滴的功能需要根据模糊且不断变化的规则分配给不同的用户,那么基于声明的身份验证将使您的解决方案更加整洁。
与往常一样,将两个部分解耦的净优势取决于一个独立于另一个而变化的频率。