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.

  • Secure Socket Layer (SSL)
    • Protocol providing security over the Internet for client-server applications to communicate across a network in a way designed to prevent eavesdropping and tampering.
  • SSL Certificate
    • An SSL certificate is a means by which web servers prove their identity to web browsers, allowing a secure site to communicate privately with the web browser via the HTTPS protocol. An SSL certificate is digitally "signed" by a certificate authority, such as GoDaddy or Thawte, that web browsers already trust. The signing of a SSL Certificate allows the web browser to verify the identity of a secure site before sending private personal information, such as bank account or credit card numbers. Webmasters and Network Administrators can purchase certificates from the certificate authorities, which verifies the identity of a Web Server or Application Server to varying degrees. Alternatively, for local networks or networks mainly transferring information internally to the organization, an SSL certificate can be "Self-Signed" by the organization, although this method is not deemed as acceptable for all Enterprise situations, nor is it accepted by all browsers.
  • OAuth
    • OAuth (Open Authorization) is an open protocol to allow secure API authorization in a simple and standardized way from desktop, web applications.
  • Web Server
    • Refers to either the hardware (the computer) or the software (the computer application) that helps to deliver Web content that can be accessed through the Internet/Intranet. The primary function of a web server is to deliver web pages on the request to clients using the Hypertext Transfer Protocol (HTTP). This means delivery of HTML documents and any additional content that may be included by a document, such as images, style sheets and scripts. The Apache httpd Web Server has been the most popular web server on the Internet since April 1996. Apache Web Server is the core structure for the Oracle HTTP Server.
  • Application Server
    • Refers a server that provides software applications with services such as security, data services, transaction support, load balancing, and management of large distributed systems. The term is often used for web servers that support the Java Platform, Enterprise Edition (JEE), however its use isn't restricted to Java. Oracle's main application server is WebLogic, IBM's WebSphere, etc.
  • Principals
    • Under enterprise middleware security models such as Oracle Fusion Middleware and those using the XACML protocol use the term "Principal" to encompass and object that can have privileges assigned to it. In the case of Oracle BI, a principal is a user, group, or application role. Users can be assigned to groups or application roles and application roles can be assigned to other application roles, etc. In order to define the object which can be assigned an authorization based privilege the term "principal" is used, in this case for user, group, or application role synonymously.
  • Comment Security / Visibility
    • Refers to the ability to restrict visibility or read-access to a comment created by the comment author. This applies to dashboard, view, and cell comments. By default comments are visible to "Everyone". Everyone, being no pre-defined group, application role, or other container within the BI System or BITeamwork. Comments are secured in the Add Comment Dialog Prompt using the secure lock icon button option and entering a principal (user or application role) to the privilege list before submitting a comment. Comment security cannot be adjusted after the comment is created. As of release 2.4 it must be deleted and recreated if security privilege settings desire modification.

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:

  1. Can Comment Visibility be Restricted to a single user or group? Yes.
  2. Can a Cell Comment be secured/restricted to a specific list of users?
    • This is controlled by the comment security feature when the comment is created.
  3. Can a Comment be secured to a specific list of users?
    • This is controlled by the comment security feature when the comment is created.
  4. If a user does not have access to create a comment do they still see the BITeamwork icons in the Global Header?
    • This is controlled by the BITeamwork Administrator who can restrict a user from seeing the BITeamwork icons in the Global Header or the Collaboration Pane.

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.

BITeamwork Initiated OAuth Flow with Social Vendor Application

The diagram below shows in proceedural detail how BITeamwork communicates with a Social Vendor Application

  1. To request authorization for a resource, the BITeamwork opens a web page on the user's browser. The user is shown the Social Vendor log in page.
  2. The end-user logs into the Social Vendor portal to authenticate themselves. Since this web page is hosted by the Social Vendor application on the Internet and interacted with directly by the end user, BITeamwork or the company's BI Application never finds out the user’s login credentials. By loggin in on the Social Vendor application page at this time the end-user is granting authorization to BITeamwork on their company's BI Application Server. Again, the user's Social Vendor application credentials are safely known only by the user and the Social Vendor portal.
  3. The Social Vendor portal sends an authorization code back to the web page open on the user's browser. This redirection (callback URL) after logging in to the Social Vendor portal and accepting the authorization page is now a web page on the BI Application server which is now read by the BITeamwork application. A status message will appear to the user showing success or error messages.
  4. After obtaining the authorization code, the BITeamwork passes back the authorization code back to the Social Vendor application transparently behind the scenes to obtain an access token.
  5. After validating the authorization code, the Social Vendor, again transparently behind the scenes, over the Internet, passes back a response access token. The response includes an access token which is stored by BITeamwork in addition to other pertinent user-specific information.
  6. The protected resources of the Social Vendor application, such as the ability to send a post/status, or read a social feed are now available to BITeamwork.

Most Social Vendors require a callback URL to receive the access token information for the Social application once it has been accepted by the user logged in to the BI Application. This is transparently handled by BITeamwork, however, as part of the initial installation and configuration of BITeamwork with a Social Vendor application such as Salesforce Chatter, a configuration reference is made on both applications. This is only done once by the administrator. The Social Vendors desire to keep their client's applications, credentials, etc. secure is part of their success. As such, when a response is returned by the Social Vendor it expects the receiving Web Server hosting the BI Application to be secure as well. This is secure socket layer (SSL) communication at the Web Tier.

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.

See also Securing the Web Tier

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:

  1. Leverage an Existing Web Tier within the Organization
  2. Add an SSL certificate to the JEE Application Server
  3. Add a Web Tier Server Application on the same physical server as the JEE Application Server
    • Examples of Web Tier servers are Apache, Oracle HTTP Server, and Microsoft IIS

Notice

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.