Sunday, January 13, 2013

FYI: Overview on Object Level Security, Application Roles, and Inheritance in OBIEE 11g

8:18 PM

Share it Please
In Oracle Business Intelligence (OBIEE) 11g, Oracle has fundamentally changed how we map users to various security privileges.In OBIEE 10g, Object Level Security was enforced using the USER session variable, which mapped to a GROUP session variable. This created a list of possible 'groups', which a developer would then apply security restrictions to, in either Answers (Managed Privileges) and/or Security Managed in the repository.

A high level flow is outlined below:
































In OBIEE 11g, security authentication is enforced in the Weblogic Admin Server, and a user's security privileges are tied to their corresponding Application Roles in Fusion Middleware as shown in the diagram below:

The key take away is that object level security is applied to application roles and not groups.  Why application roles? In Weblogic and Fusion Middleware, we can actually assign certain privileges to an application roles - we call these 'Application Policies'. For example,  we can grant a certain application role the ability to 'edit the repository', or 'act as another user'. This feature, not possible in OBIEE 10g, now allows us to not only control what objects are being viewed, but also gives us the capability to control who can execute certain actions within the BI environment. This topic will be discussed in much greater detail in another guide.

Now let's go over the basic rules of Object Level Security for Application Roles in OBIEE 11g:

  • If a user is a direct member of an application role, they will have access to the reports allowed by that application role.
  • If a user is not a member of an application role, they will not have access to the reports allowed by that application role.
  • If a user is a direct member of two or more application roles with different security privileges for the same reports, the less restrictive security privilege is applied.
    • unless the user is explicitly denied. Explicit denial supersedes all security privileges.
  • If a user is a member of Application Role X, and Application Role X is a member of Application Role Y, the privileges in Application Role X supersede the privileges of Application Role Y

Let's cover each scenario in detail:

  • If a user is a direct member of an application role, they will have access to the reports allowed by that application role.
 
In this example, I granted Application Role 'Test Role 1' full control to folder 'Folder 1'. I then logged in as 'testuser1' who is a member of Application Role 'Test Role 1'. And as expected, testuser1 can read/write/edit/delete the folder.


  • If a user is not a member of an application role, they will not have access to the reports allowed by that application role.
In this example, I created 'Folder 2', only accessible by members of the 'BIAdministrator Application Role'. I then log in as a 'testuser1', which is not a member of the 'BIAdministrator Application Role'

As BIAdministrator:

As testuser1:


Note that in the above scenario, 'denying' the application role access accomplishes the same thing as taking no action onto the application role role (i.e. ignoring it completely)

  • If a user is a direct member of two or more application roles with different security privileges for the same reports, the less restrictive security privilege is applied.



























In this example, I created Folder 3, which grants 'read' access to Test Role 1 and 'modify' access to 'Test Role 2'. 'Testuser1' is a member of both 'Test Role 1' and 'Test Role 2'.

 
 

As expected, Testuser1 has modify rights to Folder 3 (noted by 'X', ability to delete), despite being a member of Test Role 1 which only grants the user read access








  • If a user is a direct member of two or more application roles with different security privileges for the same reports, the less restrictive security privilege is applied.
    • unless the role is explicitly denied


In this example, TestUser1 is a member of Test Role 1 and Test Role 2 and Test Role 3. Test Role 1 grants testuser1 open rights, Test Role 2 grants testuser1 modify rights and Test Role 3 is explicitly denied.
















As expected, testuser1 does not have access to Folder 4 because of Test Role 3

  • If a user is a member of Application Role X, and Application Role X is a member of Application Role Y, the privileges in Application Role X supersede the privileges of Application Role Y




























 
In this example, testuser1 is a member of application role 'Test Role 4'. Application role 'Test Role 5' is a member of application Role 'Test Role 4'. Test Role 4 grants 'open' privileges to Folder 5 and Test Role 5 grants 'full control' to Folder 5.

 
As expected, testuser1 only has read/open access to Folder 5 even though Application Role 'Test Role 5' grants full control. This is because direct inheritance overrides indirect inheritance








Even if the inherited role explicitly denies access to folder 5, the user will still be able to access folder 5 because the direct role grants read/open access:

Note how testuser1 has modify access to Folder 5 (noted by the 'X') , despite inheriting a role that is denied access to the same folder.




These basic rules can be applied to any hierarchy, no matter how complex. Think you've mastered these 4 basic rules? Identify the final privileges for User 1 in the scenario below:



Result:

  • User is a direct member of Role 1 and 2 and indirect member of Role 3, Role 4 and Role 5
  • User has no access to Dashboard A
  • User has open access to Dashboard B
  • User has full control of Dashboard C
  • User has no access to Dashboard E
  • User has open access to Dashboard D

keywords : object level security, obiee security, obiee application roles, obiee 11g security, weblogic application roles, obiee inheritance

16 comments:

  1. very good post on user groups and security.

    ReplyDelete
  2. Very clear explanation! Thank you!

    ReplyDelete
  3. John,

    As usual, an excellent job. Oracle documentation is misleading and plain wrong on this subject.

    ReplyDelete
  4. Every points regarding object level security was clear to understand.
    Regards,
    JAVA Training in Chennai|Best JAVA Training institute in Chennai

    ReplyDelete
  5. There are lots of information about hadoop have spread around the web, but this is a unique one according to me. The strategy you have updated here will make me to get to the next level in big data. Thanks for sharing this.<
    Regards,
    Hadoop Training in Chennai|Big Data Training in Chennai|Big Data Training

    ReplyDelete
  6. Excellent post!!! The strategy you have posted on this technology helped me to get into the next level and had lot of information in it.
    Python training in chennai

    ReplyDelete
  7. You have done really great job. Your blog is very unique and informative. Thanks. Devops Online Training | Data Science Online Training

    ReplyDelete
  8. Your blog is awesome.You have clearly explained about it.It's very useful for me to know about new things..Keep on blogging. Selenium Training in Chennai | Selenium Course in Chennai

    ReplyDelete
  9. Good post..Keep Sharing.! I'm working in brave technologies private limited. We are the leading low cost ERP software development company in chennai.

    ReplyDelete