Categories
- All Categories
- Oracle Analytics Learning Hub
- 31 Oracle Analytics Sharing Center
- 21 Oracle Analytics Lounge
- 251 Oracle Analytics News
- 45 Oracle Analytics Videos
- 16.1K Oracle Analytics Forums
- 6.3K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 93 Oracle Analytics Trainings
- 16 Oracle Analytics and AI Challenge
- Find Partners
- For Partners
OAS & DV access control question
Hi, we are using OAS2025, OBIA7.6.4., EBS12.2.12, Oracle19c on Linux. We have our core subject areas whose fact tables are grown > two billion rows over time. We are planning to release DV in stages, first to a selected group of users on custom datasets only. We want DV users to do their Adhoc queries/create workbooks etc. only on custom datasets which are migrated for them but looks like in DV, allowing them access to custom datasets also give them access to the entire list of existing subject areas as well (which includes our gigantic core subject areas, big enough to bring the entire application to a screeching halt for wide open queries). We tried repository's presentation folder permissions, No Access there to DV User is over written by their Read or Default permissions of other roles that they have, Doing subject area access 'Denied' at front end application administration cuts off their access to the subject area in both OAS as well as DV. We want the DV users to keep their current access in OAS (for published content or Adhoc analysis or both) as is but when they go to DV they should only operate with custom datasets, created and migrated for them to query and build DV content using it (and NOT pull in the entire list of existing subject areas to be used along with custom dataset). Any tip/guidance on how to achieve that is highly appreciated.
Best Answer
-
Well, no tool will ever fully cover for what a user will or can do…
All valid points, but you can't do much more than explaining things. Tell them that the first one taking down the server because of something obviously "stupid" will lose access right away :D
0
Answers
-
You definitely need a strategy to overcome this issue. I would advise to engage Oracle Product team considering it is such a large OBIA deployment.
0 -
Hi @User_SI7HK ,
Overall it is a single product, doesn't matter if you use the "classic" frontend (the /analytics with dashboards and analyses) or the DV frontend. That's why in DV you don't have any permission option for subject areas, because the same security as the rest of the product apply there.
The case you expose was covered by the default security model in the past, already in OBIEE 11g.
As you said, in the RPD you should leave the read permission or your users will not be able to get any data out of your subject areas. But then, it was possible to not give permissions in the frontend (Administration > Manage Privileges > each subject area) when a user wanted to create a new analysis, while preserving their access to the subject area for existing analyses.
The "Access within Answers" was meant to mean just that: who is allowed to see this subject area when creating a new analysis. But there you shouldn't use deny, it is mostly to remove who shouldn't have it and only grant it to the right application names.
Are you saying that this security works for answers but not for DV when creating a workbook? If that's the case, then I would call this a bug, or a missing feature at minimum.
The challenge is that in your environment you probably have security model with inheritances at various levels and places, therefore it is more challenging to test if the product really doesn't work as it should.
I didn't test it in OAS 2025, because didn't have this need.
0 -
@User_SI7HK , good news!
The product works correctly. If you implement security correctly, you get the behaviour you expect.
In a test OAS 2025 environment I create a user allowed to create analyses and DV workbooks, but I didn't granted access in "classic" Administration > Manage Privileges > Subject Areas:… (but didn't set a deny, just granted permission to BI Service Administrator only).
With an account having the BI Service Administrator role I created an analysis on that subject area and saved it in the shared folder. My test user is able to open it and see all the data in the analysis. But my user isn't allowed to see the subject area as a source when creating a new analysis or a DV workbook.
Everything works fine.
This means you should review your security model and adapt it as needed to separate users allowed to create analyses and workbooks with your subject area and who is only meant to consume it.
0 -
Hi Gianni, thanks for your insight to my issue. We have many groups (FA's, Billers etc.) who have access to published content (common dashboards reports) but don't have access to subject area (for Create > Analysis), except for handful of Superusers (belonging to rolls added in front end Weblogic>Administration> Manage Privilege> Subject Area: added with that role(s) of Superusers). General read-only population with lowest rolls (like Authenticated Users, BIConsumers, DVConsumers) is not a concern, as they don't have access to any subject area (in OAS or DV). These Superuser groups who have Adhoc capability in OAS and can create reports on allowed subject areas and can save them in their 'My Folders', are required not to have access to those subject areas when they go to DV and just see DV specific custom datasets migrated for the purpose. So basically what we are trying to do is, a Superuser (with Adhoc capability on few subject areas) when goes to DV, then he/she should only see custom dataset migrated to DV and NOT the subject areas that he/she has access to in OAS (in addition to that custom dataset). Hope I understood your response correctly in that respect.
0 -
These Superuser groups who have Adhoc capability in OAS and can create reports on allowed subject areas and can save them in their 'My Folders', are required not to have access to those subject areas when they go to DV and just see DV specific custom datasets migrated for the purpose.
This contradiction is not possible, because the same exact query these users can build with an analysis can be generated with a DV workbook. If they are able, and allowed, to create a new analysis on a subject area, they are also allowed to use that subject area in a workbook in DV. That's how the product works, just because it does make sense.
What they could build in DV that could take your environment down can be done by those same users in an analysis in "classic". That's why there isn't a difference in the availability of a subject area between the 2 front-ends. Both can do the same exact thing, just with a different GUI.
0 -
Thanks Gianni, completely agree with your points, yes that is the general understanding of how the role based set-up of OAS should behave in DV. Data in OAS, to some extent, is more contained/controlled for users and we have been managing it (by monitoring and killing long running query sessions) so far, but with robust control over datasets, easy steps for dataset augmentation, dataset joining to create a dataflows (with on check for whether the joining field is indexed or not) etc. etc. DV appears risky to open up and have these giant tables be available for quick drag & drop in a dataflow. And our large user base is not ready/trained for a big-bang launch of DV due to its drastic UI difference. So at this point we want to open it up to a handful of users (of a specific group, currently we just have bunch of tested workbooks out there only) to explore additional new AI capabilities on a custom datasets and was hoping if it is doable that way.
0
