How to review security options and control data in OBIEE

 

All businesses require some sort of security model. Even the most basic security architecture is comprised of three elements:

•  Authentication – does a user have access to the application?

•  Authorization – what application object permissions has  the user been granted?

•  Row-Level Security – which rows can the user see in a table?

Once these basic concepts are understood, it is possible to build an application topology within Oracle Business Intelligence to meet even the most complex of security requirements.

Fortunately, Oracle Business Intelligence leverages industry standard concepts to implement security requirements necessitated by business processes.  If you have familiarity with security in another application, the concepts discussed herein will seem very familiar.  If not, that’s okay, too. The  concepts discussed here are pretty straight forward. 

Authentication

User authentication is the process by which an application determines if a specific username and password combination has been granted login  access.  

•   All businesses require that a given application check if a user has been granted the ability to login.

•   Within the OBI architecture user authentication can occur at three different points:  the Oracle BI Presentation Server, the Oracle BI Server, or an external application (database, LDAP or via Single Sign On setup) 

    o   SSO is covered in the following Lesson

It is also possible to pass username and password information from the Oracle BI Presentation Server to the Oracle BI Repository Server for Authentication using the variables :USER and :PASSWORD. 

The Oracle BI Server has the capability to take any username and password combination and authenticate it against username and password combinations stores within the Oracle BI Repository or send them to an external source for authentication, such as a database or LDAP. 

•  When a user logs into the Oracle BI Repository using the Oracle BI Administration tool, the Repository itself authenticates the user.  The user must be created within the security section of the Repository.  Only those users who have a business function that requires them to have access to the Repository should be created in this section. 

•  The Administrator user must always exist and cannot be deleted although its password may be altered.

System Variables and Initialization Blocks

• During the login process the System Variables :USER and :Password are populated with the username and password by the Oracle BI Presentation Server. These are the only variables where information is passed from the Oracle BI Presentation Server to the Oracle BI Server. The values used to populate all other

variables are stored within database tables.

•  How does the application access those tables? The Oracle BI Server uses Initialization blocks, code passed to a database, LDAP server, etc. to populate Oracle BI Server variables with information. In this particular case we are talking about user groups.

•  How does the Oracle BI Server know who’s information to fetch from the database? The variables are then populated with different information based on each session (:USER from the Oracle BI Presentation Server), so when a user logs in, the information pulled by the Initialization Block is specific to that user alone.

•  The same initialization block can be used to populate many different System or Session Variables.

Authorization

Authorization is the process by which a user is granted privileges to application objects and by which the level of access is defined. 

• Users are not explicitly granted privileges, but rather are assigned to groups (roles, responsibilities, etc.) that are associated with specific privileges. 

• Much like Authentication, Authorization can occur at several different points. Authorization can occur through the Oracle BI Presentation Server, the Oracle BI Server or an external application (database, LDAP, etc.). 

• Oracle Business Intelligence Server will pass the authenticated username to an external database or LDAP to retrieve the association between users and groups.

 

User & Group Setup Options - Repository

1 Users can be added to the repository and assigned to group(s).   

Pros:

•  Quickly add a user to repository. 

Cons:

•  Must have access to repository to add a user and/or group. 

•  Have to manually add a user to a group. No mass update option unless adding a group within a group. 

2 Under the Logons tab you can specify a username and password for each database in the physical layer. 

3 When password expires a user will not be allowed to login and will have to contact an administrator to change the password. 

User & Group Setup Options - Database

1 Use an Initialization Block and set up session variables for your users.  By storing the user information within a database table, maintenance and mass updates are easier. 

2 The order of your select statement and the assigned variable are important as these are a 1 to 1 relationship.  For example, in the example above, the DISPLAYNAME will be populated with the full_name value for each session. 

1.  It’s a best practice to use a database table for user security, including repository and webcat group membership. 

2.  Utilizing writeback for user maintenance is a cheap & easy method without having to create a custom application. 

User Session Variables

1 The variables with a red question mark indicate that they are reserved variable names. 

These variables perform specific functions:

• USER = The id that the user used to login to the Web Server 

• DISPLAYNAME = The name that is displayed after logging into the Web Server in the ‘Welcome [DisplayName]! 

• EMAIL = Currently, does not work as intended within OBIEE.  This is supposed to populate an Email device under ‘My Account’; however, this field can still be used by Delivers to send emails. 

•  LOGLEVEL = The level of logging for the individual user. 

• PORTALPATH = The default dashboard the user sees after logging in. 

• GROUP = The repository groups a user belongs to. 

• WEBGROUPS = The web catalog (front end) groups a user belongs to. 

User & Group Security Options - Repository

1. Utilizing the GROUP session variable will place the user in the assigned repository group during their session.  The repository group name must exist in the repository.  In addition, you will not see an entry in the repository group since this is a session variable. 

2. Utilizing the WEBGROUPS session variable will place the user in the assigned webcat group during their session. The webcat group name must exist in the repository.  In addition, you will not see an entry in the webcat group since this is a session variable. 

Use the Session Manager to view the session variable values assigned to each user. 

User & Group Security Options - Webcat

1. Create groups and assign the groups the appropriate permissions throughout the webcat. Do not assign individuals access to webcat folders, pages, dashboards, reports, etc as managing this level of granularity is difficult and prone to error. 

 

2. Before creating a new dashboard create a folder with the same name and store reports and prompts by page under this folder. Assigning security to these folders will also assign similar permissions to each dashboard page. 

1. Creating a group called ‘Authorized Users’ to allow access to OBIEE will ensure each user has been setup to access the application.  This is especially important if

using Single Sign-On (SSO) to authenticate users.  

 

2. Creating a ‘Denied Access’ group and revoking access to OBIEE is an easy way to block prior individuals from using the application.  When a database is used for authorization, add the ‘Denied Access’ group to the WEBGROUPS column to lock

out the person. 

Create a user in the repository called test_user and experiment with granting and revoking access to this user in the webcat.  Insure the logging level is set to 2 for this user or following steps will not work.

 

Row-Level Security - Data Visibility

Row-Level Security is the process of filtering the data on a row-by-row basis that a specific user can access.  It is also defined using a combination of session variables and group privileges within the Oracle BI Repository.

•  Row-level Security is most often used to limit the view of sensitive data, like financial or compensation information, while not explicitly denying access to all

the information.

•  For example, in many cases a business process requires that a sales person see his or her compensation information without being able to view his or her peer’s

information.

•  Additionally, the business may require hierarchical Row-Level Security. It could be the case that the access of the manager of the salesperson in the previous should be limited to data pertaining to his or her direct reports.

•  Generally Hierarchical Row-Level Security is implemented from an organization or position perspective. Due to the complexity of this task, it is  unfortunately outside the scope of this class. 

Data Visibility

1. Control security by adding Filters to a group within the repository.  Each group can have their own security filters.  The security filters are appended onto the ‘WHERE Clause’ that  is submitted to the database. 

 

2 Typically Filters are added to the Fact based tables in the Presentation or Business Model Layer.  

Add the test_user to the Region Manager group.  Next, add Filters for the Paint subject area to filter Region to ‘EASTERN REGION’ (Note: ‘Eastern Region’ will not

work).  Finally, create a report using attributes from these table in Answers and view the log to make sure  the filter has been applied.