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，好像也有點丑。。。