FrameWork数据权限浅析4之基于多维度配置表实现行级数据安全

日子过得好苦逼，我过的很好，只是缺少￥.时间在变，而问题始终未变，你解不解决它都在那里一动不动.不知不觉已经发现手机的中央，电脑的右下角已经出现了201411的字样，突然从桌子上爬起来，差点忘记了自己还是一个上进的人，吹了几分钟牛逼了，接下来我们还是开始说一说这次的问题吧，往下看你会很快看到解决问题的方法的哦........

在本系列文章的第3篇文章中我们已经在6.3的扩展中写下了这么一段话，接下来我们先熟悉一下

--6.3扩展--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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

只是在设计报表的时候多增加一个过滤条件即可 where accesstype=''

--6.3扩展----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

熟悉了上篇文章的思路，那么接下来我们进入正题吧.

[1]：问题分析

在本系列的文章2、3中我们实现了基于用户、角色配置表的行级数据安全，可以通过在FM之外控制访问数据的权限,但是配置表的结构都只是针对一个权限标准的，那就是部门，而在实际的场景中这个就显得很单薄。

实际的工作中我们可能遇到这样的情况：

1：分析数据中存在产品表product、部门表pdept、产品类型表ptype

2：有三个用户分别是king、zhangsan、test

3：king可以访问‘信托一部’和‘信托二部’的数据，并且产品类型只能为‘单一’的数据

4：zhangsan只可以访问‘信托二部’的数据，并且产品类型只能为‘集合’的数据

5：test没有权限访问此数据

[2]：解决问题

毫无疑问，在文章3中的办法是可以解决这个问题的，接下来我们就说一下具体的步骤

--2.1创建拥有多个权限指标的数据安全配置表，如下图

字段解释：

roleid:来自CJP认证中的角色id

accessid:来自分析数据中的维度表的id

accesstype:判断accessid的类型，是来自部门维度还是来自产品类型维度，即我们所说的权限指标类型

--2.2在FM物理层中改写已导入的维度表

a:改写部门表查询主题定义处的sql脚本

b:改写产品类型表查询主题定义处的sql脚本

c:主要代码解析

(1):ACCESS_TABLE.ACCESSTYPE='产品类型' --过滤为产品类型的id

(2):#sq(CAMIDList())# like '%'||ACCESS_TABLE.ROLEID||'%'--从配置表中过滤出所有当前登录用户所拥有角色的所有维度id

(3):#sq(CAMIDList())#--利用宏函数取出当前登录用户所拥有的所有权限的id

d:保证所有维度表和事实表已经建立了正常的1:n关系

本文中不在多说，所指为

pdept 1:n product

ptype 1:n product

--2.3在cognos connection门户中设计报表

a:设计报表界面，随意拖拉出一个交叉表的层次即可

b：设计无数据提示界面,红圈的地方是设置无数据时页面提醒的，具体配置如下

解析：1处选中3的地方就显示高级了，2的地方选择为空时显示页面4的地方下面可以放一个提示图片或者自定义一些提示文字都可以.

c:设计查询，如下图

解释：与此系列的第2、3篇文章不同的是，查询这里就是拖拉之后的查询效果，没有添加任何任何维度和access_table之间的关系,因为关系已经在维度表

的sql中指定好了，详情请看2.a

[3]:查看效果

--3.1权限关系分析

执行下列语句，来了解一下每一个角色的权限

select r1.role_id,r1.role_name,r1.deptname,r2.typename from
(
select  r.role_id,r.role_name,d.deptname from access_table a
inner join cognos.org_role r on a.roleid=r.role_id
inner join wxj.pdept d on a.accessid=d.deptkey and a.accesstype='部门'
group by  r.role_id,r.role_name,d.deptname
) r1
inner join
(
select   r.role_id,r.role_name,t.typename from access_table a
inner join cognos.org_role r on a.roleid=r.role_id
inner join wxj.ptype t       on a.accessid=t.typekey and a.accesstype='产品类型'
group by  r.role_id,r.role_name,t.typename
) r2 on r1.role_name=r2.role_name and r1.role_id=r2.role_id
order by r1.role_id

结果为：

又因在CJP认证中:

用户king对应的角色id为10000,

用户zhangsan对应的角色id为10001，

用户test对应的角色id为10004

所以king可以访问信托一、信托二部且产品类型为单一的数据

所以zhangsan可以访问信托二部且产品类型为集合的数据.

所以test无权访问此数据，因为test所对应的角色id-1004为在access_table中做任何配置

ps:如果一个报表中同时存在多个权限指标，要想让一个角色拥有看到此报表数据的权限，则

需要在access_table中同时给出这多个权限指标的全部或者部分关联关系，比如报表有部门、

又有类型，则需要至少给此角色一个部门对关系一个类型对应关系.才有可能让用户看到数据,

当然这一切都是根据报表的结构而言的.

--3.2登录测试

a:用户king(国王)登录，查看数据，ok

b:用户zhangsan(张三)登录，查看数据，ok

c:用户test(测试)登录，查看数据，ok

[4]：优缺点比较

--4.1优点

a:考虑的比较周全,可以在一张配置表设计多种权限指标多层级的、更详细的、针对每一个维度的数据权限控制

b:无需为每一个权限指标都创建一张类似access_table的表

c:无需在每一个报表设计界面的明显过滤器中添加维度id和accessid的对应关系

d:无需对access_table本身设置过滤器

e:无需对access_table和事实表创建关联关系，在维度层实现权限控制.

access_table只是在重写维度sql时用到了，本身和FM模型没有什么关系，模型只要保持维度和事实表的1：n关系就好了

--4.2缺点

a:需要对一个配置表维护多个字段设置多个行,比如:给一个角色新增访问权限，就需要考虑多个权限指标是否都要配置关系

而且还需要指定该accessid的所属维度类型.

-----------------至此为止------------------

Framework数据安全系列文章我想可以告一段落了，感谢Cognos中国论坛上面所有同学给的思路，感谢Intelnet，至此敬礼