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

Part Number E10543-05
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

3 Using Alternative Authentication Providers

This chapter explains how to configure Oracle Business Intelligence to use alternative directory servers for authentication instead of using the default Oracle WebLogic Server LDAP directory. This chapter explains how to set up Oracle Business Intelligence to use Oracle Internet Directory, Active Directory, and other authentication providers, and also explains how to use OID as a policy store, and credential store.

Note:

For a detailed list of security setup steps, see Section 1.7, "Detailed List of Steps for Setting Up Security In Oracle Business Intelligence".

This chapter contains the following sections:

3.1 Introduction

When you use an alternative authentication provider, you will typically use administrative tools provided by your provider vendor to set up your users and groups. You can then assign these users and groups to the preconfigured application roles (for example, BIConsumer, BIAuthors, and BIAdministrator), and any additional application roles that you create. For more information about assigning users and groups to application roles, see Section 2.4, "Managing Application Roles and Application Policies Using Fusion Middleware Control".

You continue to use the other Oracle Business Intelligence tools (such as, the Oracle BI Administration Tool, Fusion Middleware Control, and the Presentation Services Administration Page) to manage the other areas of the security model.

For a current list of supported authentication providers and directory servers to use with Oracle Business Intelligence, you select the authentication provider from the Type list in the Create a New Authentication Provider page. For more information, see System Requirements and Certification.

You can configure more than one supported authentication provider. For more information, see Section 3.4.4, "Configuring Multiple Authentication Providers Using Fusion Middleware Control".

If you use a directory server other than the default WebLogic LDAP Server, you can view the users and groups from the other directory server in Oracle WebLogic Server Administration Console. However, you must manage the users and groups in the interface for the directory server being used. For example, if you are using Oracle Internet Directory (OID), you must use OID Console to create and edit users and groups.

3.2 High-Level Steps for Configuring an Alternative Authentication Provider

To configure an alternative authentication provider:

Prerequisite: Ensure that only the Administration Server is running.

  1. Set up and configure groups and users to enable Oracle Business Intelligence to use an alternative authentication provider as described in Section 3.3, "Prerequisites for Using Alternative Authentication Providers".

  2. Configure Oracle Business Intelligence to use authentication providers as described in Section 3.4, "Configuring Alternative Authentication Providers".

  3. Configure the User Name Attribute in the identity store to match the User Name Attribute in the authentication provider as described in Section 3.5, "Configuring User and Group Name Attributes in the Identity Store".

  4. Go to the myrealm\Users and Groups tab to verify that the users and groups from the alternative authentication provider are displayed correctly. If the users and groups are displayed correctly, then proceed to Step 5. Otherwise, reset your configuration settings and retry.

  5. Configure a new trusted user account for a user in the alternative authentication provider to match the account for DefaultAuthenticator as described in Section 3.7, "Configuring a New Trusted User (BISystemUser)".

  6. Update the user GUIDs to be the values in the alternative authentication provider as described in Section 3.8, "Refreshing User GUIDs".

  7. Assign application roles to the correct groups (enterprise roles) for the new identity store, using Fusion Middleware Control.

    For more information, see Section 2.4.4.2, "Adding or Removing Members from an Application Role".

3.3 Prerequisites for Using Alternative Authentication Providers

Before you configure an Oracle Business Intelligence installation to use an alternative authentication provider, you must make sure that groups and users exist, and are correctly configured in the alternative authentication provider. They can then be associated with corresponding Oracle Business Intelligence application roles that already exist in the Oracle Business Intelligence installation.

To set up users and groups in an alternative authentication provider:

  1. Create groups in the alternative authentication provider that can be assigned to existing Oracle Business Intelligence application roles. For example:

    BIAdministrators, BISystemUsers, BIAuthors, BIConsumers

  2. Create users in the alternative authentication provider, that correspond to the groups created in Step 1. For example:

    BIADMIN, BISYSTEM, BIAUTHOR, BICONSUMER.

  3. Assign the users to their respective groups, in the alternative authentication provider.

    For example you would assign the BIADMIN user to the BIAdministrators group, and the BISYSTEM user to the BISystemUsers group.

  4. Make the BIAuthors group part of the BIConsumers group in the alternative authentication provider.

    Doing this enables BIAuthors to inherit permissions and privileges of BIConsumers.

3.4 Configuring Alternative Authentication Providers

The following procedures describe how to configure one or more authentication providers instead of the default Oracle WebLogic Server LDAP directory.

Note:

This section shows settings for specific authentication providers. However, the instructions can also be used as a general guide for other authentication providers.

3.4.1 Configuring Oracle Internet Directory as the Authentication Provider

This procedure illustrates how to reconfigure your Oracle Business Intelligence installation to use Oracle Internet Directory(OID).

To configure OID as the authentication provider:

  1. Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

    This screenshot or diagram is described in surrounding text.
    Description of the illustration wls01.gif

  2. Select Security Realms from the left pane and click myrealm.

    The default Security Realm is named myrealm.

  3. Display the Providers tab, then display the Authentication sub-tab.

    This screenshot or diagram is described in surrounding text.
    Description of the illustration wls03.gif

  4. Click New to launch the Create a New Authentication Provider page.

    This screenshot or diagram is described in surrounding text.
    Description of the illustration wls04.gif

  5. Enter values in the Create a New Authentication Provider page as follows:

    • Name: Enter a name for the authentication provider. For example, MyOIDDirectory.

    • Type: Select OracleInternetDirectoryAuthenticator from the list.

    • Click OK to save the changes and display the authentication providers list updated with the new authentication provider.

      This screenshot or diagram is described in surrounding text.
      Description of the illustration wls07.gif

  6. Click MyOIDDirectory in the Name column of the Authentication Providers table to display the Settings page.

    This screenshot or diagram is described in surrounding text.
    Description of the illustration wls08.gif

  7. Display the Configuration\Common tab, and use the Control Flag list to select 'SUFFICIENT', then click Save.

    For more information, see Section 3.4.5, "Setting the JAAS Control Flag Option".

    This screenshot or diagram is described in surrounding text.
    Description of the illustration wls05.gif

  8. Display the Provider Specific tab.

    This screenshot or diagram is described in surrounding text.
    Description of the illustration wls09.gif

  9. Use the Provider Specific tab to specify the following details:

    Section Name Field Name Description
    Connection Host The host name of the Oracle Internet Directory server.
    Connection Port The port number on which the Oracle Internet Directory server is listening.
    Connection Principal The distinguished name (DN) of the Oracle Internet Directory user to be used to connect to the Oracle Internet Directory server. For example: cn=OIDUser,cn=users,dc=us,dc=mycompany,dc=com.
    Connection Credential The Password for the Oracle Internet Directory user entered as the Principal.
    Groups Group Base DN The base distinguished name (DN) of the Oracle Internet Directory server tree that contains groups.
    Users User Base DN The base distinguished name (DN) of the Oracle Internet Directory server tree that contains users.
    Users All Users Filter The LDAP search filter. Click More Info... for details.
    Users User From Name Filter The LDAP search filter. Click More Info... for details.
    Users User Name Attribute The attribute that you want to use to authenticate (for example, cn, uid, or mail). For example, to authenticate using a user's email address you set this value to mail.

    Note: The value that you specify here must match the User Name Attribute that you are using in the authentication provider, as described in the next task Section 3.5.1, "Configuring the User Name Attribute in the Identity Store".

    General GUID attribute The attribute used to define object GUIDs in OID.

    orclguid

    Note: You should not normally change this default value, however, if you do, you must also specify the changed value in Fusion Middleware Control, as described in the task Section 3.6, "Configuring the GUID Attribute in the Identity Store".


    Figure 3-1 shows the Users area of the Provider Specific tab.

    Figure 3-1 Provider Specific Tab - Users Area

    This screenshot or diagram is described in surrounding text.
    Description of "Figure 3-1 Provider Specific Tab - Users Area"

    For more information about configuring authentication providers in Oracle WebLogic Server, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

  10. Click Save.

  11. Perform the following steps to set up the DefaultAuthenticator Control Flag setting:

    1. At the main Settings for myrealm page, display the Providers tab, then display the Authentication sub-tab, then select DefaultAuthenticator to display its configuration page.

    2. Display the Configuration\Common tab and select 'SUFFICIENT' from the Control Flag list.

      For more information, see Section 3.4.5, "Setting the JAAS Control Flag Option".

    3. Click Save.

  12. Perform the following steps to reorder Providers:

    1. At the main Settings for myrealm page, display the Providers tab, then display the Authentication sub-tab. This screenshot or diagram is described in surrounding text.
      Description of the illustration wls07.gif

    2. Click Reorder to display the Reorder Authentication Providers page

    3. Select MyOIDDirectory and use the arrow buttons to move it into the first position in the list, then click OK.

      This screenshot or diagram is described in surrounding text.
      Description of the illustration wls11.gif

    4. Click OK to save your changes.

      The authentication providers display in the re-ordered sequence.

      This screenshot or diagram is described in surrounding text.
      Description of the illustration oid23_crop.gif

  13. Click Save.

  14. In the Change Center, click Activate Changes.

  15. Restart Oracle WebLogic Server.

3.4.2 Configuring Active Directory as the Authentication Provider

This procedure illustrates how to configure your Oracle Business Intelligence installation to use Active Directory.

The example data in this section uses a fictional company called XYZ Corporation that wants to set up WNA SSO for Oracle Business Intelligence for their internal users.

This example uses the following information:

  • Active Directory domain

    The XYZ Corporation has an Active Directory domain, called xyzcorp.com, which authenticates all the internal users. When users log into the corporate network from Windows computers, the log into the Active Directory domain. The domain controller is addc.xyzcor.cop, which controls the Active Directory domain.

  • Oracle BI EE WebLogic domain

    The XYZ Corporation has a WebLogic domain called bifoundation_domain (default name) installed on a network server domain called bieesvr1.xyz2.com.

  • System Administrator and Test user

    The following system administrator and domain user test the configuration:

    • System Administrator user

      Jo Smith (login=jsmith, hostname=xyz1.xyzcorp.com)

    • Domain user

      Bob Jones (login=bjones hostname=xyz47.xyzcorp.com)

To configure Active Directory as the Authentication Provider:

  1. Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

    This screenshot or diagram is described in surrounding text.
    Description of the illustration wls01.gif

  2. Select Security Realms from the left pane and click myrealm.

    The default Security Realm is named myrealm.

  3. Display the Providers tab, then display the Authentication sub-tab.

    This screenshot or diagram is described in surrounding text.
    Description of the illustration wls03.gif

  4. Click New to launch the Create a New Authentication Provider page.

    This screenshot or diagram is described in surrounding text.
  5. Enter values in the Create a New Authentication Provider page as follows:

    • Name: Enter a name for the authentication provider. For example, ADAuthenticator.

    • Type: Select ActiveDirectoryAuthenticator from the list.

    • Click OK to save the changes and display the authentication providers list updated with the new authentication provider.

      This screenshot or diagram is described in surrounding text.
  6. Click DefaultAuthenticator in the Name column to display the Settings page.

  7. In the Common Authentication Provider Settings page, change the Control Flag from REQUIRED to SUFFICIENT and click Save.

    For more information, see Section 3.4.5, "Setting the JAAS Control Flag Option".

  8. In the authentication providers table, click ADDirectory in the Name column to display the Settings page.

  9. Display the Configuration\Common tab, and use the Control Flag list to select 'SUFFICIENT', then click Save.

    This screenshot or diagram is described in surrounding text.
  10. Display the Provider Specific tab to access the options which apply specifically to connecting to an Active Directory LDAP authentication store.

  11. Use the Provider Specific tab to specify the following details:

    Section Name Field Name Description
    Connection Host The name of the Active Directory server addc.xyzcorp.com.
    Connection Port The port number on which the Active Directory server is listening (389).
    Connection Principal The LDAP DN for the user we will connect to Active Directory as, when retrieving information about LDAP users. For example: cn=jsmith,cn=users,dc=us,dc=xyzcorp,dc=com.
    Connection Credential/Confirm Credential Password for the Principal specified above (for example welcome1).
    Groups Group Base DN The LDAP query used to find groups in AD.

    Note: Only groups defined under this path will be visible to WebLogic.

    (CN=Builtin,DC=xyzcorp,DC=com).

    Users User Base DN The LDAP query used to find users in AD. CN=Users,DC=xyzcorp,DC=com
    Users User Name Attribute Attribute used to specify user name in AD. Default value is cn.

    Do not change this value unless you know your Active Directory is configured to use a different attribute for user name. If you do change it, see, Section 3.5.1, "Configuring the User Name Attribute in the Identity Store".

    Users All Users Filter LDAP search filter. Click More Info... for details.
    Users User From Name Filter LDAP search filter. Click More Info... for details.
    Users User Object class user
    General GUID attribute The attribute used to define object GUIDs in AD.

    objectguid

    Note: You should not normally change this default value, however, if you do, you must also specify the changed value in Fusion Middleware Control, as described in the task Section 3.6, "Configuring the GUID Attribute in the Identity Store".


    For more information about configuring authentication providers in Oracle WebLogic Server, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

  12. Click Save.

  13. At the main Settings for myrealm page, display the Providers tab, then display the Authentication sub-tab.

  14. Click Reorder. to display the Reorder Authentication Providers page.

  15. Select ADDirectory and use the arrow buttons to move it into the first position in the list, then click OK.

  16. In the Change Center, click Activate Changes.

  17. Restart Oracle WebLogic Server.

3.4.3 Configuring a Database as the Authentication Provider

This section describes how to configure Oracle Business Intelligence to use a database as the authentication provider by using a SQLAuthenticator and a virtualized identity store database adapter, and contains the following topics:

3.4.3.1 Introduction and Prerequisites

You can configure more than one identity store to enable user role and profile information to be split across different identity stores (for example, LDAP and database identity stores) using virtualization.

User role and profile information can be stored in a database with the help of an adapter that enables the database to appear like an LDAP server. A virtualized identity store provider can retrieve user profile information from a database through a database adapter.

The method of database authentication described here is only possible in release 11.1.1.5 (and later), because earlier releases require the use of INIT blocks.

This topic explains how to configure Oracle Business Intelligence with a SQLAuthenticator and a virtualized identity store provider (including a database adapter), both running against a suitable database schema. The examples given are illustrative only, and your database schema need not be identical to the sample described here.

Use this procedure when you need to authenticate users against a database schema. The preferred identity store for authentication purposes is an LDAP directory service, such as Oracle Internet Directory (OID).

The approach to database authentication described here requires two database columns, one containing users and another containing passwords. This method is not based on database user accounts.

Oracle Business Intelligence Enterprise Edition version 11.1.1.5.0 (or later) must be installed and running.

3.4.3.2 Creating a Sample Schema

In practice, you will have your own schemas, which you are using in an earlier installation of Oracle BI EE. The sample schema described here is deliberately simplistic, and is intended only to illustrate how to configure the system to use the schema.

Note:

A suitable database schema containing the users, credentials and groups required for authentication, must be accessible from the WebLogic server on which Oracle BI EE is running.

Figure 3-2 has tables, USER, GROUP and USER_GROUP, where USER_GROUP serves to join the other two tables.

Figure 3-2 Sample Schema

Surrounding text describes Figure 3-2 .

If either USER, USER_GROUP or GROUP information exist in more than one table, you must create a view over the tables of each type of information. You can then present the views to the database adapter, configured in Section 3.4.3.3.2.

3.4.3.3 Configuring a Data Source and SQL Authenticator in Oracle WebLogic Server Administration Console

You configure a data source and SQL authenticator in Oracle WebLogic Server Administration Console as follows:

3.4.3.3.1 Configuring a Data Source Using Oracle WebLogic Server Administration Console

To configure a data source using Oracle WebLogic Server Administration Console:

  1. Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

  2. Click Services in the left pane and click Data Sources.

  3. In the Summary of Data Sources page, click New, and choose Generic Data Source.

  4. In the JDBC Data Sources Properties page, enter or select values for the following properties:

    • Name - For example, enter: UserGroupDS

      The name used in the underlying configuration file (config.xml) and throughout the Administration Console whenever referring to this data source.

    • JNDI Name - For example, enter: jdbc/User GroupDS

      The JNDI path to which this JDBC data source will be bound.

    • Database Type - For example, select: Oracle

      The DBMS of the database that you want to connect to.

  5. Click Next.

  6. Choose a database driver from the Database Driver drop down list.

    For example, select: Oracle's Driver (Thin) for Service Connections; Versions:9.0.1 and later

  7. Click Next.

  8. Click Next.

  9. On the Connection Properties page, enter values for the following properties:

    • Database Name - For example, enter: ora11g

      The name of the database that you want to connect to.

    • Host Name - For example, enter: mymachine.mycompany.com

      The DNS name or IP address of the server that hosts the database.

    • Port - For example, enter: 1521

      The port on which the database server listens for connections requests.

    • Database User Name

      Typically the schema owner of the tables defined in Section 3.4.3.2

    • Password/Confirm Password

      The password for the Database User Name.

  10. Click Next.

  11. Check the details on the page are correct, and click Test Configuration.

  12. Click Next.

  13. In the Select Targets page select the servers or clusters for your datasource to be deployed to.

    You should select the Administration Server and Managed server(s) as your targets, for example:

    • In the Servers pane

      Select the AdminServer check box.

    • In the Clusters pane

      Select the bi_server1 check box.

  14. Click Finish.

  15. In the Change Center, click Activate Changes.

  16. Restart Oracle WebLogic Server.

3.4.3.3.2 Configuring a SQL Authenticator using Oracle WebLogic Server Administration Console

This task enables a suitably privileged user to log in to the Oracle WebLogic Server Administration Console using the WebLogic database authenticator.

To configure a SQL authenticator using Oracle WebLogic Server Administration Console:

  1. Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

    This screenshot or diagram is described in surrounding text.
    Description of the illustration wls01.gif

  2. Select Security Realms from the left pane and click myrealm.

    The default Security Realm is named myrealm.

  3. Display the Providers tab, then display the Authentication sub-tab.

    This screenshot or diagram is described in surrounding text.
    Description of the illustration wls03.gif

  4. Click New to launch the Create a New Authentication Provider page.

    This screenshot or diagram is described in surrounding text.
  5. Enter values in the Create a New Authentication Provider page as follows:

    • Name: Enter a name for the authentication provider. For example, UserGroupDBAuthenticator.

    • Type: Select ReadOnlySQLAuthenticator from the list.

      This creates a read only SQL Authenticator, and WebLogic will not write back to the database.

    • Click OK to save the changes and display the authentication providers list updated with the new authentication provider.

      This screenshot or diagram is described in surrounding text.
  6. In the authentication providers table, click UserGroupDBAuthenticator in the Name column to display the Settings page.

  7. Display the Provider Specific tab to specify the SQL statements used to query, and authenticate against, your database tables.

    Figure 3-1 shows SQL statements for the sample schema outlined in Section 3.4.3.2

    Table 3-1 SQL Statements for the Sample Schema

    Query SQL Notes

    SQL Get Users Password (used to authenticate)

    SELECT PASSWORD FROM USER WHERE USER_ID = ?

    The SQL statement used to look up a user's password. The SQL statement requires a single parameter for the username and must return a resultSet containing at most a single record containing the password.

    SQL User Exists

    SELECT USER_ID FROM USER WHERE USER_ID = ?

    The SQL statement used to look up a user. The SQL statement requires a single parameter for the username and must return a resultSet containing at most a single record containing the user.

    SQL List Users

    SELECT USER_ID FROM USER WHERE USER_ID LIKE ?

    The SQL statement used to retrieve users that match a particular wildcard search The SQL statement requires a single parameter for the wildcarded usernames and returns a resultSet containing matching usernames.

    SQL List Groups

    SELECT GROUP_ID FROM GROUP WHERE GROUP_ID LIKE ?

    The SQL statement used to retrieve group names that match a wildcard The SQL statement requires a single parameter for the wildcarded group name and return a resultSet containing matching groups.

    SQL Group Exists

    SELECT GROUP_ID FROM GROUP WHERE GROUP_ID = ?

    The SQL statement used to look up a group. The SQL statement requires a single parameter for the group name and must return a resultSet containing at most a single record containing the group.

    SQL Is Member

    SELECT GROUP_ID FROM USER_GROUP WHERE GROUP_ID=? AND USER_ID LIKE ?

    The SQL statement used to look up members of a group. The SQL statement requires two parameters: a group name and a member or group name. It must return a resultSet.

    SQL List Member Groups

    SELECT GROUP_ID FROM USER_GROUP WHERE USER_ID = ?

    The SQL statement used to look up the groups a user or group is a member of. The SQL statement requires a single parameter for the username or group name and returns a resultSet containing the names of the groups that matched.

    SQL Get User Description (if description supported enabled)

    SELECT USER_NAME FROM USER WHERE USER_ID = ?

    The SQL statement used to retrieve the description of a specific user. The SQL statement requires a single parameter for the username and must return a resultSet containing at most a single record containing the user description.

    SQL Get Group Description (if description supported enabled)

    SELECT GROUP_DESCRIPTION FROM GROUP WHERE GROUP_ID = ?

    The SQL statement used to retrieve the description of a group. Only valid if Descriptions Supported is enabled. The SQL statement requires a single parameter for the group name and must return a resultSet containing at most a single record containing the group description.


    Note:

    If you are using a different table structure, you might need to adapt these SQL statements (table or column names) to your own schema. Also, you should leave the question mark (?) as a runtime query placeholder (rather than hardcode a user or group name).

    For more information about configuring authentication providers in Oracle WebLogic Server, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

  8. Enter all of the SQL statements appropriate to your Authenticator.

  9. If your password column is in plaintext (that is, if the result of the query supplied for the SQL Get Users Password column is not hashed/encrypted), select the Plaintext Password Enabled checkbox.

    If the Plaintext Password Enabled checkbox is cleared, the SQLAuthenticator expects passwords to have been hashed using SHA-1 (default encryption algorithm). For more information on the supported encryption algorithms, see the documentation for the base SQLAuthenticator Mbean PasswordAlgorithm attribute.

  10. Click Save.

  11. Perform the following steps to configure default authenticator Control Flag setting:

    1. At the main Settings for myrealm page, display the Providers tab, then display the Authentication sub-tab, then select DefaultAuthenticator to display its configuration page.

    2. Display the Configuration\Common tab and select 'SUFFICIENT' from the Control Flag list.

      For more information, see Section 3.4.5, "Setting the JAAS Control Flag Option".

    3. Click Save.

  12. Perform the following steps to reorder the Authentication Providers:

    1. Display the Providers tab.

    2. Click Reorder to display the Reorder Authentication Providers page

    3. Select UserGroupDBAuthenticator and use the arrow buttons to move it into the first position in the list.

    4. Click OK to save your changes.

  13. You must ensure there is a trusted system user in your database and that you replace the credentials in the Credential store to point to this user's credentials as described in Section 3.7, "Configuring a New Trusted User (BISystemUser)".

  14. In the Change Center, click Activate Changes.

  15. Restart the BI components (use Fusion Middleware Control once the Administration Server has been restarted), Oracle WebLogic Server, and Managed Server(s).

Note:

Check the Users and Groups tab to confirm that the database users and groups appear there.

3.4.3.4 Configuring the Virtualized Identity Store

You configure the virtualized identity store as follows:

3.4.3.4.1 Enabling Virtualization by Configuring the Identity Store

You configure the identity store to enable virtualization so that more than one Identity Store can be used with the identity store service, and therefore user profile information can be split across different authentication providers (identity stores).

For more information, see Section 3.4.4, "Configuring Multiple Authentication Providers Using Fusion Middleware Control".

3.4.3.4.2 Configuring a Database Adaptor

You configure a database adaptor to make the database appear like an LDAP server, which enables the virtualized identity store provider to retrieve user profile information from a database using the database adapter.

To configure a database adaptor:

This task shows how to edit and apply adapter templates that specify how to use your database tables as an identity store.

  1. Create a file named adapter_template_usergroup1.xml.

    This file describes the mapping of the user table to a virtual LDAP store.

  2. Make sure that the file contains the following contents:

    Note:

    You must adapt the section shown in bold, to match the columns in your own table/attributes used in the LDAP server, the sample shown here is for the sample schema being used throughout Section 3.4.3.
    <?xml version = '1.0' encoding = 'UTF-8'?>
    <adapters schvers="303" version="1" xmlns="http://www.octetstring.com/schemas/Adapters" xmlns:adapters="http://www.w3.org/2001/XMLSchema-instance">
       <dataBase id="directoryType" version="0">
          <root>%ROOT%</root>
          <active>true</active>
          <serverType>directoryType</serverType>
          <routing>
             <critical>true</critical>
             <priority>50</priority>
             <inclusionFilter/>
             <exclusionFilter/>
             <plugin/>
             <retrieve/>
             <store/>
             <visible>Yes</visible>
             <levels>-1</levels>
             <bind>true</bind>
             <bind-adapters/>
             <views/>
             <dnpattern/>
          </routing>
          <pluginChains xmlns="http://xmlns.oracle.com/iam/management/ovd/config/plugins">
             <plugins>
                <plugin>
                   <name>DBGUID</name>
                   <class>oracle.ods.virtualization.engine.chain.plugins.dbguid.DBGuidPlugin</class>
                   <initParams>
                      <param name="guidAttribute" value="orclguid"/>
                   </initParams>
                </plugin>
             </plugins>
             <default>
                <plugin name="DBGUID"/>
             </default>
             <add/>
             <bind/>
             <delete/>
             <get/>
             <modify/>
             <rename/>
          </pluginChains>
          <driver>oracle.jdbc.driver.OracleDriver</driver>
          <url>%URL%</url>
          <user>%USER%</user>
          <password>%PASSWORD%</password>
          <ignoreObjectClassOnModify>false</ignoreObjectClassOnModify>
          <includeInheritedObjectClasses>true</includeInheritedObjectClasses>
          <maxConnections>10</maxConnections>
          <mapping>
             <joins/>
             <objectClass name="inetorgperson" rdn="cn">
                <attribute ldap="cn" table="USER" field="USER_NAME" type=""/>
                <attribute ldap="uid" table="USER" field="USER_ID" type=""/>
                <attribute ldap="usernameattr" table="USER" field="USER_NAME" type=""/>
                <attribute ldap="loginid" table="USER" field="USER_ID" type=""/>
                <attribute ldap="description" table="USER" field="USER_NAME" type=""/>
         <attribute ldap="orclguid" table="USER" field="USER_ID" type=""/>
             </objectClass>
          </mapping>
          <useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
          <connectionWaitTimeout>10</connectionWaitTimeout>
          <oracleNetConnectTimeout>0</oracleNetConnectTimeout>
          <validateConnection>false</validateConnection>
       </dataBase>
    </adapters>
    

    In this example the section highlighted in bold should be the only section that needs customizing, but the elements should be mapped by matching the attributes/classes used in a virtual LDAP schema with the columns in your database which correspond to them. The virtual schema is the same as that of Weblogic Embedded LDAP, so you can map database columns to any of the attributes shown in Table 3-2.

    Table 3-2 Examples of Attributes to Map to Database Columns

    Attribute Example

    description

    John Doe

    cn

    john.doe

    uid

    john.doe

    sn

    Doe

    userpassword

    welcome1

    displayName

    John Doe

    employeeNumber

    12345

    employeeType

    Regular

    givenName

    John

    homePhone

    650-555-1212

    mail

    john.doe@example.com

    title

    Manager

    manager

    uid=mary.jones,ou=people,ou=myrealm,dc=wc_domain

    preferredLanguage

    en

    departmentNumber

    tools

    facsimiletelephonenumber

    650-555-1200

    mobile

    650-500-1200

    pager

    650-400-1200

    telephoneNumber

    650-506-1212

    postaladdress

    200 Oracle Parkway

    l

    Redwood Shores

    homepostaladdress

    123 Main St., Anytown 12345


  3. Use the first, outer element (<objectClass name="inetorgperson" rdn="cn">) to declare mapping of the LDAP objectclass inetorgperson.

    The cn attribute is used as its RDN (Relative Distinguished Name). The sub-elements then declare which LDAP attributes map to which tables and columns in the database. For example, the line <attribute ldap="uid" table="USER" field="USER_ID" type=""/> means that we wish to map the USER_ID field of the USER table to the standard LDAP attribute uid (that is, a unique user id for each user).

    Next, you map groups using the same method.

  4. Create a file named adapter_template_usergroup2.xml.

    This file describes the mapping of the group table to a virtual LDAP store.

  5. Add the following contents to the file:

    You must customize the section shown in bold to match the columns in your own table. The sample content shown here is to match the sample schema we have been using throughout this example.

    <?xml version = '1.0' encoding = 'UTF-8'?>
    <adapters schvers="303" version="1" xmlns="http://www.octetstring.com/schemas/Adapters" xmlns:adapters="http://www.w3.org/2001/XMLSchema-instance">
        <dataBase id="directoryType" version="0">
          <root>%ROOT%</root>
          <active>true</active>
          <serverType>directoryType</serverType>
          <routing>
             <critical>true</critical>
             <priority>50</priority>
             <inclusionFilter/>
             <exclusionFilter/>
             <plugin/>
             <retrieve/>
             <store/>
             <visible>Yes</visible>
             <levels>-1</levels>
             <bind>true</bind>
             <bind-adapters/>
             <views/>
             <dnpattern/>
          </routing>
          <pluginChains xmlns="http://xmlns.oracle.com/iam/management/ovd/config/plugins">
             <plugins>
                <plugin>
                   <name>VirtualAttribute</name>
                   <class>oracle.ods.virtualization.engine.chain.plugins.virtualattr.VirtualAttributePlugin</class>
                   <initParams>
                      <param name="ReplaceAttribute" value="uniquemember={cn=%uniquemember%,cn=users,dc=oracle,dc=com}"/>
                   </initParams>
                </plugin>
             </plugins>
             <default>
                <plugin name="VirtualAttribute"/>
             </default>
             <add/>
             <bind/>
             <delete/>
             <get/>
             <modify/>
             <rename/>
          </pluginChains>
          <driver>oracle.jdbc.driver.OracleDriver</driver>
          <url>%URL%</url>
          <user>%USER%</user>
          <password>%PASSWORD%</password>
          <ignoreObjectClassOnModify>false</ignoreObjectClassOnModify>
          <includeInheritedObjectClasses>true</includeInheritedObjectClasses>
          <maxConnections>10</maxConnections>
          <mapping>
             <joins/>
             <objectClass name="groupofuniquenames" rdn="cn">
                <attribute ldap="cn" table="USER_GROUP" field="GROUP_ID" type=""/>
                <attribute ldap="description" table="USER_GROUP" field="GROUP_ID" type=""/>
                <attribute ldap="uniquemember" table="USER_GROUP" field="USER_ID" type=""/>
             </objectClass>
          </mapping>
          <useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
          <connectionWaitTimeout>10</connectionWaitTimeout>
          <oracleNetConnectTimeout>0</oracleNetConnectTimeout>
          <validateConnection>false</validateConnection>
       </dataBase>
    </adapters>
    
  6. Customize appropriate sections highlighted in bold, for the following elements:

    • ReplaceAttribute

      Specifies how to define the unique member for a group (the %uniquemember% is a placeholder for a value which will be passed in at runtime when looking up whether a user is a member of a group)

      The only aspect of this element you may wish to change is the specification of the root for your users. While this is notional, by default it must match whatever you specify as the root of your user population when you run the libovdadapterconfig script in step 10.

    • groupofuniqueness

      Specifies how group attributes are mapped to database fields and as with the user, the attributes correspond to the defaults in Weblogic Embedded LDAP.

      You must map the following attributes:

      • cn (map to a unique name for your group)

      • uniquemember (map to the unique name for your user in the user/group mapping table in your database schema)

      Mapping the following attributes is optional:

      • description is optional (although clearly helpful)

      • orclguid (maps to a UID, if available in your database schema)

      No other attributes are user-configurable.

  7. Copy the two adapter files into the following folder:

    <MW_HOME>/oracle_common/modules/oracle.ovd_11.1.1/templates/

  8. Open a command prompt/terminal at:

    <MW_HOME>/oracle_common/bin

  9. Ensure the following environment variables are set:

    • ORACLE_HOME=<MW_HOME>/Oracle_BI1

    • WL_HOME=<MW_HOME>/wlserver_10.3/

    • JAVA_HOME=<MW_HOME>/jdk160_24/

  10. Run the libovdadapterconfig script to create each of the two adapters from the template files above. The syntax is:

    libovdadapterconfig -adapterName <name of adapter> -adapterTemplate <name (NOT including path) of template file which defines adapater> -host localhost -port <Admin Server port> -userName <user id of account which has administrative privileges in the domain> -domainPath <path to the BI domain> -dataStore DB -root <nominal specification of a pseudo-LDAP query to treat as the "root" of this adapter - must match that specified in template for adapter 2 above> -contextName default -dataSourceJNDIName <JNDI name for DataSource which points at the database being mapped>
    

    For example:

    ./libovdadapterconfig.sh -adapterName userGroupAdapter1 -adapterTemplate adapter_template_usergroup1.xml -host localhost -port 7001 -userName weblogic -domainPath /opt/oracle_bi/user_projects/domains/bifoundation_domain/ -dataStore DB -root cn=users,dc=oracle,dc=com -contextName default -dataSourceJNDIName UserGroupsDS
    
    ./libovdadapterconfig.sh -adapterName userGroupAdapter2 -adapterTemplate adapter_template_usergroup2.xml -host localhost -port 7001 -userName weblogic -domainPath /opt/oracle_bi/user_projects/domains/bifoundation_domain/ -dataStore DB -root cn=users,dc=oracle,dc=com -contextName default -dataSourceJNDIName UserGroupsDS
    

    The scripts should exit without error.

  11. Restart WebLogic Administration Server and Managed Server(s).

    You should now be able to login to WebLogic and Oracle Business Intelligence using credentials stored in the database

3.4.3.5 Troubleshooting the SQL Authenticator

This section provides troubleshooting information on the SQL authenticator, and contains the following topics:

3.4.3.5.1 Adding or Removing Users to or from a Role Using Oracle WebLogic Server Administration Console

If you are unable to log in to Oracle Business Intelligence using a database user, a useful diagnostic test is to see whether your user can log in to WebLogic at all. If you do not have other applications on the WebLogic server which take advantage of WebLogic container authentication, you can add your user (temporarily) to the WebLogic Global Admin role and see if they can log in to the Oracle WebLogic Server Administration Console to test whether the SQLAuthenticator is working at all.

To add or remove users to or from this role using the Oracle WebLogic Server Administration Console:

  1. Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

  2. Select Security Realms from the left pane and click myrealm.

    The default Security Realm is named myrealm.

  3. Display the Roles and Policies tab, then display the Realm Roles sub-tab.

    This screenshot is described in the surrounding text.
  4. In the list of roles, click on the plus sign to expand Global Roles, then Roles, then click the View Role Conditions link for the Admin role.

  5. Ensure the conditions specified will match your user, either directly, or by virtue of a group they belong to.

    For example, a condition may be User=myadminaccount or Group=Administrators.

  6. If you have made any changes, click Save.

    Changes will apply immediately.

  7. You should now be able to check whether the user in question can log in to the Oracle WebLogic Server Administration Console at http://<bi server address>:<AdminServer Port>/console (for example, http://mybiserver:7001/console).

    If the user can, but cannot log in to Oracle Business Intelligence, the SQLAuthenticator is working correctly, but there may be issues in the identity store service. Check that you have specified the virtualize=true property in Section 3.4.3.4, "Configuring the Virtualized Identity Store" and that your DBAdapter templates are correct.

3.4.3.5.2 Wrong Datasource Name Specified

If you specify the wrong JNDI name for the datasource field of the SQLAuthenticator, this will cause errors to appear in the Weblogic AdminServer/Managed Server(s) log files, such as the following:

Caused by: javax.security.auth.login.FailedLoginException: [Security:090761]Authentication failed for user jsmith java.sql.SQLException: [Security:090788]"Problem with DataSource/ConnectionPool configuration, verify DataSource name wrongdsname is correct and Pool configurations are correct"
        at weblogic.security.providers.authentication.shared.DBMSAtnLoginModuleI
mpl.login(DBMSAtnLoginModuleImpl.java:318)

You should use the fully qualified JNDI name, not the Name field of the DataSource, so in the example shown in Section 3.4.3.3.1, "Configuring a Data Source Using Oracle WebLogic Server Administration Console", the name of the DataSource was UserGroupDS but the JNDI name was jdbc/UserGroupDS and it is this fuller form which you should use.

3.4.3.5.3 Incorrect SQL Queries

Take care that the SQL queries you specify in the SQLAuthenticator config are syntactically correct and refer to the correct tables etc. For example, the following error occurs in the AdminServer.log when the wrong table name is specified for the password query

####<Jul 7, 2011 4:03:27 PM BST> <Error> <Security> <gbr20020> <AdminServer> <[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <de7dd0dc53f3d0ed:e0ce69e:131007c1afe:-8000-00000000000007fa> <1310051007798> <BEA-000000> <[Security:090759]A SQLException occurred while retrieving password information
java.sql.SQLSyntaxErrorException: ORA-00942: table or view does not exist
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:457)
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:405)
     at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:889)
     at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:476)

3.4.3.6 Correcting Errors in the Adaptors

You cannot modify an existing database adapter, so if you make an error in either the libovdadapter command, or the template(s) you use to create the adapters, you must delete then recreate the adapter using the following procedure:

To delete then recreate the database adaptor:

  1. Log into the WSLT console by running the WLST script at:

    <BI Install Directory>/oracle_common/common/bin/ /wlst[.sh/cmd]

  2. Connect to your admin server using the following syntax:

    connect('<WLS admin user name>','<WLS admin password>','t3://<admin server host>:<admin server port>')

    For example:

    connect('weblogic','weblogic','t3://myserver:7001')

  3. Delete the misconfigured adaptor using the following syntax:

    deleteAdaptor(adaptorName='<AdaptorName>')

    For example:

    deleteAdaptor(adaptorName='userGroupAdaptor2')

  4. Exit the WLST console using the command exit() and recreate the adapter with the correct settings by following the steps outlined in Section 3.4.3.4.2.

3.4.4 Configuring Multiple Authentication Providers Using Fusion Middleware Control

This section describes how to configure Oracle Business Intelligence to use multiple authentication providers using Fusion Middleware Control.

To configure multiple authentication providers using Fusion Middleware Control:

If you are communicating with LDAP over SSL (one-way SSL only), see Section 5.4.6, "Configuring SSL when Using Multiple Authenticators".

  1. (Optional) If not already done, configure supported authentication providers as described in Section 3.4.

  2. Log in to Fusion Middleware Control.

    For more information, see Section 1.6.2, "Using Oracle Fusion Middleware Control".

  3. From the navigation pane expand the WebLogic Domain folder and select bifoundation_domain.

  4. Right-click bifoundation_domain and select Security, then Security Provider Configuration to display the Security Provider Configuration page.

    This screenshot is described in the surrounding text.
  5. In the Identity Store Provider area, click Configure to display the Identity Store Configuration page.

    This screenshot is described in the surrounding text.
  6. In the Custom Properties area, use the Add option to add a new custom property as follows:

    Property Name=virtualize

    Value=true

    Note:

    If you are using multiple authentication providers, go to Section 3.4, "Configuring Alternative Authentication Providers" and configure the Control Flag setting as follows:
    • If each user appears in only one authentication provider

      set the value of Control Flag for all authentication providers to SUFFICIENT

    • If users appear in more than one authentication provider (for example, if a user's group membership is spread across more than one authentication provider)

      set the value of Control Flag for all authentication providers to OPTIONAL

  7. Click OK to save the changes.

  8. Restart the Administration Server and Managed Servers.

3.4.5 Setting the JAAS Control Flag Option

When you configure multiple Authentication providers, use the JAAS Control Flag for each provider to control how the Authentication providers are used in the login sequence. You can set the JAAS Control Flag in the Oracle WebLogic Server Administration Console. For more information, See "Set the JAAS control flag" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help. You can also use the WebLogic Scripting Tool or Java Management Extensions (JMX) APIs to set the JAAS Control Flag for an Authentication provider.

Setting the Control Flag attribute for the authenticator provider determines the ordered execution of the authentication providers. The possible values for the Control Flag attribute are:

  • REQUIRED - This LoginModule must succeed. Even if it fails, authentication proceeds down the list of LoginModules for the configured Authentication providers. This setting is the default.

  • REQUISITE - This LoginModule must succeed. If other Authentication providers are configured and this LoginModule succeeds, authentication proceeds down the list of LoginModules. Otherwise, control is returned to the application.

  • SUFFICIENT - This LoginModule need not succeed. If it does succeed, return control to the application. If it fails and other Authentication providers are configured, authentication proceeds down the LoginModule list.

  • OPTIONAL - This LoginModule can succeed or fail. However, if all Authentication providers configured in a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the configured providers.

When additional Authentication providers are added to an existing security realm, by default the Control Flag is set to OPTIONAL. If necessary, change the setting of the Control Flag and the order of Authentication providers so that each Authentication provider works properly in the authentication sequence.

3.4.6 Configuring an LDAP Authentication Provider as the Single Source

This topic explains how to reconfigure Oracle Business Intelligence to use a single LDAP authentication provider, by switching off the default WLS LDAP authenticator.

When you install Oracle Business Intelligence, the system is automatically configured to use WebLogic Server (WLS) LDAP as the default authenticator. The install process will automatically generate the required users and groups in WLS LDAP. However, you may have your own LDAP directory (for example Oracle Internet Directory) that you may want to use as the default authenticator, and switch off the WLS default authenticator. Having a single source authentication provider prevents user names and passwords being derived from multiple authentication sources, which could lead to multiple points of attack, or entry from unauthorizeed users.

This topic contains the following sections:

3.4.6.1 Configuring Oracle Internet Directory LDAP Authentication as the Single Source

The examples shown in this section are for configuring Oracle Internet Directory (OID) but could easily apply to other LDAP authentication providers by using minor changes.

To configure Oracle Internet Directory LDAP authentication as the single source:

Task 1   Backup and Recovery

Before you begin the process of switching off the WLS LDAP default method of authentication it is strongly recommended that you back up the system first. Otherwise, if you make an error during configuration you may find that you become locked out of the system or be unable to restart it.

To enable backup and recovery, during the re-configuration phase, take a copy of the config.xml file in <BIEE_HOME>\user_projects\domains\bifoundation_domain\config directory.

As you make changes it is advised that you keep copies of this file.

Task 2   WLS Removal Prerequisites

To remove the default WLS authenticators and use an alternative LDAP source (for example, OID), you must set the system up to use both WLS and the alternative method. For more information, see Section 3.4, "Configuring Alternative Authentication Providers". Your starting point should be that the WLS LDAP users (default authenticator) and the new alternative LDAP users are both configured to allow access to Oracle Business Intelligence.

When you have set this up to enable you to log on as either a WebLogic Server LDAP user or an OID LDAP user, you can then proceed to follow the steps to remove the WebLogic Server default authenticator, as described in these tasks.

Task 3   Identify or Create Essential Users Required in OID LDAP

You must ensure that the essential users shown in Table 3-3 are migrated from WebLogic Server LDAP to OID LDAP.

Table 3-3 Essential Users Required in OID

Users Standard WLS Users New Users Required in OID

1

BISystemUser

OID_BISystemUser (this can be any existing OID user)

2

WebLogic

OID_Weblogic (This can be any existing OID user)

3

OracleSystemUser

OracleSystemUser (This User has to exist with this name in OID - fixed requirement of OWSM)


Three users are created during install:

  • BISystemUser

    This user is created in WebLogic Server , and is used to perform the communication between Presentation Services and BI Server components. You must create or identify an equivalent user in OID LDAP (for example, OID_BISystemUser). Ensure that the passwords used here confirm to your security password standards (for example, never use welcome1).

  • Weblogic (specified during install or upgrade, so can be different).

    This administrator user is created during the install (sometimes called Weblogic, but can have any name). You need to identify or create an equivalent user in OID but this user can have any name.

  • OracleSystemUser

    This user is specifically required (by Oracle Web Services Manager - OWSM) for the Global Roles mapping, and you must create this user in OID using this exact name.

Task 4   Identify or Create Essential Groups in OID LDAP

The essential groups shown in Table 3-4 are required in the OID LDAP directory.

Table 3-4 Essential Groups Required

Groups WLS Groups Automatically Created New OID Groups Required

1

Administrators

OID_Administrators

2

AdminChannelUsers

OID_AdminChannelUsers

3

AppTesters

OID_AppTesters

4

CrossDomainConnectors

OID_CrossDomainConnectors

5

Deployers

OID_Deployers

6

Monitors

OID_Monitors

7

Operators

OID_Operators

8

OracleSystemGroup

OracleSystemGroup (fixed requirement)

9

BIAdministrators

OID_BIAdministrators

10

BIAuthors

OID_BIAuthors

11

BIConsumers

OID_BIConsumers


The groups in Table 3-4 are automatically created in WLS during the default Oracle Business Intelligence installation process.

Before you can remove the default WLS authentication you need to identify OID groups that will replace the WLS groups. You can choose to have an individual OID group for each WLS group (in Table 3-4) or use a single OID group to replace one or many WLS groups.

Currently the only specific requirement is that you must have a group defined in OID as OracleSystemGroup using this exact name (an OWSM requirement).

Task 5   Associate OID Groups with Global Roles in the WebLogic Console

The global role mappings shown in Table 3-5 must be configured in OID.

Table 3-5 Global Role Mapping in WebLogic Admin Console

Users Global Roles Current WLS Groups New OID Groups Required

1

Admin

Administrators

OID_Administrators

2

AdminChannelUsers

AdminChannelUsers

OID_AdminChannelUsers

3

AppTester

AppTesters

OID_AppTesters

4

CrossDomainConnector

CrossDomainConnectors

OID_CrossDomainConnectors

5

Deployer

Deployers

OID_Deployers

6

Monitor

Monitors

OID_Monitors

7

Operator

Operators

OID_Operators

8

OracleSystemRole

OracleSystemGroup

OracleSystemGroup (fixed requirement)


You must associate the global roles from Table 3-5 (displayed in the WLS console) with your replacement OID groups (defined in Task 4), before you can switch off the default WLS authenticator.

To associate OID groups with global roles in Oracle WebLogic Server Administration Console:

  1. Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.

    For more information, see Section 1.6.1, "Using Oracle WebLogic Server Administration Console".

  2. Select Security Realms from the left pane and click myrealm.

    The default Security Realm is named myrealm.

  3. Click Realm Roles.

  4. Click Global Roles and expand Roles.

    WLS console realm roles showing global roles.
  5. Add a new condition for each Role as follows:

    Note:

    Do not do this for Anonymous and Oracle System role, which can both remain unchanged.
    1. Click View Role Conditions.

    2. Select group from the Predicate List drop down.

    3. Enter your newly-associated OID group from Table 3-4.

      For example, you would assign the Admin role to the OID_Administrators role.

      Mapped Admin global role with OID role

      Note:

      Once you have successfully switched off the Default WLS Authentication you can return here and remove the old WLS groups (for example, here you would remove Group: Administrators. For more information, see Task 12, "Post Single LDAP OID Authentication Setup tasks"
    4. Save your changes.

Task 6   Set User to Group Membership in OID LDAP

Now that you have created new users and groups in OID to replicate the users and groups automatically created in WLS LDAP you will need to ensure that these users and groups also have the correct group membership in OID as shown in Table 3-6.

Table 3-6 User to Group Membership Required in OID

Groups New OID User Is A Member Of These New OID Groups

1

OID_BISystemUser

OID_Administrators

Note: You can choose to assign this to OID_BIAdministrators rather than OID_Administrators, if required, as this will also work.

2

OID_Weblogic

OID_Administrators

OID_BIAdministrators

3

OracleSystemUser

Note: A user with this exact name must exist in OID.

OracleSystemGroup

Note: A group with this exact name must exist in OID


Note:

In order to achieve the user and group membership shown in Table 3-6 you must have suitable access to update your LDAP OID server, or someone else must be able to update group membership on your behalf.
Task 7   Set OID Users and Groups Application Roles Membership in Fusion Middleware Control

You must add the recently created OID users and groups (in Table 3-7), as members of existing application roles using Fusion Middleware Control.

Table 3-7 OID User and Group Application Roles Membership Required in Fusion Middleware Control

Groups Make a member of the existing WLS application roles New OID User/Groups

1

BISystem

OID_BISystemUser (OID user)

2

BIAdministrator

OID_BIAdministrators (OID group

3

BIAuthor

OID_ BIAuthors (OID group)

4

BIConsumer

OID_BIConsumers (OID group)


To set required OID users and group application roles membership using Fusion Middleware Control:

  1. Log in to Fusion Middleware Control.

    For more information, see Section 1.6.2, "Using Oracle Fusion Middleware Control".

  2. From the navigation pane expand the Business Intelligence folder and select coreapplication.

  3. Display the application roles for Oracle Business Intelligence.

    For more information, see Section 2.4.1, "Displaying Application Policies and Application Roles Using Fusion Middleware Control"

  4. Assign members to application roles as follows:

    Mapping OID members to existing Application Roles.

    Caution: Although you can assign groups to the BISystem application role you should only ever assign users to this role to protect security.

Task 8   Update the Credential Store Password for the New Trusted System User

The user name and password you created for the BISystemUser in OID must be exactly the same as created in Task 3, "Identify or Create Essential Users Required in OID LDAP" (for example, for the OID_BISystemUser).

To update the Credential Store password for the new OID_BISystemUser:

  1. Log in to Fusion Middleware Control.

    For more information, see Section 1.6.2, "Using Oracle Fusion Middleware Control".

  2. From the navigation pane expand the WebLogic Domain folder and select bifoundation_domain.

  3. Click WebLogic Domain in main pane to display a menu, then choose Security, and Credentials to display the Credentials page.

  4. Expand oracle.bi.system and select system.user.

  5. Click the Edit to display the Edit Key dialog.

    Edit Key dialog enter new oid details for authentication.
  6. Input the new user name and password.

  7. Click OK.

Task 9   Delete the Default Authenticator

You are now ready to remove the Default Authenticators.

To remove the default authenticators:

You must have first created an LDAP authenticator that maps to your LDAP source (for more information, see Task 2, "WLS Removal Prerequisites").

  1. Change the Control Flag from SUFFICIENT to REQUIRED in the Oracle WebLogic Server Administration Console.

    For more information, see Section 3.4.5, "Setting the JAAS Control Flag Option".

    Changing control flag to Required for OID.

  2. Save the changes.

  3. Delete any other authenticators so that your LDAP OID authenticator is the single source.

    OID provider is now the single source.
Task 10   (Optional) Remove Old GUID References

Complete this task if you are using OID LDAP for the first time, that is, if moving from a 10g LDAP authentication (upgraded to 11g) to OID LDAP authentication. This will resynchronize the system user GUID's (Global Unique Identifiers). Otherwise you may find you are unable to login and will get the following error message:

The GUID of user {username} does not match user reference GUID of the repository. Please ask the administrator to delete the old user reference at the repository and login again.

To remove old GUID references:

  1. Stop all Oracle Business Intelligence Services.

    In Windows use the menu option Stop BI Services providing the original administrator user name, and password specified during install (for example, weblogic/welcome1).

  2. In the Administration Tool, open the repository file that you are using in 11g, in offline mode.

  3. Select Manage and Identity from the menu.

  4. Click BI Repository and display the Users tab.

  5. Select all users and delete them.

    Note:

    If you have specific permissions defined in the repository file for a particular user these will be lost. In this case, when you start up your Business Intelligence system you will need to re-associate any user level permissions with these users in your LDAP (OID) source. This will ensure that a user with the same name, (but who is not the same person), will be identified correctly by the system, as a different user.

    Deleting RPD users in the BI Admin Tool.

Task 11   Restart the BI Services

Now you are ready to restart the BI services. You must use the new OID administrator user (for example, OID_Weblogic), because the WebLogic Server administration user created during installation was removed, and users now exist in the single OID source. The OID administration user must have sufficient privileges (granted by the Global Admin role) to start WebLogic.

Note:

When you log in to the Administration Tool online you must now provide the OID user and password (for example, OID_Weblogic) along with the repository password.
Task 12   Post Single LDAP OID Authentication Setup tasks

Complete this task if everything is working correctly.

Note:

Back up your config.xml, now, before performing this step (see Task 1, "Backup and Recovery")

Edit Global Roles (section: Task 5, "Associate OID Groups with Global Roles in the WebLogic Console") Removing all the WebLogic Server Roles from the OR clause, that were automatically created. Such as:

  • Admin

  • AdminChannelUsers

  • AppTester

  • CrossDomainConnector

  • Deployer

  • Monitor

  • Operator

Task 13   Stop Alternative Methods of Authentication

Oracle Business Intelligence allows various forms of authentication methods to be applied at once. While some can see this as a desirable feature it also comes with security risks. For users wishing to implement just a single source of authentication, they should consider auditing the repository for the following alternative methods of authentication.

To stop all initialization block authentication access:

You stop access through initialization blocks using the Administration Tool. Successful authentication requires a user name, and initialization blocks populate user names using the special system session variable called USER.

  1. Remove the USER System Variable from the repository.

  2. Ensure that initialization blocks in the repository have the Required for authentication check box cleared.

  3. Check that initialization blocks in the repository that set the system session variables PROXY and PROXYLEVEL do not allow users to bypass security.

    The system variables PROXY and PROXYLEVEL allow connected users to impersonate other users with their security profile. This is fine when the account being proxied-to, has less privileges, but if the account has more privileges it can be a security issue.

Caution: If you disable an initialization block, then any dependant initialization blocks will also be disabled.

You can now be sure that any attempted access using initialization block authentication will no longer be successful. However, you must check all of your initialization blocks.

3.4.6.2 Troubleshooting

You might receive the following error after you have configured Oracle Internet Directory LDAP authentication as the single source:

<Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed.

Reason: weblogic.security.SecurityInitializationException: User <oidweblogic> is not permitted to boot the server. The server policy may have changed in such a way that the user is no longer able to boot the server. Reboot the server with the administrative user account or contact the system administrator to update the server policy definitions.

Solution

If when you restart the system as the new WebLogic OID administrator (oidweblogic), you are locked out, and the above message is displayed, it is because the oidweblogic user has insufficient privileges. The oidweblogic user requires the Admin global role to enable it to belong to an OID Administrator group. You resolve this issue by adding the BIAdministrators group (or an OID equivalent) to the Admin global role.

Note:

To restore a previously working configuration, you must replace the latest updated version of the config.xml file with a backup version that you have made before changing the configuration (for more information, see Task 1, "Backup and Recovery").

To complete the restoration of the backup config.xml file, restart Oracle Business Intelligence as the original WebLogic administrator user, instead of as the OID user.

3.5 Configuring User and Group Name Attributes in the Identity Store

This topic contains the following sections:

3.5.1 Configuring the User Name Attribute in the Identity Store

If you configure an alternative authentication provider such as Oracle Internet Directory (OID) or Active Directory (AD), then you must ensure that the User Name Attribute that you use in the identity store matches the User Name Attribute that you use in the alternative authentication provider.

For example, to authenticate using a user's email address you might set the User Name Attribute to mail in both the identity store and the authentication provider.

Figure 3-3 shows the User Name Attribute in OID Authenticator set to mail.

Figure 3-3 Example - Provider Specific Tab

This screenshot or diagram is described in surrounding text.
Description of "Figure 3-3 Example - Provider Specific Tab"

The UserNameAttribute in the alternative authentication provider is usually set to the value 'cn', if it is not, you must make sure the settings for AllUsersFilter and UserFromNameFilter are configured correctly as shown in Table 3-8. Table 3-8 illustrates the default setting (using the value cn), and a required new setting (using a new value in the attribute AnOtherUserAttribute).

Table 3-8 Changing User Name Attributes

Attribute Name Default Setting Required New Setting

UserNameAttribute

cn

AnOtherUserAttribute

AllUsersFilter

(&(cn=*)(objectclass=person))

(&(AnOtherUserAttribute =*)(objectclass=person))

UserFromNameFilter

(&(cn=%u)(objectclass=person))

(&(AnOtherUserAttribute =%u)(objectclass=person))


Make the changes in the Provider Specific tab, using Table 3-8 (substitute the AnOtherGroupAttribute setting with your own value). For more information about how to display the Provider Specific tab, see Section 3.4, "Configuring Alternative Authentication Providers".

Note:

For the UserName Attribute only, you must use the following task to add two properties to the identity store configuration (user.login.attr and username.attr). This tells the identity store about the attribute you're expecting to get user name from (it defaults to using 'uid' if none is specified).

To configure the User Name attribute in the identity store:

  1. Log in to Fusion Middleware Control.

    For more information, see Section 1.6.2, "Using Oracle Fusion Middleware Control".

  2. From the navigation pane expand the WebLogic Domain folder and select bifoundation_domain.

  3. Right-click bifoundation_domain and select Security, then Security Provider Configuration to display the Security Provider Configuration page.

    This screenshot is described in surrounding text.
  4. In the Identity Store Provider area, click Configure to display the Identity Store Configuration page.

    This screenshot is described in surrounding text.
  5. In the Custom Properties area, use the Add option to add the following two Custom Properties:

    Table 3-9 Custom Properties

    Property Name Value

    user.login.attr

    Specify the User Name Attribute that is set in the authentication provider. For example, if the User Name Attribute is set to mail in the authentication provider, then set this value to mail.

    username.attr

    Specify the User Name Attribute that is set in the authentication provider. For example, if the User Name Attribute is set to mail in the authentication provider, then set this value to mail.


    Figure 3-4 shows an example set of Custom Properties with the User Name Attribute set to mail.

    Figure 3-4 Custom Properties - User Name Attribute

    This screenshot is described in surrounding text.
  6. Click OK to save the changes.

  7. Restart the Administration Server.

Note:

Ensure that the users and groups from your authentication provider (for example, OID, AD), are displayed in WebLogic Console, as described in Step 4 in Section 3.2, "High-Level Steps for Configuring an Alternative Authentication Provider".

3.5.2 (Optional for Active Directory) Changing Group Name Attributes

If your Active Directory server uses a Group Name attribute other than the default value 'cn', you must to change it. If you do change this attribute, you will also need to change the settings for AllGroupsFilter and GroupFromNameFilter as shown in Table 3-10 (the example shows a group name stored in an attribute called AnOtherGroupAttribute).

Table 3-10 Changing Group Name Attribute

Attribute Name Default Setting Required New Setting

StaticGroupNameAttribute/DynamicGroupNameAttribute

cn

AnOtherGroupAttribute

AllGroupsFilter

(&(cn=*)(objectclass=person))

(&(AnOtherGroupAttribute =*)(objectclass=person))

GroupFromNameFilter

(&(cn=%u)(objectclass=person))

(&(AnOtherGroupAttribute =%u)(objectclass=person))


Make the changes in the Provider Specific tab, using Table 3-10 (substitute the AnOtherGroupAttribute setting with your own value). For more information about how to display the Provider Specific tab, see Section 3.4.2, "Configuring Active Directory as the Authentication Provider".

3.6 Configuring the GUID Attribute in the Identity Store

If you configure an alternative authentication provider such as Oracle Internet Directory (OID) or Active Directory (AD), and you change the GUID attribute from its default value, then you must ensure that the value that you use in the identity store matches the changed value that you are using in the alternative authentication provider.

For example, if you are using OID and have changed the default value of the GUID attribute from orclguid to newvalue, you must set the value to newvalue in both the identity store and the authentication provider.

To configure the GUID attribute in the identity store:

  1. Log in to Fusion Middleware Control.

    For more information, see Section 1.6.2, "Using Oracle Fusion Middleware Control".

  2. From the navigation pane expand the WebLogic Domain folder and select bifoundation_domain.

  3. Right-click bifoundation_domain and select Security, then Security Provider Configuration to display the Security Provider Configuration page.

    This screenshot is described in surrounding text.
  4. In the Identity Store Provider area, click Configure to display the Identity Store Configuration page.

    This screenshot is described in surrounding text.
  5. In the Custom Properties area, use the Add option to add a Custom Property called PROPERTY_ATTRIBUTE_MAPPING:

    Table 3-11 Custom Properties

    Property Name Value

    PROPERTY_ATTRIBUTE_MAPPING

    Specify the GUID attribute value that is set in the authentication provider. For example, if the GUID attribute is set to newvalue in the authentication provider, then set this value to GUID=newvalue.


    Figure 3-5 shows an example set of Custom Properties including a new property called PROPERTY_ATTRIBUTE_MAPPING having a GUID attribute value set to GUID=newvalue.

    Figure 3-5 Custom Properties - GUID Attribute

    This screenshot is described in surrounding text.
  6. Click OK to save the changes.

  7. Restart the Administration Server, any Managed Server(s), and Oracle BI components.

3.7 Configuring a New Trusted User (BISystemUser)

Oracle Business Intelligence uses a specific user for the configured authenticator for internal communication. If for example, you configure Oracle BI to use an alternative authentication provider (for example, Oracle Internet Directory, Active Directory), then you must create a new user (or select an existing user), in the alternative authentication provider to use for this purpose and give that user the required permissions. You grant the chosen user the permission they need by making them a member of the preexisting BISystem application role. When configuring multiple authenticators (for more information, see Section 3.4.4), this user only needs to exist in one of the identity stores.

To create a new trusted user account with a user from the alternative authentication provider:

The credentials of the trusted user account are stored in the Credential Store under the system.user key. You must point the system.user key to a set of credentials available in your authentication provider (for example, Oracle Internet Directory, Active Directory).

Whether you decide to use an existing user or create a new one, the process for changing the system.user is the same.

  1. In the alternative authentication provider create, or identify a user for the trusted user.

    Best practice is to name this trusted user BISystemUser to clarify its purpose, but you might choose any name you want.

    When you are finished, the Users table in Oracle WebLogic Server Administration Console should resemble Figure 3-6 (the example given is for Oracle Internet Directory).

    Figure 3-6 Users Table in Oracle WebLogic Server Administration Console

    This screenshot or diagram is described in surrounding text.
    Description of "Figure 3-6 Users Table in Oracle WebLogic Server Administration Console"

    Next add the trusted user's credentials to the oracle.bi.system credential map.

  2. From Fusion Middleware Control target navigation pane, expand the farm, then expand WebLogic Domain, and select bifoundation_domain.

    • From the WebLogic Domain menu, select Security, then Credentials.

    • Open the oracle.bi.system credential map, select system.user and click Edit.

      This screenshot or diagram is described in surrounding text.
      Description of the illustration bisystem_cred.gif

    • In the Edit Key dialog, enter BISystemUser (or name you selected) in the User Name field. In the Password field, enter the trusted user's password that is contained in the authentication provider (for example, Oracle Internet Directory, Active Directory).

      Entering BISystemUser credentials in the Edit Key dialog.
    • Click OK.

      Next you must make the new trusted user a member of the BISystem application role.

  3. In Fusion Middleware Control target navigation pane, go to the Oracle WebLogic Server domain in which Oracle Business Intelligence is installed. For example, bifoundation_domain.

  4. Select Security and application roles from the WebLogic Domain menu, to display the Application Roles page.

  5. Click the Select Application Stripe to Search radio button, and select obi from the list. Click the search arrow to the right of the Role Name field.

    The Oracle Business Intelligence application roles are displayed and should resemble Figure 3-7.

    Figure 3-7 Application Roles Page in Fusion Middleware Control

    Application Roles page in Fusion Middleware Control.
  6. Select the BISystem application role and click Edit.

  7. In the Edit Application Role page, scroll down to the Users section and click Add User.

  8. In the Add User dialog, click the arrow next to the User Name field to search for the trusted user created in the alternative authentication provider (for example, Oracle Internet Directory). Use the shuttle controls to move the trusted user name (BISystemUser) from the Available Users list to the Selected Users list.

    This screenshot or diagram is described in surrounding text.
    Description of the illustration bisystem_edit02.gif

  9. Click OK.

    The trusted user (BISystemUser) contained in the alternative authentication provider (for example, Oracle Internet Directory, or Active Directory), is now a member of the BISystem application role.

    The next stage of configuring the new system user is to ensure they are part of the WebLogic Global Admin role.

  10. In WebLogic Console, click myrealm to display the Settings for <Realm> page, display the Roles and Policies tab.

  11. In the list of roles, click on the plus sign to expand Global Roles, then Roles, then click View Role Conditions link for the Admin Role.

    Includes Admin role associated with new system user.
  12. Add the new trusted user to the Global Admin Role.

    Ensure the conditions specified will match your user, either directly, or by virtue of a group they belong to (for example, condition may be User = BiSystemUser or Group=Administrators).

  13. Click Save.

  14. If you change the trusted user name to a value other than BISystemUser, you must also change the equivalent user name for JMS Modules.

    Oracle Business Intelligence Publisher JMS modules use BISystemUser by default, therefore if you have changed your trusted user account name to a value other than BISystemUser, you must also change the user name for JMS Modules to the value of the new trusted user.

    1. In WebLogic Console, select - Services - Messaging - JMS Modules.

    2. Select BipJmsResource.

    3. Go to the Security tab, and display the Policies sub-tab.

    4. Replace BISystemUser with the name of the new trusted user.

  15. Start the Managed Servers.

    When you have changed the system user credentials in this way, restart the BI Server and Presentation Services. In Fusion Middleware Control - select Business Intelligence and Restart All Components.

The new trusted user from the authentication provider (for example, Oracle Internet Directory, Active Directory), is configured for Oracle Business Intelligence.

3.8 Refreshing User GUIDs

In Oracle Business Intelligence 11g Release 1 (11.1.1), users are recognized by their global unique identifiers (GUIDs), not by their names. GUIDs are identifiers that are unique for a given user. Using GUIDs to identify users provides a higher level of security because it ensures that data and metadata is uniquely secured for a specific user, independent of the user name.

GUID refresh (also called GUID synchronization or GUID regeneration) updates any metadata references to user GUIDs in the Oracle BI repository and Oracle BI Presentation Catalog. During the GUID refresh process, each user name is looked up in the identity store. Then, all metadata references to the GUID associated with that user name are replaced with the GUID in the identity store.

GUID refresh might be required when Oracle Business Intelligence is reassociated with an identity store that has different GUIDs for the same users. This situation might occur when reassociating Oracle Business Intelligence with a different type of identity store, or when moving from test to production if a different identity store is used in production, and should be a rare event.

Note that if Oracle best practices are not observed and Oracle Business Intelligence repository data is migrated between systems that have different GUIDs for the same users, GUID refresh is required for the system to function. This is not a recommended practice, because it raises the risk that data and metadata secured to one user (for example, John Smith, who left the company two weeks ago) becomes accessible to another user (for example, John Smith, who joined last week). Using application roles wherever possible and using GUIDs consistently across the full development production lifecycle prevents this problem from occurring.

To refresh user GUIDs:

This task requires that you manually edit the configuration files to instruct the Oracle BI Server and Presentation Services to refresh the GUIDs on restart. Once completed, you edit these files to remove the modification. For information about where to locate Oracle Business Intelligence configuration files, see "Where Configuration Files are Located" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

To refresh user GUIDs, perform the following steps on APPHOST1 and APPHOST2. Note that GUID refresh must occur with only one node operating at a time.

  1. Stop Oracle BI Server and Presentation Services on all nodes except where you are refreshing the user GUIDs. For example:

    cd ORACLE_HOME/admin/instancen/bin
    ./opmnctl stopproc ias-component=coreapplication_obips1./opmnctl stopproc ias-component=coreapplicaiton_obis1
    
  2. Update the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS parameter in NQSConfig.INI:

    1. Open NQSConfig.INI for editing at:

      ORACLE_INSTANCE/config/OracleBIServerComponent/coreapplication_obisn
      
    2. Locate the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS parameter and set it to YES, as follows:

      FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = YES;
      
    3. Save and close the file.

  3. Update the Catalog element in instanceconfig.xml:

    1. Open instanceconfig.xml for editing at:

      ORACLE_INSTANCE/config/OracleBIPresentationServicesComponent/
      coreapplication_obipsn
      
    2. Locate the Catalog element and update it as follows:

      <ps:Catalog xmlns:ps="oracle.bi.presentation.services/config/v1.1">
      <ps:UpgradeAndExit>false</ps:UpgradeAndExit>
      <ps:UpdateAccountGUIDs>UpdateAndExit</ps:UpdateAccountGUIDs>
      <ps:/Catalog>
      
    3. Save and close the file.

  4. Restart the Oracle BI Server and Presentation Services using opmnctl:

    cd ORACLE_HOME/admin/instancen/bin
    ./opmnctl stopproc ias-component=coreapplication_obips1
    ./opmnctl stopproc ias-component=coreapplicaiton_obis1
    ./opmnctl startproc ias-component=coreapplicaiton_obis1
    

    After you confirm that the Oracle BI Server is running, then start Presentation Services:

    ./opmnctl startproc ias-component=coreapplicaiton_obips1
    
  5. Set the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS parameter in NQSConfig.INI back to NO.

    Important: You must perform this step to ensure that your system is secure.

  6. Update the Catalog element in instanceconfig.xml to remove the UpdateAccount GUIDs entry.

  7. Restart the Oracle Business Intelligence system components again using opmnctl:

    cd ORACLE_HOME/admin/instancen/bin
    ./opmnctl stopall
    ./opmnctl startall
    

3.9 Configuring Oracle Internet Directory as the Policy Store and Credential Store

To re-configure Oracle Business Intelligence to use Oracle Internet Directory (OID) as a Credential Store and Policy Store Provider, follow the steps in "Reassociating the OPSS Security Store" in Oracle Fusion Middleware Application Security Guide.

Notes