Applied Oracle Security: Developing Secure Database and Middleware Environments- P57 ppsx

536 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligencen Chapter 13, we talked about securing access to the Oracle Business Intelligence BI server itself.. To run

This page intentionally left blank

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

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

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;

/

■

■

■

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

■

■

■

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