基于SSM框架的通用权限框架设计

Posted 李慕白

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了基于SSM框架的通用权限框架设计相关的知识,希望对你有一定的参考价值。

 1. 整体解决方案概述

   1.1 权限整体解决方案概述

    权限设计主要有一下几大部分组成:
     PassPort

   
针对现在系统的分析,系统之间有部分信息是共享的,这部分信息将由中心话的Passport来统一维护

   权限订阅模块:
   
负责订阅接受Passport发出的相关实体修改的信息。
   
资源权限绑定:
   
有效的将资源-角色--成员在
数据库中简历绑定。
   
数据权限高速内存数据缓存:
   
将数据权限相关的数据缓存在内存,提供高性能访问能力。
   Struts
页面权限过滤和绑定:
   
使用Strutstag动态根据资源权限的设置,决定页面中资源(按钮,菜单,URL,页面元素)的访问能力。
   
数据权限过滤:
   
根据数据过滤权限的特定,定义的数据权限过滤的通用数据结构
   
根据业务集成和整合的需要,和优先级别的需要,权限部分的开发设计将逐步推进,初期会以各应用系统为单元进行资源权限和数据权限的改造,随后将根据重要业务系统的需要,逐步建立中心话的passport

 

  1.2 权限设计的原则

2. 资源权限解决方案

  2.1 概览

 (1)功能级授权采用通常的权限分组,角色绑定资源的通用设计思路来完成。基本设计思路如下图:

  

                                       资源权限绑定概览

    资源:
   
菜单,按钮,URL,页面中的任何元素。
   
角色:
   
根据业务定义的各种角色,比如订单生成角色,结算角色等。
   
组:
   
用于联系角色和用户。
   
用户:
    
系统中登录的用户。

 

(2)资源权限在开发,测试,项目上线后维护中的不同作用:

   项目开发和测试阶段:

  • 项目开发人员和业务人员共同确定什么资源需要权限管理并在系统中定义资源。
  • 在页面当中定义控制资源访问的tag。
  • 根据业务模块的不同定义相应的增删改查的角色。
  • 绑定角色和资源。

   在项目上线之后和运维阶段:

  • 在需要的时候可以继续建立更多的角色,并绑定角色和已有的资源。
  • 建立用户组。
  • 绑定用户组和已有的角色。
  • 为用户组指定管理员,并授予管理员管理用户组的权限,用户组的管理员一般是业务人员的领导。
  • 用户组管理员根据本部门的需要和调整,来动态的增减用户组的成员。
  • 被加入用户组的成员立刻获得系统相应访问资源的访问和使用权限,无需修改代码。

 2.2 管理类型和普通类型

  分组和角色分别都有两种类型,一种是管理类型,一种是普通类型,以下做详细说明:

   分组表设计(Group)

类型

说明

Id

Number(10)

Not null

PK

Name

Varchar2(128)

Not null

组名称

Admin

Boolean

Not null

是否为管理类型

3. 功能级授权基本设计

  功能级授权的意义在于对页面可见元素的操作性,单纯从页面的可见性可简单划分成如下几个部分:

   以上三点其实都可以归结为第三点,即:任何页面可见的元素均可纳入功能级权限管理。
实现方法:采用自写JSP标签完成,执行该标签时需要从后台或缓存中查找当前用户是否有使用当前资源的权限,如果有则正常显示,如果没有则将标签内所有内容从服务端剔除后再响应客户端。如下图:

   

                                  资源权限流程

  3.1 标签实现的代码

[java] view plain copy

 print?

  1. publicclassAuthTagextendsStrutsBodyTagSupport{   
  2. private Set<String>authCodeSet;   
  3. publicvoidsetCode(String code) {   
  4. String[] codes = code.split(",");   
  5. authCodeSet = newHashSet<String>(Arrays.asList(codes));   
  6. }   
  7. publicintdoStartTag() throwsJspException {   
  8. HttpSessionhttpSession = pageContext.getSession();   
  9. Authentication authentication = (Authentication)httpSession.getAttribute(SessionSecurityConstants.KEY_AUTHENTICATION);   
  10. if(authentication == null){   
  11. returnSKIP_BODY;   
  12. }   
  13. if(hasAuth(authentication)){   
  14. returnEVAL_BODY_INCLUDE;   
  15. }   
  16. returnSKIP_BODY;   
  17. }   
  18. privatebooleanhasAuth(Authentication authentication){   
  19. for(String auth: authCodeSet){   
  20. if(authentication.getComponentResources().contains(auth)){   
  21. returntrue;   
  22. }   
  23. }   
  24. returnfalse;   
  25. }   
  26. }  

4.安全性设计

    页面元素的可见性并不能控制URL的可访问性,在系统设计中,使用Struts2的拦截器机制来过滤URL,防止用户不通过页面直接通过URL访问系统。
    系统资源的抽取设计。
    系统资源包含了以上提到的两个部分页面元素和URL,两种资源在某些时候是可组合的,比如按钮点击后提交URL,则该按钮与该URL可组成一个资源。
    页面元素可独立成为一个资源,而URL不能脱离页面元素独立成为资源。每个资源都有唯一的标标识。
    资源与资源之间也存在层级关系,比如下图:

            

 4.1 资源表设计

列名类型(长度) 可否空

说明

Key varchar2(256) not null

标识资源的唯一的代码

Name varchar2(256) not null

资源名称

Url varchar2(256) null

对应的URL

Parent_key varchar2(256) null

父资源代码

Desc varchar2(256) null

                       描述或备注信息

    Key值的设定建议采用会意的字符串,比如新增按钮资源属于第三级资源则它的代码应该为"sysres_duty_add".

 4.2 授权树状插件

     对资源的授权采用ZTree插件实现,效果见下图:
       

                                   对资源进行管理的树状插件

  4.3 插件使用方式:

   如何在struts中使用资源权限tag

[html] view plain copy

 print?

  1. <%@ taglib prefix="hop" uri="/restree" %>   
  2. <res:treeurlres:treeurl="resTree.action"   
  3. expandUrl="expandResTree.action"   
  4. async="true"   
  5. chkType="check"   
  6. id="demoTree"/>  

5.数据权限方案

  5.1 业务关键字定义:

   

                  数据权限业务关键字定义

    

  5.2 设计思路和原则

    5.3 什么是岗码?

  

                         岗码大体结构

    

  5.4 岗码定义和阅读规则

    

                                        岗码的格式规则

     岗码格式如下:

     岗位ID_岗位类型(管理/业务)_岗位职位_工贸ID_渠道ID_经营体ID_产品线code_BUCode_品牌_型号经营体.
     
注意:根据业务需要,岗码会不断的扩充,以存储更多用于分析查询的信息.

  5.5 岗码生成和岗码从数据库刷新至业务服务器

  

          岗码生成和岗码从数据库刷新至业务服务器

    

  定时更新策略
 
每天定时执行岗码更新SQL脚本,更新数据库中的岗码,并且定时重置内存中的数据缓存。这里建议采用增量式更新,否则对数据库压力过大。这里所使用的SQL脚本可参考下面第2点实时更新策略所使用的脚本。
  
实时更新策略
 
对于更新相对较频繁的表(如人员表、岗位表),首先在该表上设立触发器,基于表做的所有修改将记录到历史表中,系统定时扫描历史表,发现改动则执行SQL脚本更新岗码,并更新缓存。这里的更新指单条记录的更新,非批量更新。

  当蓝色部分使用应用服务的时候可以直接更新缓存,从而略过橙色部分活动图。
 
历史表ecc_oms.sys.his

列名类型(长度) 可否空

说明

Id Number(12) not null PK

PK

Table_name varchar2(128) not null

表名

PK_Valuevarchar(512) not null

主键值如:123, 张三

PK_namevarchar(128) not null

主键字段如:empId, empName

Oper_type number(2) not null

操作类型:增:1、删:2、改:3

Create_time Date not null

创建时间

flag varchar2(1) not null

完成标记位: 0:未完成,1完成

    

 5.6 如何存储岗码:

 (1) 新增用户-岗位关系表和岗位-用户岗码关系表:ecc_oms.sys_emp_code
  Emp_id :用户ID
  Code_id:岗码ID-对应ecc_oms.ecc_oms.sys_code表主键
 (2) 岗位-客户岗码关系表:ecc_oms.ecc_oms.sys_cust_code
  Cust_code:客户code
  Code_id:岗码ID

 5.7 如何从数据库刷新岗码到应用服务器

  系统启动时,将所有岗码涉及到的表全部读取成JavaBean(不是持久化对象),放在缓存中。
   /**********
资源相关**********/
   
人员信息:  ecc_oms.sys_employee
   
组织(部门信息)信息:  ecc_oms.sys_org
   
职位信息:  ecc_oms.duty_title
   
区域(工贸)基本信息-ecc_oms.sys_area_info
   
所属产品线,产品系统的产品(型号)信息:ecc_fnd.product_v
   
产品线信息:ecc_fnd.product_line_v
   
大小渠道基本信息-ecc_fst.sales_channel_properties
   
岗位基本信息:ecc_fst.station_config
   
客户关系信息 -ecc_customer.customer_info_v
   BU
信息表 -ecc_oms.sys_bu_info
   BU
与产品线对应关系表 -ecc_fnd.bu_product_group_pl

   /*********
授权相关*********/
   --
组织经营体:  ecc_oms.SYS_ORG_SALECHANN
   --
组织产品线:  ecc_oms.sys_org_prod
   --
组织职位:  ecc_oms.org_duty_title
   
岗码表:  ecc_oms.sys_station_config
   
用户岗码表:  ecc_oms.sys_emp_code
   
客户岗码表:  ecc_oms.sys_cust_code
   
经营体与小渠道关系信息(按产品线): ecc_fst.sales_channel_manager_relation
   
客户信息表-二级区域与客户关系表


   
主要类列表和简单描述:

以上是关于基于SSM框架的通用权限框架设计的主要内容,如果未能解决你的问题,请参考以下文章

基于SSM框架的RBAC权限系统设计与实现(附源码论文 )

基于ssm框架设计定做

毕业季基于ssm框架的管理系统设计与实现如何写开题报告,怎么完成设计

基于SSM框架的旅游购票系统的设计与实现

垃圾邮件管理系统,基于SSM框架的JAVA系统

zsy框架-架构设计