FrameWork数据权限浅析3之基于角色的配置表实现行级数据安全

带着上一次笔记的疑问和些许欢喜来到了混混沌沌的下午,程序员的脑子一直在不停的思索着,而多思考总是没错的，盼望着盼望着事情就有了转机，现在我们就来说一说基于角色级别的中间表机制实现行级数据安全.

由于本文大概思路和基于用户级别的中间表机制实现行级数据安全类似，所以在这里就说一说有区别的地方，如果实在有不明白的地方，我想在几十个字前面的链接处给出的文章会给你提供很大的帮助.

1：定义权限标准

和基于用户级别的保持一致.

2：设计基于角色的中间表角色部门表

表(access_role)结构如下图所示

字段解释：roleid来自CJP权限认证的角色表，deptid来自数据仓库中的部门维度表

3:在FM中创建关联关系

--3.1创建事实表和权限标准直接的多对一关系（pdept  1:n  product）

由于和基于用户的操作一样，这里不过多描述

--3.2创建事实表和用户部门表之间的多对一关系（access_role  1:n  product）

由于和基于用户的操作一样，这里不过多描述

--3.3给角色部门表添加过滤器，此步骤很重要

代码解析：#sq(CAMIDList())# contains [physical layer].[ACCESS_ROLE].[ROLEID]

#sq(CAMIDList())#表示利用宏函数获取当前登录用户的所有角色信息并返回，实际内容如下所示

'CAMID("Intrust:u:1"), CAMID("Intrust:r:10000"), CAMID("Intrust:r:10001"), CAMID("::Everyone"), CAMID("::System Administrators"), CAMID("::All Authenticated Users"), CAMID(":Authors"), CAMID(":Query Users"), CAMID(":Consumers"), CAMID(":Metrics Authors"), CAMID(":Metrics Users"), CAMID(":Planning Contributor Users"), CAMID(":Controller Users"), CAMID(":Analysis Users"), CAMID(":PowerPlay Users"), CAMID(":Data Manager Authors"), CAMID(":Readers"), CAMID(":Express Authors"), CAMID(":Adaptive Analytics Users"), CAMID(":Statistics Authors"), CAMID(":Mobile Users"), CAMID(":Cognos Insight Users"), CAMID(":"), CAMID("Intrust")'

返回的是一个字符串，然后我们看再去和access_role中的角色ID比较如果包含则取改行roleid对应的deptid.

经过以上操作，保存模型，发布到cognos connection。

4：在设计报表的查询中添加明细过滤器

[产品认购分析].[部门].[部门].[部门].[部门键]=[physical layer].[ACCESS_ROLE].[DEPTID]

该步骤主要是让角色部门中间表和分析中的部门维度关联起来，实现角色级别的部门ID过滤，然后和部门维度进行关联，这就起到了

只显示和角色相关部门的数据的作用.在以后的管理中我们只要管理好access_role角色和部门之间的关系，给该报表添加数据访问新

用户的时候，在页面维护CJP中的用户角色表，给新用户加上有访问该报表权限的角色即可.如果需要让新角色具有访问该数据的权限，

则需要维护access_role表，结合起来，保证访问权限和数据权限的相对完美实现.

5:查看效果

--5.1可以实现具有不同角色的用户可以访问报表中不同部门的数据

--5.2可以实现修改CJP权限认证中用户角色表来实现给用户增加或者减少访问数据的权限

--5.3可以实现修改access_role来给新角色赋权

PS：需要注意的是，如果用户a具有角色1、角色2, 角色1可以访问部门1的数据，角色2可以访问部门2的数据，则用户a的

访问权限是其所拥有角色权限的并集，即：用户a可以访问部门1和部门2的数据.

6：优缺点分析

--6.1优点

此方法可以保证在以后给该报表增加访问用户或者角色的时候不再修改FM模型即可，增加用户的访问权限维护CJP权限认证中的用户角色表即可，增加角色的访问权限维护

access_role表即可，而且把这种关系扩展到角色和用户的维护符合用户分配权限的习惯.

--6.2缺点

唯一的缺点我想应该是每次设计报表都需要在查询的明细过滤器中加上一个access_role和权限标准表的关联关系，而且从需求完整度上来说，需要维护CJP中的用户角色中间表和access_role两张表，可以这么说比起CJP权限管理来说，我们增加了一个配置表access_role，此表的作用就是建立权限指标表和角色表之间的关系.

--6.3扩展

当然，随着业务的扩展，权限指标可能会多起来，不仅仅局限于部门,也可能是产品类型、所属区域等等,这样的话我们可以考虑在access_role增加一个字段比如下面的结构

当然，这个时候我们可以给表换个名字如下图所示，只是在设计报表的时候多增加一个过滤条件即可 where accesstype=''