nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Oracle Communities

Oracle Analytics and AI

Child Item

OBIEE 12c folder level security and subfolders

3310714

Hi,

I have couple of questions wondering if someone have any insights.

1) Is it possible to enforce security at the folder level? For example I have my subject area ABC and two folders below it: HR, FIN :

ABC

FIN

I know I can enforce security at the ABC level via Managed Privileges. Any idea if I can enforce security at the HR and FIN folder level so HR cannot see FIN, vice versa?

2) Is it possible to create sub-folders in OBIEE 12? I don't see that option in the Admin Tool. For example I'd to have:

ABC

EMPLOYEE

FIN

SALARY

I want to put some attributes in the HR and FIN folders, as well as EMPLOYEE and SALARY sub-folders.

Thanks in advance!

Find more posts tagged with

Accepted answers

All comments

Frog Toad

Hi!

2) Yes, it's possible

Properties of Presentation table -> tab "Child Presentation Tables":

Here you can set subfolders for main folders

Finally view in presentation services:

Gianni Ceresa

Hi,

You are mixing things up a bit ...

You have security in multiple places, the one you are referring to, the "Manage Privileges" in the front-end admin, isn't really security, it's more what a user can see in the "new analysis" drop down list. The same user with no access to a subject area there can perfectly open and see analysis built on that same subject area.

In the Admin tool you have permission on every single object of the presentation layer, from the subject area, down to table, down to columns.

You must only pay attention to inheritance (the behaviour of "default") and to multiple conflicting permissions if member of many app roles as "read" is stronger than "no access".

@Frog Toad answered the sub-tables part of your question, in first 11g it was limited to 1 level and I guess you can now have multiple levels.

The question is more if you don't better have multiple subject areas as it would make your full security management simpler than "access ABC subject area but then hiding the HR table which act as a fake sub-subject area" etc.

From a business model you can create many subject area, and as they all come from the same model they can be mixed together in a simple way.

3310714

Hi Frog Toad - thanks for that tip! Will check it out!

Hi Gianni - thanks for your insights. Initially I was going to create two subject areas, HR and FIN, and control access to them under Manage Privileges. I would also create two catalog folders HR and FIN and only the people in the appropriate group would have access them. Now the requirement was changed recently and we need to create Analysis combining data from HR and FIN. I couldn't find a way to join results between HR and FIN in Analyse. That's why I thought putting them under one subject area, but controlling access to them via security. Do you know if it's possible to join results between subject areas?

[Deleted User]

3310714 wrote:Do you know if it's possible to join results between subject areas?

If by "join" you mean utilize in the same analysis then it's the same answer as in the doc and since the inception of the "Add Subject Area" functionality:

Subject Areas can be added to an existing analysis if they are based on the same Business Model as the originating Subjecr Area.

Gianni Ceresa

Hi,

First thing first: manage subject area in "Manage Privileges" isn't security, it's like if you look at the moon, you put your thumb in front of it and suddenly say you found a way to hide the moon. It's a wrong impression of security, do not base any security on that one. Security is about data: can you access data from that subject or no? This isn't managed in "Manage Privileges" (the wording and the fact you see subject areas there doesn't help make the point obvious ).

You can combine the results between HR and FIN as they come from the same business model, so OBIEE is smart enough to understand that. The question is more the kind of analysis you want to do: display some HR data next to some FIN data? No problem.

Now if you want to make complex calculations or things like that I understand it's easier to have all the data available in a single subject area.

Even in this case I maintain it would be easier for your management to have 2 subject areas. In the most reserved one, the one with the most strict access you also add the data from the other one you need.

So you have 2 subject area you can easily protect and one of the 2 has some overlapping columns with the seconds. But because it's the most restricted one in term of access by default your data are already well protected, and going down to table/column level permissions (that's the one you have to set) in the RPD Presentation layer you can setup a super security where only the 4 guys of your team can see the data actually coming from the other subject area.

This overlap of objects in subject areas doesn't cost you anything else than a drag & drop: all the logic is in the business model, which is already unique. The subject area is just a "pack" objects you make available to your users. It's easier to manage security (again, the permission part in the RPD) at the subject area level as it's 1 place instead than on 2323 tables inside a subject area (just because you have to set the same thing in many places => lot more chances to make it wrong).

3310714

Thanks guys for the insights. My intention was to join two result sets using a common column, like Employee_ID. For example, from HR subject area I will retrieve (Employee_ID, Address) and from FIN subject area I will retrieve (Employee_ID, Salary). In my Analyses I want to see (Employee_ID, Address, Salary). I was able to do this in SAP Business Objects using the Merge feature. But I don't think OBIEE has such feature.

[Deleted User]

Ah totally different subject then.

You basically asking about the core functionality and purpose of the RPD.

Because I pray to Cthulhu that you dont ask us to tell you how to write SQL in a direct database request to circumvent the metadata layer (the RPD).

Gianni Ceresa

Keep it simple !

Based on your previous posts the business model is unique and common between HR and FIN, so I also assume the model can ideally answer a report on address, employee ID and salary.

So just 1 click! (ok... 2)

Add the second subject area and make your report.

Or, going back to my previous answer, in one of the 2 subject area you add the required column: in HR you can add a "salary" column somewhere or in FIN you can add a "address" column.

Of course your business model must already be unique and linking all these things together, or the whole thread doesn't make sense (because the first option of single subject area means a single business model).

3310714

Many thanks Gianni, Christian, and Frog!

I was initially confused because the Add/Remove Subject Area was greyed out in my Analysis.

So I thought the only way to incorporate results is through the Set operations:

When I saw Gianni's screenshot where it's accessible, I searched and found this article ( ) which showed me the light! Now, I understand what you guys mean by subject areas based on SAME BMM.

So basically I have 2 options to do what I initially asked. One subject area with two folders OR two subject areas with one folder each. I'll get more understanding of the requirements before deciding the path to go.