2.1 授权实现
授权包括角色授权和用户授权。角色授权就是先建立某一角色,然后对这个角色能访问的资源进行CRUD权限分配,再将角色分配给具有相同权限的用户。角色授权的优点是可以批量授权,可以极大地提高管理效率。用户授权,就是将资源的访问权限直接授权给某个具体的用户。
要实现权限的精粒度控制,就必须允许用户自行定义角色,然后对角色进行授权,而不是由软件设计者在写程序时就预先固定角色。而且这种精粒度的权限管理必须达到对菜单级的精细控制以及对WEB页面上的按钮级的精细控制。在B/S结构的软件系统中,对数据的增加、读取、修改、删除等操作都是通过WEB页面上的相应按钮或超链接的方式实现的。用户点击按钮将触发相应的请求,服务器端收到请求后调用业务逻辑完成相应的CRUD操作。例如,用户点击“增加”按钮,一般会出现增加数据的WEB页面,用户填写好相关的表单,单击“提交”按钮后,将触发“添加”(Create)请求并发送给服务器端,服务器端收到请求后在后台调用添加数据的业务逻辑,将数据持久化到数据库中,完成对数据的添加操作。也就是说,实现精细控制的权限管理后,如果用户对某一资源具有相应权限(例如删除权限),则在客户端的软件界面上“删除”按钮对该用户是可见的,否则就是屏蔽的。
在具体的程序实现过程中,授权就是将该角色能访问的资源标识(模块id)和角色标识(角色id)以及它对该资源具有的CRUD权限(一个正整数的低4位对应的二进制组合)写入ACL数据表,完成授权数据的持久化操作。
2.2 认证实现
认证就是用户登录后,系统根据他所拥有的权限,列出相应的菜单。具有不同权限的用户登录后,前台展现的菜单是不同的。
在具体实现程序时,认证就是从ACL数据表中检索出登录到系统的用户所能访问的资源标识(即模块id),形成前台显示菜单需要的数据格式,供前台显示菜单使用。同时,将用户所能访问的资源标识及用户对该资源具有的CRUD权限(一个正整数的低4位对应的二进制组合),写入session中,然后在视图(一般是jsp页面)上从session中取出用户的ACL控制列表,根据用户拥有的权限,在jsp页面上进行判断,然后根据判断结果分别显示“读取”、“增加”、“删除”、“更新”等按钮,实现精粒度的权限控制。
在编程过程中,一个用户可能拥有多个角色,同时也可能拥有单独的用户授权。此时,要先从数据库的T_ACL表中查询出该用户拥有的角色的权限列表,再查询出该用户拥有的单独权限列表,对它们进行“与”运算,最后形成该用户的权限列表。在这一过程中,角色所拥有的权限可能会与用户单独拥有的权限重复,但通过“与”运算后,就可以剔除重复的权限。
2.3 编程实现
B/S结构的软件系统中,一般具有导航菜单,每一个导航菜单实现相应的功能。例如在“地震台站管理系统”中,导航菜单具有“台站管理”、“仪器管理”、“人员管理”、“用户管理”、“角色管理”等一级菜单,这些导航菜单对应软件中的模块,每个模块完成相应的功能。每一个导航菜单都具有菜单名称、入口地址(类似于网址)等信息,它们存放在数据库的模块管理数据表中。在读写数据库时,采用Hibernate与数据库“打交道”,权限管理中所用的实体类(也叫VO类、Pojo类)类图及其关系见图2。
图2 权限管理中的实体类类图及其关系(北京尚学堂科技有限公司,2008)
Fig.2 Rights Management in the entity class diagram and their relations(Beijing Shangxue Tang Technology Co.,Ltd.,2008)
在程序设计过程中,笔者采用Struts2+Hibernate+Spring架构,授权部分使用DWR框架。由于每个实体都要进行写入、读取、更新、删除、分页等操作,因此笔者使用Java的泛型设计了一个GenericDao基类,该基类继承自Spring提供的HibernateDaoSupport类,可以完成基本的CRUD、分页等操作。对ACL、User、Role等的Dao操作则设计继承于GenericDao的子类,只要传入相应的实体即可。同时,为了方便软件的维护,笔者设计了Service层,在Service层完成业务逻辑,并调用Dao层完成对数据库的操作。前台与后台的“沟通”由Struts2的Action完成,在Action中调用Service层的业务逻辑来处理业务需求,然后将处理结果转发至前台jsp页面。各种Dao、Service、Action则统一由Spring容器进行管理。
(1)授权过程:建立角色→对角色进行授权(资源与角色关联)→将角色分配给用户(角色与用户关联)。建立角色的过程十分简单,采用Struts2的Domain模型传递参数,Struts2在Action中会自动根据前台传入的角色数据实例化一个Role类,只需要在Action中调用roleService(完成对角色数据的CRUD、分页等操作)的添加方法将其持久化到数据库中即可。而授权包含对角色的授权和单独对用户授权,当前台用户点击复选框(图3)将其选中时,后台会根据主体标识(角色或用户)作出判断,当主体标识为“角色”时将主体标识(Role)、资源id、角色id、对该资源的CRUD权限(一个正整数的低4位)写入数据库; 当主体标识为“用户”时将主体标识(User)、资源id、用户id、用户对该资源的CRUD权限写入数据库。当取消复选框时,则应从数据库中删除以上信息。在实现这一操作时,笔者使用DWR框架完成授权页面与后台业务逻辑Service层的交互,在不刷新页面的情况下就可以完成以上操作。
图3 精细权限管理在地震台站管理系统后台管理中的应用
Fig.3 Fine-right management in the Seismic Station Management System
(2)认证过程:验证用户登录→根据用户id查找其拥有的角色,从T_Acl数据表中查找角色拥有的权限→根据角色的权限查询模块资源(菜单)列表,同时将权限列表写入session→前台显示菜单,完成认证过程。在认证过程中,首先检查用户登录是否成功,成功后才查找用户的权限。
验证用户的操作是在Struts2的loginAction中完成的,如果验证成功,则调用业务逻辑AclService,从数据库中检索出用户拥有的权限,根据权限从模块数据表中检索出模块信息放入moduleList,同时将用户权限放入一个aclList,然后写入session中。最后loginAction转发到前台的主页面,主页面上用Struts2的<s:iterator>标签遍历moduleList,列出主菜单。需要注意的是,只要用户对某一资源(模块)具有CRUD中的任何一个权限,主菜单就要列出相应的菜单,而用户是拥有C、D、U还是R权限,则需在具体的WEB交互页面上读取session中用户的权限列表,决定是否显示添加、删除、更新、编辑等按钮,这就是精细的权限控制。
在实际应用中,前台主菜单一般都需要美化处理。主界面有左侧树形菜单导航,也有顶部下拉菜单导航,具体采取哪种导航菜单,需根据项目的实际需要决定。而前台需要什么样的菜单数据,只需要在Struts2的用户验证的Action中构造就行了。在“地震台站管理系统”中,前台菜单是用ExtJS框架展示的树形菜单,所以菜单资源返回的列表数据要转化成json字符串。
