关于BIEE的权限设计

BIEE 的权限中，仪表盘的权限是容易控制的，难度比较大的其数据权限的实现，也就是不同的人员查看同一个仪表盘时，看到的数据要根据权限来过滤。

 

使用 BIEE 的过滤器，根据 usergroup 设置分别的 filter，是一种解决方案。但这种解决方案中，需要在 Admintool 中设置与业务系统对应的用户组。对于大型集

 

团应用，工作量较大，且当业务系统发生变化时，同步的工作也很大。这里提出一种新思路，将 fact 表使用参数化视图来替代。达到一种类似 VPD 的效果。下

 

面是具体的实现方法。

 

 

1.1 用户信息表

 

 

用户信息表（sys_security）是业务系统中用户信息的一张远程视图，来看一下表的结构：

 

 

 

 

这其中第 2 列为 intpersonID，这个是人员的 ID，第 4 列式 intPositionID，这 个是用户的职位 ID，而职位 ID 正是用来进行权限判断的关键字段。（基于人员

ID 或是职位 ID 的权限结构，这完全取决于业务系统的设计。）

 

 

1.2 权限视图

 

 

权限视图（sys_datascope_downwards）也是一张业务系统的授权数据转换而来的视图，其中的数据包含了指定 positionID（例子中的授权关键字段）能够

 

查看的组织机构 ID，表结构如图所示：

 

 

 

 

第 4 列为 positionID ，第一列为 intorgnizationID ，而例子中的事实表 （sal_paybasicsum_summary）中包含有 orgID 即组织机构 ID。来看一下事实表

的结构：

 

 

 

 

可以看到第 3 列即组织机构维，如果将这个维度与权限视图inner join，生成view，如果可以将登陆人的positionID 代入到 view 的 where 条件中，就可实现不

 

同权限的人看到不同的事实数据，如下：

select C.*

 

from sal_paybasicsum_summary C

 

inner join sys_datascope_downwards r on r.intorgnizationid=c.orgid where r.intpositonid=<登录人的职位 ID>

 

我们可以看到，<登录人的职位 ID>是要得到登录 BIEE 系统的账号所对应的intpositiondID。这就又要用到 BIEE 的外部 DB 验证方式。

 

 

1.3 BIEE 外部 DB 验证

 

 

按下图进入 variables 的设置。

 

 

 

设置 session 下的相关内容：

 

 

 

 

主要需要设置 loginvalidate 的内容和 variables 列表，这两者的顺序和个数要

 

相互匹配。

 

 

 

 

 

 

SQL 语句如下，基于的表结构为 2.1 节的用户信息表： select

 

t.strpositionname,t.strbranchname,t.strorganizationname,t.strcaption,t.strpositionname,t.intpositionid,to_char(sysdate,'yyyy')||' 年'||to_char(sysdate,'mm')||' 月 'strloginDate,to_char(add_months(sysdate,-1),'yyyy')||' 年'||to_char(add_months(sysdate,-1),'mm')||' 月 'strLoginDate1,to_char(add_months(sysdate,-1),'yyyy')||' 年 'strLonginYear from sys_security t

where intpositionid =:USER and1=:PASSWORD

 

说明：为了方便，这里把用户密码固定为 1，实际中采用 MD5 加密的密码。

 

和上面的查询语句相匹配的参数列表如下：

 

 

 

 

需要注意的是，第一个参数一定是 USER，参数明大写。

 

完成这一步骤后，当用户登陆 BIEE 后（可能是直接登录，或者从外部系统模拟 SSO），会形成上面的 9 个 biee session 参数，其中第 6 个参数 intposiitionID

 

是我们用于权限判断的关键参数，需要通过特殊方法将该参数写到数据库的session 中。这是整个权限设计的关键环节，即：

 

 

 

（参数）BIEE Session ——> （参数）DBMS Session

 

 

1.4 物理层的 connection pool 设置

 

 

如何将参数从 bieesession 写入到 dbms session，需要如下设置：

 

 

 

如图，在物理层设置 connectionpool，在 connectionscripts 页签中，在每一

 

次执行查询前，均执行如下的 SQL 语句：

 

selectsecurity.set_security_position(VALUEOF(NQ_SESSION.intpositionid)) from

 

dual

 

这里涉及到一个函数 set_security_position(p_positionid in integer)，

 

其中包含 1 个参数，通过 VALUEOF(NQ_SESSION.intpositionid)将 biee session中的 intpositionid 取出，然后写入到数据库的 dbmssession 中，以达到整个方案

 

中的最关键步骤。来看一下 function 的写法：

 

createor replace function set_security_position(p_positionidin integer)

 

returninteger

 

asbegin

 

set_position_id(p_positionid);

 

return0;

 

end;

 

这其中又调用了一个 procedure ， 这中嵌套出于无奈， 因为dbms_session.set_context包只能在procedure 中才能调用。

 

l_ctx    varchar2(255)default 'sagacity_ctx_Analytics';   /*上下文背景名

 

 

称*/ begin

 

dbms_session.set_context(l_ctx,'PositionID',p_positionId);

 

end;

 

这 就是 procedure 的写法， 其中定义了 context 的名称：“ sagacity_ctx_analytics ” ， 这 样 定 义 后 ，只 要 使 用

 

nvl(Sys_Context('sagacity_ctx_Analytics','PositionID'),0)的写法就能取出 dbms session 中的 positionID 的值。

 

最后，再来看看 fact 表的最终写法： select C.*

 

fromsal_paybasicsum_summary C

 

innerjoin sys_datascope_downwards r on r.intorgnizationid=c.orgid

 

where               r.intpositonid=

 

nvl(Sys_Context('sagacity_ctx_Analytics','PositionID'),0)

 

 

 

2  需要注意的问题

 

 

 

2.1 biee session 与dbms_session。

 

 

因为在这种解决方案中，采用了将 bieesession 写入 dbms_session 的做法，因此在连接池的设置上需要考虑同时使用者的人数。

 

 

图中的 maximum 为 biee 占用 oracle 10g 的最大链接数。

 

还需要考虑的是 oracle 的 sessions 参数。如果该参数过小，而 biee 的并发连接数过大。是否可能会出现串 session 的情况。