关于BIEE的权限设计

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

 

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

 

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

 

面是具体的实现方法。

 

 

1.1 用户信息表

 

 

用户信息表(sys_security)是业务系统中用户信息的一张远程视图,来看一下表的结构:

 

 关于BIEE的权限设计_第1张图片

 

 

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

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

 

 

1.2 权限视图

 

 

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

 

查看的组织机构 ID,表结构如图所示:

 

 关于BIEE的权限设计_第2张图片

 

 

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

的结构:

 

 关于BIEE的权限设计_第3张图片

 

 

可以看到第 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 的设置。

 关于BIEE的权限设计_第4张图片

 

 

设置 session 下的相关内容:

 

 关于BIEE的权限设计_第5张图片

 

 

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

 

相互匹配。

 

 

 关于BIEE的权限设计_第6张图片

 

 

 

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 加密的密码。

 

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

 

 关于BIEE的权限设计_第7张图片


 

 

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

 

完成这一步骤后,当用户登陆 BIEE 后(可能是直接登录,或者从外部系统模拟 SSO),会形成上面的 9biee 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 的做法,因此在连接池的设置上需要考虑同时使用者的人数。

 关于BIEE的权限设计_第8张图片

 

图中的 maximumbiee 占用 oracle 10g 的最大链接数。

 


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

 

 

 

你可能感兴趣的:(BIEE,权限设计)