RBAC (Role based Access Control) 基于權(quán)限的訪問控制
在R12.2 之后沥曹，EBS引入了Role的概念，相較于以前通過Responsibility來控制用戶的訪問權(quán)限的方式外锅很，引入了Role的方式給用戶分配訪問權(quán)限
下面介紹幾個Role的使用方法
通過Role實現(xiàn)同一個Responsibility下不同Role的有不同的功能訪問權(quán)限
- 新建一個Menu，分配需要子菜單1 和子菜單2 ，菜單下所有子菜單的授權(quán)全部不勾選
- 新建一個Responsibility X瘾晃，關(guān)聯(lián)新建的菜單
- 新建一個Role A，然后繼承自Responsibility X幻妓，然后給這個Role創(chuàng)建授權(quán)蹦误，授權(quán)的permission set為菜單中的子菜單1。
- 新建一個Role B肉津，然后繼承自Role A强胰，然后給這個Role創(chuàng)建授權(quán)，授權(quán)permission set為菜單中的子菜單2妹沙。
只分配了Role A的用戶偶洋，就可以看到Responsibility X，但是只能訪問菜單1
這樣只分配了Role B的用戶距糖，就可以看到Responsibility X涡真，可以訪問菜單1和菜單2
相應(yīng)的配置文件還是在Responsibility層設(shè)置。
通過套娃的方式可以方便設(shè)置肾筐。標準功能可以參考Approval Manager Administrator的設(shè)置哆料。
通過Role/Grant實現(xiàn)針對某個用戶分配請求權(quán)限
- 新建一個role，然后創(chuàng)建授權(quán)
- 同時可以限定職責吗铐，如果不限定則在所有職責都可以提交
- 數(shù)據(jù)安全性選擇并發(fā)程序东亦，在數(shù)據(jù)上下文中指定對應(yīng)的請求信息。
分配了這個role的用戶就可以提交這個請求唬渗。這樣可以避免Request Group無法針對用戶限制某些報表的問題
Fusion的權(quán)限
Fusion的權(quán)限完全基于Role典阵，還去掉了Responsibility的概念。對于權(quán)限管理帶來了一些問題
- Role授權(quán)功能的最小單位是Permission Set镊逝，也就是子菜單壮啊。由于默認子菜單無法新增/調(diào)整，會存在子菜單中部分Function無法被排除
- 完全基于Role來分配Function和Data Security撑蒜，沒有Responsibiltiy的上下文歹啼，會出現(xiàn)Update/View Only權(quán)限無法在同一個功能上區(qū)分抵蚊。但是在網(wǎng)頁界面繼續(xù)保留Responsibility耘婚，好像也有點丑裹唆。讳嘱。。
