Security within BITeamwork can be seen as a separate management responsibility than that of the hosting BI Application into which BITeamwork is the guest plug-in. This document provides answers and insight into how BITeamwork is integrated into Oracle BI 11g from a security perspective. This integration not only includes privilege control for BITeamwork functionality but aspects around securing the architecture for accessing Social Vendor applications such as Salesforce Chatter.
If you have a more complex issue, we hope that you are an Enterprise Edition customer so that we can support you fully. You can also try accessing our support site for further assistance beyond this document.
The few definitions listed below will provide additional insight to some of the jargon used in this document. Understanding the information in this Security Guide is critical for the BI Administrator.
Security within BITeamwork seeks to initially leverage the inherent security of BI Application as the first line of privilege restriction. Even though no aspect of the native BI Application controls the security of BITeamwork and vice-versa, the native BI Application is the host and BITeamwork is the guest. An example of this would be if a user is restricted from having access to the Accounts Receivable dashboard, then that user will have no access to view the dashboard, and thus have no access to any comments on that dashboard.
There are a few common questions regarding Comment Security:
The majority of the questions listed here are answered by the general concept mentioned above regarding BITeamwork acting as a guest to the native BI Application. The other questions can be answered by the concept of data and row level security features of the BI Application.
The other important item to keep in mind is that all Cell Comments persist based on the original context in which they were created. This applies to standard navigation but also to security. If a Cell Comment was left on a row or column for which a user does not have privileges to view then the comment does not show for that user.
OAuth (Open Authorization) is an open protocol to allow secure API authorization in a simple and standardized way from desktop, web applications. Social Vendors implement the OAuth 2.0 Authorization Framework, so users can authorize applications to access the Social Vendor's resources on their behalf without revealing their passwords or other credentials to those applications. BITeamwork one of these applications that leverages the OAuth protocol to communicate with Social Vendors to enable the Social BI component of the product.
OAuth is often described as a 'valet key for the web'. In the same way as a valet key gives restricted access to a car, allowing the valet to drive it but not open the trunk or glovebox, OAuth allows a client application restricted access to your data at a resource server via tokens issued by an authorization server in response to your access grant.
OAuth simplifies authorization of Social Vendor applications by preventing the need to store or transfer a user's credentials across the network. The diagram shown below illustrates how accessing the Social Vendor application transpires using the OAuth protocol.
The diagram below shows in proceedural detail how BITeamwork communicates with a Social Vendor Application
All Business Intelligence systems are based on the Middle Tier (aka Business Tier) of the applications stack. Oracle Business Intelligence 11g, out-of-the-box installs on a *Nix (Linux/Unix) or Windows Operating System and is configured on either the Oracle WebLogic or IBM WebSphere Java (JEE) Application Server. These JEE application servers include a partial web server which allows for HTTP traffic to send and receiving requests. The BI Application also depends on a database stack to retain its metadata repositories. This architecture is represented by the diagram below where the Client Tier is the user's browser, the Web/App Tier is the JEE Application Server, and the Database Tier houses the metadata repository for the BI Application.
In an enterprise Business Intelligence installation the ability to add a Web (HTTP) Tier, also referred to as a Presentation Tier, which handles traffic to and from the application server, is the best practice and also recommended. This is referred to as an N-Tier architecture (3-Tier to be exact), where each of the nodes/applications reside on separate servers on the network.
As seen in the Client-Web-Application-Database Tier diagram above, it is the Web Tier which is the easiest server to apply the SSL Certificate so that secure protocol can be achieved. In order to comply with Social Vendor requirements, and thus the ability to integrate BITeamwork with the current Social Vendor option, either the Web Tier or the Application Tier requires an SSL certificate to enable secure protocol. If your BI Administrator or BITeamwork administrator is new to the concept of security a web application, here are the two initial options to confirm or accomplish this requirement:
SSL configuration is only required if leveraging the Social Vendor functionality. Again, this is a requirement from the Social Vendor application integration and not required by BITeamwork for other functionality.
If you have a questions regarding this concept, we hope that you are an Enterprise Edition customer so that we can support you fully. You can also try accessing our support site for further assistance beyond this document.