This page intentionally left blank CHAPTER 14 Securing Oracle BI Content and Data 535 536 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence n Chapter 13, we talked about securing access to the Oracle Business Intelligence (BI) server itself. Much of the discussion focused on authentication and authorization, as these two topics represent the critical and important first steps of the security lifecycle. Now let’s move into the realm of securing the actual data and content served up by Oracle BI. At this point, Oracle BI knows who the end user is and knows the groups in which the user belongs. It will use this information to make sure that the end user sees only the content and data he or she is supposed to see. To run a report or dashboard successfully, the user must have access both to the web content (the dashboard or report definition) and the data being served up by that report. The web catalog contains the definition of all of the dashboards and reports in the system. It does not contain any actual data. Securing web catalog content involves defining who can view or edit dashboard or report definitions, and this is covered in the first part of this chapter. Next, it focuses on securing the data presented through the web catalog content. Security must be applied to the data that is surfaced in the reports and dashboards defined in the web catalog. Fine-grained security for the data focuses on the security features that Oracle BI can add to the data and the features Oracle BI can leverage from the Oracle database. You’ll learn about setting up Oracle BI to leverage Virtual Private Database (VPD) and fine-grained auditing (FGA). Lastly, a number of necessary and often desirable Oracle BI features give users additional privileges required for performing specific tasks. These features have obvious security implications, and the chapter concludes by examining these features and identifying areas you may need to explore. Securing Web Catalog Content To run a report, you need permission to access both the report definition, or web catalog content, and the data that will be presented in the report. When we refer to the web catalog content, we are specifically referring to the definitions of the objects. So having read access to web catalog content means that you have read access to the report definition. NOTE BI Publisher content is secured in a way that’s slightly different from all other types of content, because BI Publisher exists as both a stand-alone product and as an integrated component of Oracle BI. BI Publisher will be discussed last in the chapter. Until then, you can assume that unless BI Publisher is specifically mentioned, we are referring to securing non–BI Publisher content. Content security policies can be applied to users or groups. It’s best to start by securing content at the group level for two reasons: First, this is much easier to manage, because you are working with a much smaller set of policies. For example, an organization of thousands of users might have only 50 distinct groups of users, and 50 policies is much more manageable than thousands. Second, web catalog security policies cannot be applied to a user until the user has logged into Oracle BI for the first time. No matter what type of authentication you use (internal or external), the Oracle BI presentation server does not know about the user until the user logs in for the first time. Let’s assume, for example, that we want all object-level permissions to be accomplished via direct grants to the user. Before the user logs in for the first time, the user does I Chapter 14: Securing Oracle BI Content and Data 537 not exist in the web catalog, making it impossible to create the object-level grants in Oracle BI. The first time the user logs in, he would have access to publicly available objects only. After this first login, however, the administrator would be able to make the necessary object-level grants. Web Catalog Groups As mentioned, it is a best practice to apply security policies first at the group level—specifically for web catalog groups. In Chapter 13, you saw that groups are defined in the RPD and owned by the BI server. Web catalog groups are defined in the web catalog and owned by the presentation server. RPD group membership determines data-level security, because the BI server is responsible for retrieving and processing all data. Web catalog group membership determines web catalog content security because the presentation server is responsible for protecting all web catalog content. Folder-based Security Before we begin an in-depth discussion on securing web catalog content, let’s review the web catalog itself. The web catalog consists of all the definitions of reports and dashboards in your Oracle BI system. You access the web catalog in two main ways: through the web interface and using the Catalog Manager client-server tool. The web interface is useful for report developers to organize their content and perform basic administration, including security administration. Catalog Manager is useful for performing larger scale administration tasks. For example, you might use Catalog Manager to promote a new dashboard and all of its supporting content from the development server to the production server. At the OS level, the web catalog is actually a directory full of XML files. Each report and dashboard gets its own XML file. The structure of the web catalog at the OS level exactly matches what you see in the web interface or in Catalog Manager. NOTE Modifying the XML files that make up the web catalog is supported only via Catalog Manager—direct editing of the files using an XML editor or any other editor is not supported. As mentioned, all content is stored in folders. Security can be applied at the individual object level or at the folder level. This is analogous to securing a file system—files and folders can have read or write permissions granted to specific users or groups. Oracle BI supports the following permissions: Read View an object. Change/Delete Modify or delete an object. Also, with Change/Delete permissions on a folder, you can create new objects in that folder. Full Control Read access, Change/Delete, and the ability to assign permissions. No Access No access to an object. Traverse Folder View objects at a lower level. For example, you might want to restrict access to /shared/SHReports but grant access to /shared/SHReports/public. In this case, you would need traverse folder permission on /shared/SHReports. ■ ■ ■ ■ ■ 538 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence A detailed explanation of these permissions, complete with examples, is available in Chapter 8 of the Presentation Server Administration Guide (Oracle BI Documentation Library: www.oracle.com/technology/documentation/bi_ee.html). Here is one point worth citing from the documentation: “Explicitly denying access takes precedence over any other permissions or privileges.” This is a very useful feature. If a group of users cannot be allowed to see certain web content, you can use No Access permission. This will always guarantee that these users will not be able to access to that content, no matter what permissions they might have inherited via group membership or parent folder permissions. iBot Security Simply put, an iBot is a job. It might be a simple scheduled job: Deliver report A to user B every Friday. It could also be a rather complex conditional job: If criteria A is met, deliver report B to the users defined by report C. Users create iBots via the web interface, and these are submitted to the scheduler service. The scheduler service will handle executing the scheduled job by submitting requests to the BI server on behalf of the user who created the iBot. When the job is complete, the scheduler service returns the results to the appropriate delivery profile. Let’s run through a few of the specifics. To create an iBot, you need access to the “Access to Delivers” system privilege. Being granted this permission allows you to access to the Oracle Delivers feature of Oracle BI—in other words, it lets you create iBots. When you attempt to open, edit, or save an iBot, the basic rules of web content security apply. In general, iBots are treated like any other object in the web catalog; however, you will notice two differences. The first difference involves where iBots are stored in the web catalog. Normally, you can store an object in your personal folder or in a shared folder to which you have Change/Delete or Full Control permission. With iBots, your storage location is determined by whether you are making the iBot available for subscription. If you do not allow subscriptions, the iBot can be saved only in your personal folder. The iBot definition will be stored in a hidden subfolder, called _iBots, in your personal folder. You will be the only one who can edit the definition of this job, but you can still specify additional recipients. These recipients will get results, but they will not have access to the job definition. If you decide to publish the iBot for subscription, the job must be stored in the shared iBots folder. Additionally, if you allow a group or user to subscribe to a scheduled job, the user is automatically granted read access to the job definition. The second major security consideration when working with iBots is the notion of data visibility. Data visibility is defined on the General tab on the Create iBot web interface, as shown in Figure 14-1. Three options can be set for data visibility, although only two choices will ever be presented at any one time. iBot Data Visibility Options The first option is to set the data visibility to Personalized. This is the default setting, and it creates the report using the permissions of the recipient. The recipient receives the data as if she had run the report herself. Assume, for example, that Beth creates an iBot and lists David as a recipient. When the data visibility is set to Personalized, the results that are generated and delivered to David using David’s permissions. The second option is to set the data visibility to Not Personalized (Use iBot Owner’s Data Visibility). This runs the report with the permissions of the iBot owner and then delivers the result of the report to each recipient. Keep in mind that the recipient might be getting data that he might not normally be allowed to see. It is analogous to the iBot owner running a report, downloading a PDF copy of the results, and then e-mailing that PDF to each recipient. This option is available for Chapter 14: Securing Oracle BI Content and Data 539 non-administrative users who have been granted the permission Publish iBots For Subscription or the permission Deliver iBots To Specific Or Dynamically Determined Users. The third option is to set the data visibility to Not Personalized (Use The Run As User’s Data Visibility). This is similar to the second option and requires the same permissions, but it also requires the user to be a Presentation Server Administrator. The difference here is that the iBot owner can run the report as any user, not just the iBot owner, and then deliver the results. Securing BI Publisher Catalog Content BI Publisher catalog content is different from the rest of Oracle BI content in several ways. These differences stem from the requirement that BI Publisher exist as both a stand-alone product and as a component of the Oracle BI Enterprise Edition suite. For example, when used as a standalone product, BI Publisher needs to have its own identity management infrastructure. When operating as part of the larger Oracle BI suite, it would be better to have an integrated security infrastructure. An awareness of these types of differences is extremely helpful as you plan your BI Publisher deployment. BI Publisher supports a number of different security models, including BI server security, BI Publisher internal security, eBusiness Suite security, and Lightweight Directory Access Protocol (LDAP). For our discussion, we are using BI server security, as that is the recommended strategy when using BI Publisher and Oracle BI together. All groups in BI Publisher are actually BI server RPD groups. In fact, both BI Publisher catalog content security and data source security are controlled using RPD groups. In addition, access to BI Publisher catalog content is always done at the group and folder level. This is different from access in Oracle BI, where security can be controlled at the group and folder level or at the user and object level. The final difference is that BI Publisher permissions are controlled completely by membership is special system groups. Membership in these system groups must be directly granted for the permission to be effective. The membership cannot be granted via membership in some other group. These groups are as follows: XMLP_ADMIN The administrator group XMLP_DEVELOPER Can create and edit reports XMLP_SCHEDULER Can schedule reports ■ ■ ■ FIGURE 14-1 The General tab in an iBot definition 540 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence XMLP_ANALYZER_EXCEL Can use Excel Analyzer functionality XMLP_ANALYZER_ONLINE Can use the Online Analyzer XMLP_TEMPLATE_DESIGNER Reserved for a future feature This section has presented only half of the security requirements: the web catalog content definition as well as the data presented through that content must be protected. The next section focuses completely on securing the data presented through Oracle BI. Conveying Identity to the Database As mentioned in Chapter 13, Oracle BI uses shared connection pools to communicate with the database. This is great for performance but requires a bit of extra setup work to ensure a secure and auditable environment. Steps should be taken to make sure that the underlying database knows who is actually querying the information so that proper database security can be applied. The easiest way to do this with an Oracle database is to set a client identifier. In this chapter, we will use client identifiers to make it possible to use Oracle’s VPD functionality and Oracle Database Auditing with Oracle BI. Setting Client Identifiers When connecting to the database through a shared connection pool, it is quite common to use the client identifier as a way to capture the end user’s true identity. The Oracle database provides a procedure to set the client identifier called DBMS_SESSION.SET_IDENTIFIER. Ideally, this would be called any time a user establishes or obtains a new connection to the database. Oracle BI connection pools even offer the ability to call database functions at several different times: on connect, before query, after query, and on disconnect. One caveat, however, is that you cannot call Oracle procedures directly from these connection pool connection scripts. The connection pool scripts expect return values and therefore your procedures must be created or wrapped as PL/SQL functions. It is a simple step to create a function to wrap DBMS_SESSION.SET_IDENTIFIER. In the sample RPDs provided on the Downloads page at www.OraclePressBooks.com, a database user called BI_SELECT does all data access (the data_access connection pool). This user has a function that takes in the BI end user’s username and returns a string. It’s not really important what the function returns, as we won’t be using it for anything meaningful. For debugging and just as a general good practice, we’ll set the return value to something that might one day be usable: CREATE OR REPLACE FUNCTION bi_select.SET_IDENTIFIER ( p_username_in IN VARCHAR2 ) RETURN VARCHAR2 AS BEGIN dbms_session.set_identifier(p_username_in); RETURN 'Function SET_IDENTIFIER Completed for ' || p_username_in; END; / ■ ■ ■ Chapter 14: Securing Oracle BI Content and Data 541 As shown in Figure 14-2, this function can then be called as part of the connection with a simple SELECT bi_select.set_identifier(‘:USER’) FROM dual. As mentioned, this can be found in all of the sample RPDs provided at www.OraclePressBooks.com. Look at the Connection Scripts tab of the DATA_ACCESS connection pool for the ORCL database, shown in Figure 14-2. You can test to see if this is working in a couple of ways. The easiest way is to log onto the database using SQL*Plus and query the v$session view. From the Oracle BI Administrator tool, right-click any table from the SH schema and choose View Data using the data_access connection pool. Then run the following query in the database in SQL*Plus: SELECT username, client_identifier FROM v$session WHERE username = 'BI_SELECT' You should see BI_SELECT as the username and Administrator (the user logged into the Administration tool) as the client identifier. You can also test this in the audit log. We’ll look at this more closely in the section “Database Auditing.” Securing Data Presented by Oracle BI The BI server handles all data retrieval. Data security policies can be enforced at the BI server level or at the database level. This section offers examples of both and concludes with a discussion on deciding where you can apply the security policy. Chapter 13 reviewed the basics of query execution in Oracle BI, including the presentation server issuing a logical SQL statement and the BI server transforming that into one or more physical SQL statements that are issued to the database. Let’s examine this in a bit more detail before getting into security policies. When a user wants to create a new ad hoc data request, she must first choose a subject area. A subject area is a logical presentation of the data accessible via Oracle BI that the user accesses FIGURE 14-2 Setting a client identifier by a connection script 542 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence in the web interface. This subject area is the representation of a presentation catalog defined in the presentation layer of the BI server metadata. The BI server metadata consists of three layers: Presentation layer This layer consists of one or more presentation catalogs, collections of tables and columns presented to the end user as a subject area. The presentation server, or any ODBC or JDBC application, can issue logical SQL statements against these tables. Business model and mapping layer This intermediate layer sits between the presentation layer and the physical layer. Business rules, including drill paths, aggregation rules, and security policies, are applied at this layer. Physical layer This layer of metadata represents the physical tables against which the BI server will issue queries. This is normally created by importing metadata from the database’s data dictionary. The business model and mapping layer plays a critical part in determining how the logical SQL statement issued by the Presentation server will get transformed in a physical SQL statement issued by the BI server against the backend data sources. It is also worth examining what the BI server does when it receives a logical SQL statement. In general, two things happen: a query plan is established and the possible use of the Oracle BI cache is evaluated. The BI server uses the metadata to determine how to satisfy the logical request, including any multi-pass SQL statements, fragmentation optimization (splitting the query across multiple systems), and aggregation navigation (rewriting queries against available aggregate data stores to improve performance). The BI server cache is extremely important in this section, because this cache is shared between users. We’ll discuss how to ensure that the sharing of cache respects all security policies. Security Policies Within the BI Server Securing data is done at two levels in Oracle BI. The first level is a coarse level and involves giving people access to subject areas—similar to giving users access to a schema in a database. If a user has access to a subject area, he will be able to perform queries against that subject area. If a user does not have access to a subject area, he will not even see that the subject area exists. It will not be usable in any fashion in Oracle BI. The second level of data security occurs at a very fine level and is either row- or column-based security, and this is the primary focus of this chapter. Subject Area Security Setting up subject area security is quite simple. Technically, security is applied to the presentation catalog in the BI server metadata. As mentioned, a one-to-one correspondence exists between BI server metadata presentation catalogs and the subject areas that appear when using Oracle Answers. The terms “presentation catalogs” and “subject areas” are often used interchangeably, and they will both be used here as well. As shown in Figure 14-3, to set up subject area security, you modify the permissions in the Presentation Catalog properties dialog box in the Administration tool. Read access to a subject area can be granted to a user or a group. Chapter 13 discussed the benefits of externalizing security. If you have externalized security, access to subject areas can be accomplished only at the group level, because users are not stored in the RPD. This same restriction does not apply in the same way to fine-grained security within the BI server, as you will see in the next section. ■ ■ ■ Chapter 14: Securing Oracle BI Content and Data 543 Now let’s move from the coarse-level security of securing access to subject areas to the fine- grained level of applying row- and column-level security. This approach follows the best practice of applying security at the most general level and then moving to the most specific level. Oracle BI’s Row-level Security Adding row-level security using Oracle BI is accomplished by adding business model filters in the BI server metadata. These filters are defined at the group level. This does not mean that the filter is the same for everyone in the group—in fact, the opposite is almost always true: the filter being added is usually user-specific. Let’s look at an example. This example business model filter is found in each example RPD. The point of this simple example is to limit the data to which the product managers have access: product managers should be able to view sales data only for the products they manage. A database table called BI_TABLES.PRODUCT_MANAGERS will be used in conjunction with the SH sample schema. This table has a row for each product that each user is allowed to view. As you can see in Figure 14-4, the user biproduct1 manages Game Consoles and the user biproduct2 manages Portable PCs and Desktop PCs. Now that the data is in place for this example, we can focus on the steps required to apply a business model filter. This will involve creating a session variable to hold information about which products a user manages and creating the business model filter that will be applied to the members of the Product Managers group. Creating the GET_PRODUCT Session Variable Chapter 13 discussed how to set up session variables and offered several examples of using session variables. Specifically, they were used to assign group membership dynamically as the user logged into Oracle BI. In this example, we use a session variable to store information about which products a user manages. The sample RPDs provided at www.OraclePressBooks.com from the Downloads page include an initialization FIGURE 14-3 Setting up subject area security in the Presentation Catalog dialog box . CHAPTER 14 Securing Oracle BI Content and Data 535 536 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence n Chapter 13, we talked about securing access to the Oracle Business. can add to the data and the features Oracle BI can leverage from the Oracle database. You’ll learn about setting up Oracle BI to leverage Virtual Private Database (VPD) and fine-grained auditing. an Oracle database is to set a client identifier. In this chapter, we will use client identifiers to make it possible to use Oracle s VPD functionality and Oracle Database Auditing with Oracle