514 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence Database Authentication Using Only Database Users As mentioned, using database authentication as documented has several drawbacks. These can be avoided if database authentication is handled more like external table authentication or LDAP authentication. To do this, we just follow the basic principles of external authentication: validate the username and password, and populate the USER session variable. 1. In the database that actually contains the database users, create a connection pool that will be used solely for authentication. 2. For the username and password, use these values: USER and :PASSWORD, respectively. These are the values the user entered into the logon screen and the presentation service is forwarding them to the BI server. The BI server will attempt to connect to the database using these values. FIGURE 13-5 LDAP authentication initialization block Chapter 13: Securing Access to Oracle BI 515 3. Create an initialization block that executes the following simple query: SELECT USER FROM dual. Put the results of that query into the USER session variable. The initialization block should use the connection pool defined in step 1. 4. Remember to check the box Required For Authentication. When a user attempts to log into the system, the BI server will execute this initialization block. If a valid username and password are entered, the use of the connection pool will succeed, the query will be executed, and the USER session variable will be populated. If the username and password are not valid, the attempt to run the query will fail because the BI server will be unable to log into the database to execute the query. Custom Authentication Oracle BI also supports the notion of custom authentication, which allows you to create your own program to authenticate users and then integrate that with Oracle BI. To accomplish this, you must write your own program to authenticate users: a .dll on windows or a .so on UNIX/Linux. The API to which your program must conform is documented in Appendix B of the Oracle BI Server Administration Guide. An example custom authentication program also ships with Oracle BI (versions 10.1.3.4 and later). This custom authentication program is designed to allow the Oracle BI Server to use Hyperion Shared Services as the security infrastructure for Oracle BI. This integrated security model is required if you want to integrate Oracle BI with Oracle Hyperion Workspace, a component of the Oracle BI Suite Enterprise Edition Plus product set. Fallback Authentication A fallback authentication mechanism is available for each of these methods of authentication. This means that if the first method of authentication fails, Oracle BI will attempt to authenticate using the internal authentication mechanism. For example, if you have set up LDAP authentication and the username and password you entered fails LDAP authentication, Oracle BI will attempt to authenticate using the internal security mechanisms. The most common case of this is the user called Administrator. This user gets created automatically in every RPD but most likely doesn’t exist in your LDAP. If you try to log in as Administrator, the LDAP authentication will fail, but the RPD authentication will succeed and you will be considered authenticated. You may be wondering why you would have both internally defined users and externally defined users. For your primary user community, end users, you will want to externalize your users for the reasons that we have discussed in this section. For your RPD developers, you will need to have accounts created in the RPD for them to use. When editing the RPD, they will need to have an internally defined username and password with which they can log into the RPD. Oracle BI Publisher Authentication Oracle BI Publisher can be used as a stand-alone reporting tool or as an integrated component of the Oracle BI suite. Because it can be used in a completely stand-alone fashion, it needs to have its own authentication and authorization infrastructure. Oracle BI Publisher supports the following authentication schemes: Internal BI Publisher security LDAP Oracle E-Business Suite ■ ■ ■ 516 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence Oracle BI Server Oracle Database Oracle Hyperion Shared Services Several of these security schemes are designed specifically for situations in which BI Publisher is integrated with other Oracle products. The Oracle BI Publisher Administrator’s and Developer’s Guide covers the process of setting up each of these authentication schemes. The important thing to point out in the context of this book is that if you want to use Oracle BI Publisher as an integral component of Oracle BI Enterprise Edition, you should use the Oracle BI Server security scheme. When this is set up, Oracle BI Publisher delegates authentication and authorization to the Oracle BI server. This is true even when Oracle BI is set up to use external authentication. For example, if Oracle BI is set up to use LDAP authentication, it would seem that you have two choices for BI Publisher security configuration: You could set it up to use Oracle BI Server authentication or LDAP authentication; however, Oracle’s recommendation is that you use Oracle BI Server authentication whenever you are using Oracle BI Publisher as an integrated component of Oracle BI Enterprise Edition. Authorization After the user is authenticated, you need to make sure that the user has the proper authorization. Authorization happens at two distinct levels in Oracle BI: at the BI server and at the presentation server. This gives the Oracle BI administrator a lot of flexibility. For example, suppose you have a project management dashboard, and one set of users can view these dashboards, while another set can view and edit the dashboards. In both cases, the users need to be able to query the same set of data. The permission to query the data is controlled at the BI server level, because the BI server handles issuing the actual queries to the database. The permission to view or edit the dashboard definition is handled by the presentation server. This section covers authorization at both the BI server level and the presentation server level. In both cases, managing authorization is accomplished completely by managing user to group assignments. Types of Groups Oracle BI has two types of groups that support authorization at two distinct levels: BI server groups (often referred to as just groups) and web catalog groups (often referred to as webgroups). A BI server group is defined in the BI server metadata (the RPD). These groups are used to control access to data. For example, you might limit what subject areas a user can access based on the user’s group membership. You may also use group membership to apply row-level filters to the data. These types of row-level filters are known as business model filters. In addition to creating business model filters based on group membership, you can also define filters based on other variables. For example, during the authentication process, you may query the user’s organization from a database application. You can then apply business model filters based on the organization value. Business model filters will be explored in great detail in Chapter 14. A webgroup is defined in the presentation server metadata (the web catalog). Webgroups are used to control access to web catalog objects, such as dashboard definitions, report definitions, and scheduled job definitions. Webgroups are also used to control access to various system permissions, such as the ability to create ad hoc requests or use web services to access Oracle BI. Controlling access to both web catalog content and system permissions is covered in detail in Chapter 14. ■ ■ ■ Chapter 13: Securing Access to Oracle BI 517 NOTE BI server groups control access to RPD objects (data) and web catalog groups control access to web catalog objects (dashboard definitions, request definitions, and scheduled jobs). Sometimes the groupings you would use to control access to data are the same groupings that would control access to web content. If this is the case, just name your webgroups, which control the UI components from the presentation server, exactly the same names used for your BI server groups, which control access to the underlying data elements. When you do this, webgroup membership will automatically be inherited from group membership. The examples provided with this text include a group called SH Users. I wanted membership in this group to control access to both BI server metadata and web content. To accomplish this, I created a group called SH Users in the RPD and a webgroup also called SH Users in the web catalog. Any user that is a member of the group SH Users will also be a member of the webgroup SH Users. Giving groups and webgroups the same name simplifies the administration process, because you need to manage group membership only at the BI sever level, and group membership at the presentation server level will be inherited automatically. Internal and External Group Membership As mentioned, managing authorization is actually an exercise in managing group memberships. You’ve already read about several different methods of authorization. Some of these require that the users be defined internal to the BI server metadata. Others methods externalize the identity storage. Groups are handled a bit differently. In every case, the groups must be defined in the Oracle BI metadata. BI server groups will be defined in the BI server metadata and web catalog groups will be defined in the web catalog. The group must exist in the metadata so that object-to- group relationships can be defined in the metadata. Groups must also be defined wherever the users are defined. We can break this into two cases: Users are defined in the BI Server metadata: built-in authentication or database authentication using RPD and database users Users are defined external to the BI Server metadata: table-based authentication, LDAP authentication, database authentication using only database users, or custom authentication In the first case, the user-to-group assignments must be stored in the Oracle BI metadata. Group membership is assigned in the BI server in with the Administration tool using the Security Manager, and webgroup membership is assigned in the presentation server using the Manage Users and Groups screen of the web interface. In the second case, the user-to-group assignments are defined outside the Oracle BI metadata. While a session is being created, the BI server will dynamically retrieve information about a user’s group membership from wherever that information is stored. The location of authorization information need not be the same as the location of authentication information. For example, usernames and passwords might be stored in an LDAP, while user-to-group membership might be defined in database tables. The only restriction is that if you are using internal authentication, you must use internal authorization, and if you are using external authentication, you must use external authorization. ■ ■ 518 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence Dynamic group membership is defined using variables and initialization blocks. The session variable GROUP is used for BI server group membership and the variable WEBGROUPS is used for web catalog group membership. If a user belongs to multiple groups, you will still populate the GROUP session variable, but you will use row-wise initialization to populate the GROUP session variable. In the examples included with this book, the user biadmin belongs to two groups (Administrators and XMLP_ADMIN) and one webgroup (Presentation Server Administrators). When biadmin logs on using external authentication, the GROUP variable should be set to the value Administrators;XMLP_ADMIN and the WEBGROUPS variable should be set to Presentation Server Administrators. Another user, biproduct1, is a member of the SH Users group and the Product Managers group. In this case, the GROUP variable needs to be populated with the value SH Users;Product Managers. Recall that variables set using row-wise initialization automatically get created as a semicolon-delimited list of values. Dynamic Group Membership Using Tables When authorization information is stored in database tables, an initialization block with a database query is used to set the GROUP and WEBGROUPS variables with values obtained from a database table. This method is implemented in the aos_database_security.rpd and aos_table_ security.rpd repositories included with this book, and either of these can be used to test or examine this method. The Variables page on the Utilities dashboard example also included with this book is useful for testing purposes. The appendix details how to use these repositories and the sample dashboard. In these examples, three tables in the BI_SECURITY_TABLES schema contain all the required information: BI_USERS, BI_GROUPS, and BI_USER_GROUPS. Here is the query used in the get_ groups initialization block: SELECT g.group_type variable_name, g.group_name variable_value FROM bi_security_tables.bi_groups g, bi_security_tables.bi_user_groups ug WHERE g.group_name = ug.group_name AND ug.user_name = ':USER' When setting up the initialization block that will execute this query and populate the GROUP and WEBGROUPS session variable, you should notice a few things. First, we have set the variable target to row-wise initialization, because a user may belong to multiple groups or web catalog groups. Second, this initialization block is set to execute after the check_user initialization block. This ensures that the USER session variable is set properly before executing the query to retrieve the group information. Lastly, the initialization block is marked as “required for authentication.” If this initialization block fails, the user will not be authenticated and will be denied access to Oracle BI. Figure 13-6 shows the setup for this initialization block. To summarize, when biadmin logs in, the check_user initialization block runs first to authenticate biadmin. Then the get_groups initialization block will run with biadmin substituted for :USER. The results when the query is run for biadmin in SQL Developer is shown in Figure 13-7. After the session is established, these session variables can be checked on the Session Variables page of the Utilities dashboard, as shown in Figure 13-8. Chapter 13: Securing Access to Oracle BI 519 FIGURE 13-6 Initialization block for dynamic group membership FIGURE 13-7 Query to populate group membership 520 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence In this section, we used database tables to set up group membership dynamically. As mentioned, this type of authorization can be used with any type of external authentication method (database, table, or LDAP). In the examples provided with this book, this method of table-based authorization is used with both the database and table-based authentication examples. Up to this point, our discussion of variables, initialization blocks, authentication, and authorization has been somewhat fragmented. We have now covered enough information to put everything together. The basic process for using database tables as a method of authorization is as follows: Create users in the appropriate place for the method of external authentication that you are using (database, table, or LDAP). Create groups in the RPD using the Administrator tool. Create web groups in the web catalog using the web interface to Oracle BI. Create and populate tables that store user-to-group assignments. Authenticate the user and set the USER session variable using an initialization block. Set the GROUP and WEBGROUPS session variables using a row-wise initialization block. Dynamic Group Membership Using LDAP Directly When using LDAP authentication, it seems natural to assume that group membership information should be obtained from LDAP. This would provide a single location to create users, create groups, and manage group membership. Oracle BI, however, cannot retrieve multiple records from an LDAP server during authentication. When returning multiple records from a database table via an initialization block, you can use the row-wise initialization feature to handle multiple records. Oracle BI does not have an equivalent feature for LDAP servers. You can attack this problem in two ways: The first way requires storing group membership in a unique way in LDAP; the second way involves using Oracle’s DBMS_LDAP package and is discussed in the next section. When retrieving group membership directly from LDAP, Oracle BI needs to group membership information stored in a particular format. There needs to be a single LDAP attribute for each user that contains a semicolon-delimited list of groups to which the user belongs. If group membership can be stored in this fashion, Oracle BI can use an initialization block to retrieve this attribute ■ ■ ■ ■ ■ ■ FIGURE 13-8 Session variables validation test Chapter 13: Securing Access to Oracle BI 521 containing the group membership information. In this setup, it is possible to populate both the USER and GROUP session variables. Oracle BI will then be able to authentication and authorize the user properly. However, this is a rather unorthodox way to store group membership in an LDAP. Dynamic Group Membership Using LDAP Indirectly Using the Oracle database’s LDAP functionality and pipelined table functions, it’s possible to expose LDAP information through the Oracle database. This allows Oracle BI to think that it’s getting its information from a database when the information is really coming from LDAP. Recall from earlier in the chapter that the authentication initialization block handles retrieving the user’s identity from LDAP and populating the USER session variable. In the case of Active Directory, the sAMAccountName is returned into the USER session variable. In the case of Oracle Internet Directory, the UID would be returned into the USER session variable. In either case, this actually represents the user’s common name (cn). To look up group membership from the LDAP, we will need to get the USER’s distinguished name (dn). Let’s outline the process required to get group information: 1. Oracle BI has the user’s cn (cn=biadmin). This was obtained via the authentication initialization block. 2. Search the LDAP to get the user’s dn (cn=biadmin,cn=Users,dc=aos,dc=oracle,dc=com). 3. Find all the groups of which biadmin is a member. When we program this, the query will actually return the dns of all the groups to which biadmin belongs (cn=BI-Administrators, cn=Groups,dc=aos,dc=oracle,dc=com). 4. Convert the dn back to a cn. The BI server does not need the full dn (cn=BI- Administrators). Following is sample code that implements this outline. This code creates a function that takes as input a username and returns a table of group names. Using the pipelined table function feature of the Oracle database, we will be able to query this function as if it were a table. This allows the BI server to return LDAP information by simply executing a query against the database. CREATE OR REPLACE type bi_security_select.array AS TABLE OF VARCHAR2(255); / CREATE OR REPLACE FUNCTION bi_security_select.get_groups ( p_username IN VARCHAR2) RETURN bi_security_select.array pipelined AS You must set these variables for your own environment ldap_host VARCHAR2(256):= 'aosdb.us.oracle.com' ; Recommend using SSL ldap_port PLS_INTEGER := '389'; ldap_user VARCHAR2(256):= 'cn=orcladmin'; If your LDAP is setup to allow anonymous binds, use null for a password Otherwise, you need to specify a password here ldap_password VARCHAR2(256):= NULL; group_base VARCHAR2(256):= 'cn=Groups,dc=aos,dc=oracle,dc=com'; user_base VARCHAR2(256):= 'cn=Users,dc=aos,dc=oracle,dc=com'; retval PLS_INTEGER; 522 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence my_session DBMS_LDAP.session; my_pset_coll DBMS_LDAP_UTL.PROPERTY_SET_COLLECTION; my_property_names DBMS_LDAP.STRING_COLLECTION; my_property_values DBMS_LDAP.STRING_COLLECTION; group_handle DBMS_LDAP_UTL.HANDLE; user_dn VARCHAR2(2000); group_type PLS_INTEGER := DBMS_LDAP_UTL.TYPE_DN; my_mod_pset DBMS_LDAP_UTL.MOD_PROPERTY_SET; my_attrs DBMS_LDAP.STRING_COLLECTION; group_cn VARCHAR2(2000); j NUMBER; my_message DBMS_LDAP.message; my_entry DBMS_LDAP.message; entry_index PLS_INTEGER; my_dn VARCHAR2(256); my_attr_name VARCHAR2(256); my_ber_elmt DBMS_LDAP.ber_element; attr_index PLS_INTEGER; i PLS_INTEGER; my_vals DBMS_LDAP.STRING_COLLECTION ; subscriber_handle DBMS_LDAP_UTL.HANDLE; user_handle DBMS_LDAP_UTL.HANDLE; user_type PLS_INTEGER; BEGIN user_type :=DBMS_LDAP_UTL.TYPE_NICKNAME; retval := -1; DBMS_LDAP.USE_EXCEPTION := TRUE; establish and LDAP session my_session := DBMS_LDAP.init(ldap_host,ldap_port); retval := DBMS_LDAP.simple_bind_s(my_session,ldap_user, ldap_password); Define Attributes for the search my_attrs(1) := 'dn'; Search User to retrieve full DN Oracle BI only has the uid Need to get the DN to search for group membership retval := DBMS_LDAP.search_s(my_session, user_base, DBMS_LDAP.SCOPE_SUBTREE, uid='||p_username, my_attrs, 0, my_message); Get First Entry of the results put the dn into the user_dn variable my_entry := DBMS_LDAP.first_entry(my_session, my_message); user_dn := DBMS_LDAP.get_dn(my_session, my_entry); Search for all the groups that have the user's DN as a UNIQUEMEMBER retval := DBMS_LDAP.search_s(my_session, group_base, DBMS_LDAP.SCOPE_SUBTREE, 'uniquemember='||user_dn, my_attrs, 0, my_message); count the number of entries returned retval := DBMS_LDAP.count_entries(my_session, my_message); my_entry := DBMS_LDAP.first_entry(my_session, my_message); entry_index := 1; Loop through the results WHILE my_entry IS NOT NULL LOOP my_dn := DBMS_LDAP.get_dn(my_session, my_entry); Trip the extra info from the DN to get just the group name group_cn:=SUBSTR( my_dn, (instr(my_dn,'=') +1)); Chapter 13: Securing Access to Oracle BI 523 group_cn:=SUBSTR( group_cn,0,(instr(group_cn,',')-1)); push the name of the group onto the output pipe pipe row(group_cn); my_entry := DBMS_LDAP.next_entry(my_session, my_entry); entry_index := entry_index+1; END LOOP; Close the connection retval := DBMS_LDAP.unbind_s(my_session); END; / We will now use this function in exactly the same way we did when getting group information from a table. Here is the query to put in the initialization block: SELECT 'GROUP' variable_name, SUBSTR(column_value,4) variable_value FROM TABLE(get_groups(':USER')) WHERE column_value LIKE 'BI-%' UNION ALL SELECT 'WEBGROUPS' variable_name, SUBSTR(column_value,7) variable_value FROM TABLE(get_groups(':USER')) WHERE column_value LIKE 'BIweb-%' A couple of things are worth noticing in this query. First is the use of the pipelined table function: select * from table(get_groups(‘:USER’)). This lets you select from a function just as if it were a table while passing in a parameter. The second thing to notice is the complexity surrounding the substring process. Let’s examine that now. If you recall, Oracle BI uses two types of groups: BI server groups and web catalog groups. In the LDAP, I had just one type of group. To solve this problem, I decided to use a naming scheme to differentiate between BI server groups and web catalog groups. All BI server groups are named BI-* and all web catalog groups are named BIweb-*. Looking at biadmin in the LDAP, I see that biadmin is a member of the BI-Administrator, BI-XMLP_ADMIN, and BIweb-Presentation Server Administrators groups. This initialization block will put biadmin in the Administrators and XMLP_ ADMIN BI Server groups and the Presentation Server Administrators web group. As is usually the case when writing code, there are many ways to solve this problem of needing to distinguish between BI server groups and web catalog groups when retrieving group information from LDAP. This method of naming schemes seemed like a fairly simple way to solve the problem. Other ways might include using a specific structure in the LDAP or using group attributes to distinguish between groups and webgroups. To summarize, when using an LDAP indirectly to obtain group membership, you would follow these steps: 1. Populate users and groups in the LDAP. 2. Set up LDAP authentication. 3. Create a pipelined table function to return group information from the LDAP. 4. Create a row-wise initialization block that queries the table function to get group information (similar to what was done in the “Dynamic Group Membership Using Tables”). . Publisher security LDAP Oracle E-Business Suite ■ ■ ■ 516 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence Oracle BI Server Oracle Database Oracle Hyperion Shared Services Several. 514 Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence Database Authentication Using Only Database Users As mentioned, using database authentication as. Indirectly Using the Oracle database s LDAP functionality and pipelined table functions, it’s possible to expose LDAP information through the Oracle database. This allows Oracle BI to think that