基于Java的权限控制系统设计
【IT168 技术文档】
一、概要
通常,需要单独的权限系统是解决授权的管理和维护,再分配等难题,不针对开发而言。
系统架构目标:在易于理解和管理,开发的前提下,满足绝大部分粗粒度和细粒度权限控制的功能需要。
除了粗粒度权限,系统中必然还会包括无数对具体Instance的细粒度权限。这些问题,被留给对框架的扩展方法来解决,这样的考虑基于以下两点:
1、细粒度的权限判断必须要在资源上获取权限分配的支持的上下文信息才可能得以实现。
2、细粒度的权限常常具有相当大的业务逻辑相关性。对不同的业务逻辑,常常意味着完全不同的权限判定原则和策略。相比之下,粗粒度的权限更具通用性,将其实现为一个架构,更有重用价值;而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐,增加架构的复杂性。而且不是那么的有必要,用定制的代码来实现就更简洁,更灵活。否则会变成各种逻辑代码的堆砌。
比如,product post数量的控制,这种一般要知道用户个性化的信息,付钱数量到数据库中查找最高数量,还要知道此用户已经有多少产品等,规则不具备通用性和重用性,
所以细粒度控制不应该放在权限架构层来解决。实例级的细粒度权限的解决方案就是将它转化为粗粒度权限,这样我们权限客户端就变得很简单了。
名词解释
粗粒度权限:一般可以通过配置文件来授权,授权只有真假,没有多少之分,不需要上下文的支持。不消耗资源的。
逻辑表达式:判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。
别名:静态授权、类级授权
细粒度权限:不能通过配置文件等表达,需要特定上下文的支持.
逻辑表达式:判断“When(Where)的时候,Who对What(Which)进行How的操作”的逻辑表达式是否为真。
别名:动态授权、实例级授权
设计原则:框架只提供粗粒度的权限。细粒度的权限也需要集中管理和维护,细粒度的权限通过定制的扩展代码将细粒度转化为粗粒度授权。
一、概要
通常,需要单独的权限系统是解决授权的管理和维护,再分配等难题,不针对开发而言。
系统架构目标:在易于理解和管理,开发的前提下,满足绝大部分粗粒度和细粒度权限控制的功能需要。
除了粗粒度权限,系统中必然还会包括无数对具体Instance的细粒度权限。这些问题,被留给对框架的扩展方法来解决,这样的考虑基于以下两点:
1、细粒度的权限判断必须要在资源上获取权限分配的支持的上下文信息才可能得以实现。
2、细粒度的权限常常具有相当大的业务逻辑相关性。对不同的业务逻辑,常常意味着完全不同的权限判定原则和策略。相比之下,粗粒度的权限更具通用性,将其实现为一个架构,更有重用价值;而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐,增加架构的复杂性。而且不是那么的有必要,用定制的代码来实现就更简洁,更灵活。否则会变成各种逻辑代码的堆砌。
比如,product post数量的控制,这种一般要知道用户个性化的信息,付钱数量到数据库中查找最高数量,还要知道此用户已经有多少产品等,规则不具备通用性和重用性,
所以细粒度控制不应该放在权限架构层来解决。实例级的细粒度权限的解决方案就是将它转化为粗粒度权限,这样我们权限客户端就变得很简单了。
名词解释
粗粒度权限:一般可以通过配置文件来授权,授权只有真假,没有多少之分,不需要上下文的支持。不消耗资源的。
逻辑表达式:判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。
别名:静态授权、类级授权
细粒度权限:不能通过配置文件等表达,需要特定上下文的支持.
逻辑表达式:判断“When(Where)的时候,Who对What(Which)进行How的操作”的逻辑表达式是否为真。
别名:动态授权、实例级授权
设计原则:框架只提供粗粒度的权限。细粒度的权限也需要集中管理和维护,细粒度的权限通过定制的扩展代码将细粒度转化为粗粒度授权。
0
相关文章