Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

Thursday, July 3, 2014

OBIEE 11g Security Demo Link

This is very useful link, nicely explained about OBIEE 11g Security. Thanks to Integrigy !!

https://www.youtube.com/watch?v=kgA9Ly56rRc

-Asifkhan P.

Saturday, February 22, 2014

Oracle Business Intelligence 11g Security (Part 3)

One of the key enhancements in OBIEE 11g are the changes in Security Architecture. OBIEE 11g implements the common security architecture as the rest of the Fusion Middleware stack. While this approach has many advantages , it does represent a significant shift in both the approach and architecture of OBIEE for authorization and authentication of users.
Oracle Platform Security Services
The architectural components of Fusion Middleware that OBIEE 11g leverages are the Oracle Platform Security services (OPSS) and WebLogic authenticators. These are the components that FMW usees to provide a common security framework across the many Oracle applications that run on FMW, including OBIEE 11g and Fusion Applications.
OPSS is standards based, portable, integrated enterprise grade security framework for Java applications. OPSS provides an abstraction layer in the form of standards-based application programming interfaces (APIs) that insulate developers from security and identity management implementation details.
OPSS is used as security platform by Fusion Apps & Fusion Middleware including WLS, OES, SOA & WC. 
Key Security Changes for Release 11g:
Some of the key changes in OBIEE security in 11g are
1.   User and Groups are no longer defined in RPD
2.     User Profile is derived from LDAP server
3.     RPD is protected by RPD Password
4.     RPD is encrypted
5.     Introduction of Applications Roles
6.     User Administrator and Group Administrators not hard-coded in RPD
7.     Administrator user not used for Inter-Process Communication (component to component)
8.     Credential Store storage mechanism
OBIEE 11g provides a scalable default security mechanism available for immediate implementation after installation. The default security mechanism provides controls to manage users and groups, permission grants and credential store. Following are the security controls that are available after the installation.
1.     An embedded LDAP server in WebLogic available to store users and groups known as “Identity Store”
2.     A file to store the permission grants information known as the “Policy Store”
3.     A file to store user and system credentials for inter process communication known as the “Credential Store”.
security_1.jpg

OPSS

Oracle Platform Security Services


Oracle Platform Security Services (OPSS) provides enterprise product development teams, systems integrators (SIs), and independent software vendors (ISVs) with a standards-based, portable, integrated, enterprise-grade security framework for Java Standard Edition (Java SE) and Java Enterprise Edition (Java EE) applications.
OPSS provides an abstraction layer in the form of standards-based application programming interfaces (APIs) that insulate developers from security and identity management implementation details. With OPSS, developers don’t need to know the details of cryptographic key management or interfaces with user repositories and other identity management infrastructures. Thanks to OPSS, in-house developed applications, third-party applications, and integrated applications benefit from the same, uniform security, identity management, and audit services across the enterprise.
OPSS is the underlying security platform that provides security to Oracle Fusion Middleware including products like WebLogic Server, SOA, WebCenter, ADF, OES to name a few. OPSS is designed from the ground up to be portable to third-party application servers. As a result, developers can use OPSS as the single security framework for both Oracle and third-party environments, thus decreasing application development, administration, and maintenance costs.

Oracle Business Intelligence 11g Security (Part 2)

Following figure shows the overall security infrastructure for Oracle Business intelligence, with end users connecting to applications that are hosted in the Oracle WebLogic Server JEE environment, which in turn connect to the Oracle BI Presentation Server and Oracle BI Server. The Oracle BI Server then authenticates users through the Security Service hosted in the WebLogic Server, which uses a feature called Oracle Platform Security Services to connect to embedded and external authenticators and directory services.

 Oracle Business Intelligence security infrastructure


image

When end users navigate to the Oracle Business Intelligence web site and enter in their username and password in order to view a dashboard at a high level, this is the process that takes place:
1.   Users enter their usernames and passwords into the analytics application (http://obisrv1:9704/analytics) that runs on WebLogic and is displayed in their browser.
2.   The User ID and password are then sent to Oracle BI Presentation Services.
3.   Oracle BI Presentation Services uses these credentials as part of the ODBC connection string that it uses to connect to the Oracle BI Server.
4.   The Oracle BI Server calls the Security Service (bimiddleware) to authenticate these user credentials.
5.   The Security Service calls Oracle Platform Security Services (OPSS), to authenticate users against the embedded LDAP server or whatever external directory has been connected to OPSS, and to establish which LDAP groups, application roles, and application policies have been granted to the users.
6.   Finally, the Security Service passes this information back to the Oracle BI Server, and the BI session is considered authenticated.
OPSS, thus, is central to the entire authentication, authorization, and security process. Let’s explore which services OPSS provides and how it facilitates the connection between Oracle Business Intelligence security infrastructure and your organization’s security arrangements.
Oracle Platform Security Services
Because organizations typically have diverse security requirements, Oracle Fusion Middleware, on which Oracle Business Intelligence is built, uses a security abstraction layer called Oracle Platform Security Services (OPSS) to connect to companies’ various authenticators and other security frameworks. Instead of having Fusion Middleware, and therefore Oracle Business Intelligence, connect directly to directory servers such as Microsoft Active Directory, it connects via OPSS, which has a standard interface over this directory through a “provider.”
Following figure shows an overview of OPSS and how it uses providers to extend connectivity to these services.

image

At a high level, OPSS provides three abstracted services for OBIEE and for other Fusion Middleware–based applications:
image   Identity store   By default this is set to use an embedded WebLogic Server LDAP server, but it can be configured to connect to Microsoft Active Directory, for example.
image   Policy store   This contains details of application roles, application policies, and the permissions they use, which by default are stored in a file called system-jazn-data.xml but can be redirected to an LDAP or file-based policy store.
image   Credential store   This replaces the external one that OBIEE 10g used, which contains the usernames, passwords, and other credentials that system services require.

Oracle Business Intelligence 11g Security (Part 1)

Oracle Business Intelligence Security can be divided into two broad areas: controlling access to the components within the BI domain (resource access security) and controlling access to business source data (data access security).

Oracle BI integrates with Oracle Fusion Middleware’s security platform.
• Oracle WebLogic Server Administration Console
– Management of users and groups for the embedded LDAP server that serves as the default identity store
• Oracle Fusion Middleware Control
– Management of policy store application roles that grant permissions to users, groups, and other application roles
• Oracle BI Administration Tool
– Management of permissions for Presentation layer objects and business model objects in the repository


Oracle BI Default Security Model

During installation, three Oracle BI security controls are preconfigured with initial (default) values to form the default security model:
• Identity store
– Contains the definitions of users, groups, and group hierarchies required to control authentication
• Policy store
– Contains the definition of application roles, the permissions granted to the roles, and the members (users, groups, and applications roles) of the roles
• Credential store
– Stores security-related credentials, such as user name and password combinations, for accessing an external system (such as a database or LDAP server)

Default Security Realm

A security realm is a container for the mechanisms that are used to protect WebLogic resources. This includes users, groups, security roles, security policies, and security providers. Whereas multiple security realms can be defined for the BI domain, only one can be active (that is, only one can be designated as the default realm at any given time). There is a single default security realm named myrealm.


Default Authentication Providers

An authentication provider establishes the identity of users and system processes, transmits identity information, and serves as a repository from which components can retrieve identity information. WebLogic Authentication Provider is used by default. There is a default WebLogic Identity Assertion Provider, which is used primarily for Single Sign On


Default Users


weblogic: is the administrative user. After installation, a single administrative user is shared by Oracle BI and Oracle WebLogic Server. The same user name and password that were supplied during the installation process are used for both. The password is also provided during installation and afterward can be changed by using the administration interface for the identity store. In the default security configuration, an administrative user is a member of the BIAdministrators group.

BISystemUser : Oracle BI system components now establish a connection to each other as BISystemUser instead of as the Administrator (the latter being the practice in earlier releases). Using a trusted system account such as BISystemUser to secure communication between components enables you to change the password of your deployment’s system administrator account without affecting communication between these components. The name of this user is the default and can be changed, or a different user can be created for the purpose of interprocess communication. This is a highly privileged user whose credentials should be protected from nonadministrative users.


Default Groups

Groups are logically ordered sets of users. Creating groups of users who have similar needs for access to system resources enables easier security management.

BIAdministrators group: Members have the equivalent permissions of the Administrator user of earlier releases with the exception of the ability to impersonate.
BIAuthors group: Members have the permissions necessary to create content for other users to use.
BIConsumers group: Members have the permissions necessary to use (or consume) content created by other users.  By default, every Oracle BI authenticated user is part of the BIConsumers group and does not need to be explicitly added to the group.



Default Application Roles


An application role defines a set of permissions that are granted to a user or group. Application roles are defined in Fusion Middleware Control which can be accessed via http://<machine name>:7001/em. To access the Application Roles page, right-click coreapplication in the left pane and select Security > Application Roles

Default application roles include:
• BISystem: Grants the permissions necessary to impersonate other users. This role is required by Oracle BI system components for intercomponent communication.
• BIAdministrator: Grants the administrative permissions necessary to configure and manage the Oracle BI installation. Any member of the BIAdministrators group is explicitly granted this role and implicitly granted the BIAuthor and BIConsumer roles.
• BIAuthor: Grants the permissions necessary to create and edit content for other users to use (or to consume). Any member of the BIAuthors group is explicitly granted this role and implicitly granted the BIConsumer role.
• BIConsumer: Grants the permissions necessary to use (or to consume) content created by other users

image


Default Application Policies

Application policies are the authorization policies that an application relies upon for controlling access to its resources. Application policies are defined in Fusion Middleware Control. To access the Application Policies page, right-click coreapplication in the left pane and select Security > Application Policies


Permission Inheritance

Permissions granted explicitly to a user take precedence over permissions granted through application roles, and permissions granted explicitly to the application role take precedence over any permissions granted through other application roles.



Set Row-Level Security (Data Filters)

Data filters are a security feature that provides a way to enforce row-level security rules in the repository. Data filters are set up in the repository using the Administration Tool and are applied for a particular user or application role. You do not set up data filters if you have implemented row-level security in the database, because in this case, your row-level  security policies are being enforced by the database rather than by Oracle BI Server.

Data filters can be set for objects in both the BMM layer and the Presentation layer.  Applying a filter on a logical object affects all Presentation layer objects that use the object.  If you set a filter on a Presentation layer object, it is applied in addition to any filters that might be set on the underlying logical objects.

It is a best practice to set up data filters for particular application roles rather than for individual users.


Set Query Limits


Use the Query Limits tab to control the following activities:
• Control runaway queries by limiting queries to a specific number of rows received by a user or role.
• Limit queries by maximum run time or to time periods for a user or role.
• Allow or disallow the populate privilege (this is primarily used for Marketing applications and is beyond the scope of this course).
• Allow or disallow execution of direct database requests for specific database objects. To access the Query Limits tab, open the Identity Manager, click the Application Roles tab, double-click an application role to open the Application Role dialog box, and click Permissions.


Set Timing Restrictions

You can regulate when users can query databases to prevent users from querying when system resources are tied up with batch reporting, table updates, or other production tasks.
To restrict access to a database during particular time periods, click the ellipsis (…) button in the Restrict column to open the Restrictions dialog box. Then perform the following steps: 
1. To select a time period, click the start time and drag it to the end time.
2. Access:
- To explicitly allow access, click Allow.
- To explicitly disallow access, click Disallow.