Categories
- All Categories
- 15 Oracle Analytics Sharing Center
- 14 Oracle Analytics Lounge
- 211 Oracle Analytics News
- 41 Oracle Analytics Videos
- 15.7K Oracle Analytics Forums
- 6.1K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 77 Oracle Analytics Trainings
- 14 Oracle Analytics Data Visualizations Challenge
- Find Partners
- For Partners
OBIEE 12c Application Role Auditing

OBIEE 11g Catalog Groups have been migrated into OBIEE12c WebLogic Application Roles.. (fusion middleware control - security - application roles)
A: is there a way to grant users access to manage those without giving them full access to the rest of weblogic..
B: is there a way to audit who makes the change when a user is put in or taken out of an application role.. Preferably into a table that can be reported on in an OBIEE Subject area..
Answers
-
On OBIEE 11g:
- Oracle recommends that Oracle BI Presentation Catalog groups be used for backward compatibility only and that Application Roles be used instead for new installations.
Catalog Groups as a way of doing things went away a long time ago ... do you have a mix of them and application roles (due to moving from 10g in the past)?
You don't want end users managing your application roles ... you want a BI Administrator or at least one of your Oracle Fusion Middleware Admins doing it.
0 -
yes, version 10 and 11 we used catalog groups. the Presentation Admins managed who was memebers of them via BI..
we are working on 12c migration and have converted the catalog groups to application roles.. and I have given the presentation admins access to fusion middleware control so they can continue to manage who is in the roles.. I was just wondering if there was a way to restrict them to only that task and not everything else in the console..
Management is also asking if there is any way to audit who is adding/removing users from the application roles..
0 -
If you want a non-Enterprise manager way of handling this where people aren't weblogic admins then best move this out to a DB table where you then handle it via APEX for example and the read that table as a BISQLGroupProvider security provider in the WLS security realm.
0 -
Amen - stick it in a database, then mass user account maintenance, auditing, addition, deletion becomes so much easier!
0 -
Yeah. Managing named user rights in EM either through the GUI or through WLST is just awful.
0 -
You got already some alternatives above on how to manage that need.
Staying on the "default" way to manage things you would have to collect and analyse detailed web logs of the Adminserver: the EM interface you use execute actions when you add/remove somebody from a role, so you would probably extract these actions from the webserver log etc.
But it's for sure not as easy and practical than using a DB table to map users into roles (and APEX on top).
0 -
Not to make too fine a point but next time maybe check which answer arrived in which chronological order :-P
0 -
So it goes...
I said to Dude! on the ideas forum that sometimes the awarding of points is capricious and random @Dude! this is the kind of thing I had in mind...
0