Setting Up Security

This chapter provides prerequisites, overviews of security configuration types and secured dimensions, and discusses how to:

• Set up user authentication.

• Set up object-level security.

• Set up data-level security.

Prerequisites

The following software is required to set up security in the Fusion Campus Solutions Intelligence application:

• PeopleTools 8.52

• Oracle Business Intelligence Enterprise Edition 11g

• Oracle HTTP Server 11g (Oracle WebTier Utility)

• Oracle Identity Management 11g (an Oracle Fusion Middleware 11g application)

  • Oracle Access Manager (authentication engine for SSO)

  • Oracle Access Manager WebGates

  • Oracle Internet Directory (LDAP)

Understanding Security Configuration Types

Security in the Fusion Campus Solutions Intelligence application can be broadly classified into three configuration types—user authentication, dashboard object security, and data access security. All three configuration types play a vital role in securing data. This table discusses the security configurations that are delivered with the Fusion Campus Solutions Intelligence application:

These steps explain the general flow of user authentication, dashboard object security, and data access security in the Fusion Campus Solutions Intelligence application:

1. The user signs onto the Single Signon (SSO) Server.

2. The SSO server authenticates the user by checking into the LDAP (Oracle Internet Directory) Server.

3. The LDAP server confirms that the user is valid.

4. The Application server is configured to get the user information from the SSO server.

   This eliminates the need for the user to log separately into PeopleSoft Internet Architecture (PIA) and OBIEE.

5. After the user logs in, the system applies object-level security to determine the user's access to objects such as pages, reports, and components.

   Object-level security is controlled by the OBIEE Application Role with which the user is associated.

6. When the user clicks on a report, the system applies data-level (row-level) security.

   Data-level security is controlled by the user's security role and the Oracle BI Server Application Role with which the user is associated.

7. When the user clicks a link to drill in place to an OLTP, additional signon is not required.

Understanding Secured Dimensions

In PeopleSoft EPM you can grant users access to a particular dimension if you indicate during system setup that the dimension requires securing. Each secured dimension is associated with a security join table (SJT) in the EPM database that stores the security profiles for users, and the corresponding dimension values to which they have access.

This table lists the delivered, secured dimensions for the Fusion Campus Solutions Intelligence application:

See Also

Defining Dimension and Metric Security

Setting Up User Authentication

Users sign directly into Oracle Business Intelligence Enterprise Edition (OBIEE) to access the Fusion Campus Solutions Intelligence application. By setting up single signon with user identity management, you eliminate the need to maintain multiple user ID repositories. The OBIEE system authenticates the user at signon and associates the user with their Application Roles in OBIEE.

The single signon with user identity management feature also enables users to drill in place from the Fusion Campus Solutions Intelligence dashboards or reports to source data in online PeopleSoft transaction applications without encountering an additional PeopleSoft signon page.

This section discusses how to complete the following tasks to set up Oracle Single Signon with Oracle Identity Management for the Fusion Campus Solutions Intelligence application:

• Configure PeopleTools for LDAP authentication.

• Configure OBIEE to use LDAP authentication.

• Register PeopleSoft as a partner application with Oracle Single Signon Server.

• Register OBIEE as a partner application with Oracle Single Signon Server.

• Configure PeopleSoft for Single Signon with Oracle Application Server.

• Configure OBIEE for Single Signon with Oracle Application Server.

Note. PeopleSoft and OBIEE also support third-party single signon authentication systems. For more details, refer to the PeopleSoft PeopleTools PeopleBook: Security Administration.

See Also

Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)

Configuring PeopleTools for LDAP Authentication

To configure the PeopleTools system for LDAP authentication, use the instructions in the PeopleSoft PeopleTools PeopleBook: Security Administration to complete these tasks:

1. Configure the LDAP directory.

   Use the Configure Directory - Directory Setup page (PeopleTools, Security, Directory, Configure Directory, Directory Setup) to specify the network information of your LDAP directory servers.

   Use the Configure Directory - Additional Connect DNs (distinguished names) page (PeopleTools, Directory, Configure Directory, Additional Connect DN's) to specify connect DNs, in addition to the default connect DN specified on the Directory Setup page.

2. Cache the directory schema.

   Use the Configure Directory - Schema Management page (PeopleTools, Security, Directory, Configure Directory, Schema Management) to install selected PeopleSoft-specific schema extensions into your directory.

   Use the Configure Directory - Test Connectivity page (PeopleTools, Security, Directory, Configure Directory, Test Connectivity) to test the DNs and search criteria that you entered on the previous pages of the Configure Directory component, and view the results.

3. Create authentication maps.

   Use the Authentication Map - Authentication page (PeopleTools, Security, Directory, Authentication Map, Authentication) to map to the directory that the PeopleSoft system uses to authenticate users.

4. Create user profile maps.

   Use the User Profile Map - Mandatory User Properties page (PeopleTools, Security, Directory, User Profile Map, Mandatory User Properties) to specify the attributes that are required for signon.

Note. Skip these tasks if you configured the PeopleTools system for LDAP authentication as part of a previous installation.

See PeopleSoft PeopleTools PeopleBook: Security Administration, "Employing LDAP Directory Services," Configuring the LDAP Directory.

Verify the Configuration

Perform the following steps to verify the correct configuration:

1. Sign onto Oracle's PeopleSoft application as a user with administrative rights, such as VP1, password VP1, and navigate to the Configure Directory component (PSDSSETUP).

   Verify that an LDAP server is configured to match your OID.

   Access the Test Connectivity page and verify that all tests are successful.

2. Navigate to the Authentication Map - Authentication page.

   Verify that a map exists that matches the directory server in the previous step.

3. Navigate to the User Profile Map - Mandatory User Properties page.

   Verify that a user profile map exists for the directory server in the previous step.

4. Navigate to the Signon PeopleCode page (PeopleTools, Security, Security Objects, Signon PeopleCode).

   Verify that the Invoke as button is enabled, and the User ID and Password fields are populated with the person who has the authority to execute the signon PeopleCode.

   Verify that the functions LDAP_Authentication and LDAP_ProfileSynch are enabled.

5. Sign onto the PeopleSoft application as an enterprise user that exists in the LDAP server.

6. If the signon to the PeopleSoft application fails, reboot the associated application server.

Note. The LDAP profiles are synchronized with PeopleSoft user profiles only when users sign onto the application. Therefore, all enterprise users (users that are created in the LDAP server) must sign onto the PeopleSoft application at least once before using the Fusion Campus Solutions Intelligence application.

Configuring OBIEE to Use LDAP Authentication (Oracle Internet Directory)

See Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1),Configuring Oracle BI to use Oracle Internet Directory, sections 3.2.1.1 through 3.2.1.4.

Registering PeopleSoft as a Partner Application with Oracle Access Manager 11g (SSO)

See Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager 11g Release 1 (11.1.1), "Registering Partners (Agents and Applications) by Using the Console," to register PeopleSoft as a partner application with Oracle Access Manager 11g.

Registering OBIEE as a Partner Application with Oracle Access Manager 11g (SSO)

The steps to register OBIEE as a partner application with Oracle Access Manager Server are identical to the steps that you completed when you registered PeopleSoft as a partner application with Oracle Access Manager Server.

Configuring PeopleSoft for Single Signon with Oracle Access Manager 11g

To configure PeopleSoft for single signon with the Oracle Access Manager, complete the tasks that are discussed in this section.

See PeopleSoft PeopleTools PeopleBook: Security Administration, Implementing Single Signon, Implementing Oracle Access Manager as the PeopleSoft Single Signon Solution.

1. Create a default user ID, which is similar to implementing the web server security exit in PeopleSoft.

   See PeopleSoft PeopleTools PeopleBook: Security Administration, "Employing Signon PeopleCode and User Exits," Using the Web Server Security Exit, Creating a Default User.

2. Modify the PeopleSoft web profile to contain default user signon information.

   Enable the Allow Public Access option for the web profile.

   Enter the same user ID that you created in the previous step.

   To prevent a user ID from appearing as the default user on the signon page, enter a 0 value for the Days to Auto Fill User ID field.

   See PeopleSoft PeopleTools PeopleBook: Security Administration, "Employing Signon PeopleCode and User Exits," Using the Web Server Security Exit, Modifying the Web Profile.

   See PeopleSoft PeopleTools PeopleBook: PeopleTools Portal Technologies, "Configuring the Portal Environment," Configuring Web Profiles, Configuring Portal Security.

3. Implement signon PeopleCode.

   Make sure that the Oracle Internet Directory user information exists in PeopleSoft, which can be accomplished with a delivered Signon PeopleCode function.

   This step requires that user profiles are defined in the Oracle Internet Directory and in PeopleSoft. PeopleSoft provides the OSSO_AUTHENTICATION Signon PeopleCode function to obtain user profile and role information from the Oracle Internet Directory. To use this information, add and enable OSSO_AUTHENTICATION in the FUNCLIB_LDAP record definition by using the Signon PeopleCode page.

   We recommend that you modify the entry for SSO_AUTHENTICATION and change the function name to OSSO_AUTHENTICATION. This action avoids mixing single signon options. In your Signon PeopleCode program, modify the getWWWAuthConfig( ) function to assign the value of the default user that you created to the &defaultuserId variable.

   Note. OSSO_AUTHENTICATION must appear before LDAP_PROFILESYNC in the Signon PeopleCode page grid.

   See PeopleSoft PeopleTools PeopleBook: Security Administration, "Employing Signon PeopleCode and User Exits," Using Signon PeopleCode, Enabling Signon PeopleCode.

   Note. Alternatively, you can write a custom PeopleCode program to create the user as needed. However, this customization is not supported by Oracle.

4. Modify mod_wl_ohs.conf file, located in <ORACLE_INSTANCE>/config/OHS/<componentName> to redirect users to the Oracle Single Signon page.

   This is an example of code in the mod_wl_ohs.conf file:

   <Location /PORTAL>
      SetHandler weblogic-handler
      WebLogicHost <server name>
      WeblogicPort <port>
   </Location>

Configuring OBIEE for Single Signon with Oracle Access Manager 11g

To configure OBIEE for single signon with Oracle Access Manager 11g, complete the tasks that are discussed in this section.

1. Change the Oracle OBIEE WebLogic Server authenticator from the default identity store (i.e. the embedded LDAP server) to the new identity store and new SSO provider.

   See Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1), Enabling SSO Authentication, Configuring a New Authenticator for Oracle WebLogic Server.

   See Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1), Enabling SSO Authentication, Configuring a New Identity Asserter for Oracle WebLogic Server.

2. Add the user name(s) from OID into the pre-existing BISystem Application Role and refresh users and group GUIDs

   See Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1), Using Alternative Authentication Providers, Configuring a New Trusted User (BISystemUser).

   See Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1), Using Alternative Authentication Providers, Regenerating User GUIDs.

3. Enable OBIEE to accept SSO authentication

   See Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1), Enabling SSO Authentication, Using Fusion Middleware Control to Enable SSO Authentication.

Setting Up Object-Level Security

This section discusses how to complete the following tasks to set up object-level security for the Fusion Campus Solutions Intelligence application. You can achieve object-level security by mapping users and groups to Application Roles with access to specific Oracle BI Administration Tool objects and Oracle BI Presentation Catalog objects.

Creating and Managing Users and Groups

Oracle Internet Directory (OID) is the authentication provider instead of the default the embedded WebLogic LDAP Server provided with OBIEE 11g. Creating and managing users and groups must be completed in OID.

See Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory 11g Release 1 (11.1.1), Getting Started With Oracle Internet Directory.

Mapping Users and Groups to Application Roles

After users and groups are created and mapped together, they will need to be mapped to Application Roles. BIConsumers, BIAuthors, or BIAdministrators are provided by default and have preconfigured privileges to access BI components (metadata repository and presentation catalog).

Note. New groups and Application Roles can be created if the defaults (BIConsumers, BIAuthors, or BIAdministrators) do not meet your business requirements.

To map users and groups to Application Roles:

1. Start the Oracle Enterprise Manager (for example, http://localhost:7001/em).

   The Fusion Middleware Control login page displays.

2. On the Fusion Middleware Control login page, enter the Administrator for the Administrator field and welcome1 for the Password field, then click Login.

3. From the target navigation pane, expand the WebLogic Domain and right-click bifoundation_domain.

4. Select Security then Application Roles.

5. On the Application Roles page, select Select Application Stripe to Search, and select obi from the list.

6. Click the Search icon (next to the Role Name field).

7. Select an application role in the list and click Edit.

   The Edit Application Role page displays.

8. In the Edit Application Role page, click the Add Group icon.

   The Add Group page displays.

9. In the Add Group page, add the group that you want to assign to the Roles list

10. Click OK to continue, then click OK again on the Edit Application Role page.

See Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1), Managing Security Using the Default Security Configuration, Creating and Managing Application Roles and Application Policies Using Fusion Middleware Control.

Managing Metadata Repository Privileges

To modify metadata repository privileges:

1. Open the repository in the Oracle BI Administration Tool.

2. In the Presentation panel, navigate to the subject area or sub-folder for which you want to set permissions.

3. Right-click the subject area and select Properties to display the properties dialog.

4. Click Permissions to display the Permissions dialog.

5. Select Read, Read/Write, No Access, or Default for each Application Role or user you wish to modify.

   It is best practice to only modify the Application Roles.

6. Click OK to continue, then click OK again on the properties dialog.

7. Save your changes.

See Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1), Managing Security Using the Default Security Configuration, Managing Metadata Repository Privileges Using the Oracle BI Administration Tool.

Managing Presentation Services Catalog Privileges

To modify presentation services catalog privileges:

1. Log in to Oracle Business Intelligence as a user with Administrator privileges.

2. From the Home page in Presentation Services, select Administration to display the Administration page.

3. In the Security area, select Manage Privileges to display the Manage Privileges page.

4. Click an Application Role next to the privilege that you want to edit.

   The Privilege page displays.

5. In the Privilege page, add or change permissions for an Application Role.

6. Click OK to save your changes.

See Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1), Managing Security Using the Default Security Configuration, Managing Metadata Repository Privileges Using the Oracle BI Administration Tool.

Setting Up Data-Level Security

This section provides an overview of data-level security, and discusses how to complete the following tasks to set up data-level security for the Fusion Campus Solutions Intelligence application:

• Determine secured dimensions.

• Create physical joins.

• Secure dimensions.

• Secure facts that use specific dimensions.

• Remove data security on facts and dimensions.

See Setting Up EPM Infrastructure, Business Rules, and Security.

Understanding Data-Level Security

The data-level security that you set up during the PeopleSoft EPM system implementation is maintained when users access the same data in the Fusion Campus Solutions Intelligence application. Data-level security effectively leverages the PeopleSoft EPM security framework. You can set up additional data-level security in the Oracle BI Repository by using Oracle BI Server group filters and restrictive conditions in the Logical layer. These SJTs are delivered with the Fusion Campus Solutions Intelligence application and are used to store the secured members of a specific dimension:

• D_ACAD_GRP_SJT (Academic Group SJT)

• D_DEPT_SJT (Department SJT)

• D_INSTN_SJT (Institution SJT)

The system uses D_BUS_UNIT_SJT to secure both the Business Unit and Business Unit Accounts Payable secured dimensions.

The system uses the PF_SY_ROLE_USER table to extract information about role user mapping.

All security-related tables are located in the Security Tables folder in the Oracle BI Repository.

Determining Secured Dimensions

Determine the dimension that you want to secure and identify the underlying table and its corresponding SJT. For example, if you want to secure the Institution dimension, the underlying table is D_INSTITUTION, and the corresponding SJT is D_INSTN_SJT.

See Setting Up EPM Infrastructure, Business Rules, and Security.

Creating Physical Joins

The Fusion Campus Solutions Intelligence application delivers the physical joins for the delivered secured dimensions.

Access the Physical Diagram - Physical Join page (Oracle BI Administration Tool, Manage, Joins, <dimension>) to create physical joins.

This is an example of the Physical Join page showing a join between a dimension table and its SJT:

The WHERE clause that is shown in this example is D_INSTITUTION.INSTITUTION_SID = D_INSTN_SJT.INSTITUTION_SID OR D_INSTN_SJT.INSTITUTION_SID = 2147483647. The number 2147483647 can be used for any dimension, and indicates ALL access for a role.

Following is an example of a physical join between the same SJT (D_INSTN_SJT) and the PF_SY_ROLE_USER table. Because SJT tables are populated with role information, this join will map the role to the enterprise user:

The Where clause that is used in this example is D_INSTN_SJT.PF_SY_ROLE_NAME = PF_SY_ROLE_USER.PF_SY_ROLE_NAME AND PF_SY_ROLE_USER.OPRID IN ( VALUEOF(NQ_SESSION."USER")). The variable NQ_SESSION.USER is an OBIEE variable that stores the user ID of the person who is currently signed onto the system.

This is the resulting physical diagram from the preceding two physical join examples:

Securing Dimensions

Access the Business Model and Mapping - Logical Table Source page (Oracle BI Administration Tool, Business Model and Mapping layer, <dimension>, Properties, Sources) to secure dimensions.

This is an example of the Logical Table Source page for the Institution dimension:

In this example, to secure the Institution dimension, the tables that are involved are D_INSTITUTION and D_INSTN_SJT. In the Business Model and Mapping layer, open the D_INSTITUTION dimension properties, and click the Sources tab. Force a join with the D_INSTN_ SJT and PF_SY_ROLE_USER by first adding the two tables to the Map to these tables region, and selecting the associated rows in the Joins grid.

Securing Facts That Use Specific Dimensions

Access the Business Model and Mapping layer - Logical Table Source page to secure facts.

This is an example of the Logical Table Source page for the Award Snapshot fact:

In this example, secure facts that use the Institution dimension in the same way that you secured the Institution dimension. In the Business Model and Mapping layer, open the F_AWD_SNPSHT fact properties, and click the Sources tab. Force a join with the D_INSTITUTION, D_INSTN_ SJT, and PF_SY_ROLE_USER tables by first adding the three tables to the Map to these tables region, and selecting the associated rows in the Joins grid.

Removing Data Security on Facts and Dimensions

Access the Business Model and Mapping layer - Logical Table Source page to remove data security on facts and dimensions.

This is an example of the Logical Table Source page for the Award Snapshot fact after you remove the table mapping that you added in the previous example:

To remove the data security on facts or dimensions, select the dimension or fact, access the Sources, and right-click on Properties. Clear the joins and remove the associated tables.

For example, assume that you want to remove the fact security that you set up in the previous section. To disable the security, delete the forced joins with D_INSTITUTION, D_INSTN_SJT and PF_SY_ROLE_USER tables. When you remove the tables from the Map to these tables region, the system removes the joins from the Joins grid, and the data will be unsecured.