OBIEE Security -Part 3 - Data Level Security

Data Level Security:

Data Level security controls rights to view data. Row level security is implemented by the BI server on the background automatically allowing users to see data or rows to which they are authorized to.

You can choose to set up row-level security in the repository, or in the database. Implementing row-level security in the repository provides many benefits, including the following:

• All users share the same database connection pool for better performance
• All users share cache for better performance
• You can define and maintain security rules that apply across many federated data sources

Setting up Data Level Security:

1. A aususer created and assigned BICONSUMER group

2. Create a User_country table

CREATE TABLE USER_COUNTRY

  ( USERNAME VARCHAR2(20),

COUNTRY VARCHAR2(25)

  )

3. Insert sample data

insert into user_country(username, country ) values ('WEBLOGIC', 'USA');

insert into user_country(username, country ) values ('USER1', 'IND');

insert into user_country(username, country ) values ('SAMPLEUSER', 'AUS');

insert into user_country(username, country ) values ('AUSUSER', 'AUS');

OBIEE Security -Part 2 - Object Level Security

Object Level Security:

Object level security deal with access restriction to various obiee objects for different application roles and users. Object level security is achieved by granting or denying access to application roles or user.

We can restrict access to following objects using object level security:

• Repository Objects
• Presentation Tables
• Presentation table columns
• Subject area
• Webcatalog objects
• Reports
• Dashboards
• Dashboard Pages
• Catalog Folders

Repository Level: you can set object level security at repository on presentation layer.you can grant/deny access to user/application roles to access subject area, table or column

In presentation layer go to properties of a subject area, Table or Column.

Select permissions.

Select ‘Show all users/application roles’

Here you can see all the users and application roles and properties such as read, read/write, no access and default.

OBIEE Security - Part 1

Overview of Security in Oracle Business Intelligence:

Oracle Business Intelligence 11g is tightly integrated with the Oracle Fusion Middleware Security architecture and delegates core security functionality to components of that architecture. Specifically, any Oracle Business Intelligence installation makes use of the following types of security providers:

Authentication provider that knows how to access information about the users and groups accessible to Oracle Business Intelligence and is responsible for authenticating users.

Policy store provider that provides access to Application Roles and Application Policies, which forms a core part of the security policy and determines what users can and cannot see and do in Oracle Business Intelligence.

Credential store provider that is responsible for storing and providing access to credentials required by Oracle Business Intelligence.

By default, an Oracle Business Intelligence installation is configured with an authentication provider that uses the Oracle WebLogic Server embedded LDAP server for user and group information. The Oracle Business Intelligence default policy store provider and credential store provider store Credentials, Application Roles and Application Policies in files in the domain.

Authentication: Each Oracle Business Intelligence 11g installation has an associated Oracle WebLogic Server domain. Oracle Business Intelligence delegates user authentication to the first authentication provider configured for that domain.

• The default authentication provider accesses user and group information stored in the LDAP server embedded in the Oracle Business Intelligence's Oracle WebLogic Server domain.
• The Oracle WebLogic Server Administration Console can be used to create and manage users and groups in the embedded LDAP server.

Authorization: After a user has been authenticated, the next critical aspect of security is ensuring that the user can do and see what they are authorized to do and see. Authorization is controlled by a security policy defined in terms of applications roles.

Application Roles represent a functional role that a User has, which gives that User the privileges required to perform that role. For example, having the Sales Analyst Application Role might grant a User access to view, edit and create reports on a company's sales pipeline.