EBS R12.2 RBAC(Role based Access

RBAC (Role based Access Control) 基于权限的访问控制

在R12.2 之后，EBS引入了Role的概念，相较于以前通过Responsibility来控制用户的访问权限的方式外，引入了Role的方式给用户分配访问权限
下面介绍几个Role的使用方法

通过Role实现同一个Responsibility下不同Role的有不同的功能访问权限

1. 新建一个Menu，分配需要子菜单1 和子菜单2 ，菜单下所有子菜单的授权全部不勾选
2. 新建一个Responsibility X，关联新建的菜单
3. 新建一个Role A，然后继承自Responsibility X，然后给这个Role创建授权，授权的permission set为菜单中的子菜单1。
4. 新建一个Role B，然后继承自Role A，然后给这个Role创建授权，授权permission set为菜单中的子菜单2。

只分配了Role A的用户，就可以看到Responsibility X，但是只能访问菜单1
这样只分配了Role B的用户，就可以看到Responsibility X，可以访问菜单1和菜单2

相应的配置文件还是在Responsibility层设置。

通过套娃的方式可以方便设置。标准功能可以参考Approval Manager Administrator的设置。

通过Role/Grant实现针对某个用户分配请求权限

1. 新建一个role，然后创建授权
2. 同时可以限定职责，如果不限定则在所有职责都可以提交
3. 数据安全性选择并发程序，在数据上下文中指定对应的请求信息。

分配了这个role的用户就可以提交这个请求。这样可以避免Request Group无法针对用户限制某些报表的问题

Fusion的权限

Fusion的权限完全基于Role，还去掉了Responsibility的概念。对于权限管理带来了一些问题

1. Role授权功能的最小单位是Permission Set，也就是子菜单。由于默认子菜单无法新增/调整，会存在子菜单中部分Function无法被排除
2. 完全基于Role来分配Function和Data Security，没有Responsibiltiy的上下文，会出现Update/View Only权限无法在同一个功能上区分。但是在网页界面继续保留Responsibility，好像也有点丑。。。