Oracle Analytics Cloud and Server

Welcome to the Oracle Analytics Community: Please complete your User Profile and upload your Profile Picture

Oracle Analytics Cloud: RPD Subject Area Security

Received Response
295
Views
5
Comments

Summary: Subject Area Security Model in OAC

Content (required):

I'm looking to implement an object level security model. For example purposes, I will reference 2 users (Alice & Bob), 3 Groups (HR: ReadOnly, HR: ContentDev, & Finance: ContentDev) and 2 Subject Areas (Headcount Analytics, Finance Analytics)

Setting the stage:

Alice is part of the HR: ReadOnly & HR: ContentDev groups.

Bob is part of the HR: ReadOnly & Finance: ContentDev groups.


The intent of these groups are as follows:

HR: ReadOnly (DV Consumer) - should have access to view DV content that was created with the Headcount Analytics subject area.

HR: ContentDev (DV ContentAuthor) - should have access to view & create DV content with the Headcount Analytics subject area.

Finance: ContentDev (DV ContentAuthor) - should have access to view & create DV content with the Finance Analytics subject area.


Goal behavior:

Bob is able to see content created with the Headcount Analytics subject area but is unable to create content with the Headcount Analytics subject area. He should be able to create content with the Financial Analytics subject area.

Alice is able to see content created with the Headcount Analytics subject area but is unable to see anything create with the Financial Analytics subject area and is unable to create any content with the Financial Analytics subject area.


Current Behavior:

If we restrict the Headcount Analytics subject area in the RPD permissions - we remove the ability for Finance: ContentDev users to create with the subject area, however, if those users are also members of HR: ReadOnly it removes all visibility of data within the content created with the Headcount Analytics subject area.


Version (include the version you are using, if applicable):


Code Snippet (add any code snippets that support your topic, if applicable):

Answers

  • You say who is member of what group, what these groups are supposed to allow their members to do, what is the ideal behavior and then apparently complain about the current behavior. But what does your current security model looks like? Because yours is an extremely focused question on your own specific security model, but you aren't saying anything about what you did to implement it...

    And also, when you talk about groups, do you really mean groups? Because groups aren't an element of the OAC security model: you reference users or application roles, groups at best are members of application roles and stop there.

  • Joshua C. Stewart
    Joshua C. Stewart Rank 5 - Community Champion

    Hi Gianni,

    For additional context, the groups are mapped to custom application roles, so I've referenced to them synonymously.

    I have Presentation Layer permissions with the following configuration

    AuthenticatedUser -> No Access to Headcount Analytics & Finance Analytics (otherwise all subject area' are accessible)

    Finance: ContentDev -> No Access to Headcount Analytics & Read Access to Finance Analytics

    HR: ContentDev -> No Access to Finance Analytics & Read Access to Headcount Analytics

    Best,

    Josh

  • edit: OP first reply was that my request for more info was pointless and not helping him at all. Now he did decide to provide more details and "look good" in the forum after this reply was posted (his reply at 21:16, my reply at 21:21 and him editing his reply at 21:32 CET). I will do as said and stay away from his thread. My security models keep working as expected...


    original reply:

    Well, my security models work, does this contribute more to the discussion?

    I'm just saying that you aren't providing enough information to give you a direct answer, and I don't have any crystal ball in stock and playing a guessing game isn't going to help anyone.

    But it's a free open forum, don't worry I will stay away from your threads.

    Have a good one

  • Try using the classic catalog permissions per Subject Area. Deny to the groups which should not be able to author.

    Administration

    Security -Manage Privileges

    Manage privileges and rights given to users and groups.


    The path is <OAC URL>/ui/analytics/saw.dll?Admin

  • Joshua C. Stewart
    Joshua C. Stewart Rank 5 - Community Champion

    Hi Bret,

    Thank you for the suggestion. We've tried this and it gets us 95% of the way there. While setting the Subject Area permissions in classic restricts user's abilities to select the Subject Area during a 'Create Workbook' process flow.


    However, the limitation with this configuration is with workbooks that are already created. For example, if Bob is part of the Finance: ContentDev application role, he is unable to create a net new workbook with and of the Headcount Analytics subject area. However, if Bob has access to a workbook that Alice created with the Headcount Analytics subject area, then he is able to explore the Headcount Analytics data.


    We can handle 99% of these cases via Folder security, however, we are looking for a configuration that would absolutely prevent Content Authoring with Subject Area's that user's aren't explicitly granted Content Author access to.


    The only security configuration I've seen that absolutely removes the ability to author content in a specific subject area, is in the RPD. However, that goes a step too far and removes the ability to read any data from the subject area.


    Best,

    Josh