Configure Oracle Analytics Server to Use Alternative Authentication Providers

Follow these options to configure Oracle Analytics Server to use one or more authentication providers instead of the default Oracle WebLogic Server LDAP directory.

Topics:

Reconfigure Oracle Internet Directory as an Authentication Provider

Use these steps to reconfigure the Oracle Internet Directory (OID) LDAP as the authentication provider.

Note:

If the User Name Attribute, or the Group Name Attribute is configured to a value other than cn in Oracle Internet Directory, you must change corresponding values in Oracle WebLogic Server Administration Console. The LDAP authenticators, including the OracleInternetDirectoryAuthenticator and the ActiveDirectoryAuthenticator, default to cn as the user name and group name attributes. You can use alternative attributes for the user name such as uid or mail.

Log in to Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
In Domain Structure, select Security Realms, and click myrealm.
Click the Providers tab, then click the Authentication tab.
Click New.
In Create a New Authentication Provider, in the Name field, type a name for the authentication provider such as MyOIDDirectory.
From the Type list, select OracleInternetDirectoryAuthenticator.
Click OK to save the changes and display the authentication providers list updated with the new authentication provider.
In the Authentication Providers table, under the Name column, click MyOIDDirectory.
In Settings for MyOIDDirectory, click the Configuration tab and then click the Common tab.
From the Control Flag list, select SUFFICIENT, and then click Save.
Click the Provider Specific tab, in the Connection properties, type your values for Host, Port, Principal, and Credential.
In the Provider Specific tab, Group area, specify value for the Group Base DN (distinguished name).
In the Provider Specific tab, Users area, specify the following:
- User Base DN
- All Users Filter
- User From Name Filter
- Use Retrieved User Name as Principal
- User Name Attribute
Click Save.

You must also complete these tasks:

After completing the above tasks, in the Change Center, click Activate Changes, and then restart Oracle WebLogic Server.

Oracle Internet Directory Authenticator Provider Specific Reference

Review the table to complete the values required in the Oracle Internet Directory (OID) Authenticator.

Use this table to get the details about the fields in the Provider Settings page of the Settings for MyOIDDirectory.

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. Leave this blank, because it is the default value for the Active Directory authenticator. Any filter that you add to the All Users Filter is appended to all user searches.
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 such as cn, uid, or mail. For example, to authenticate using a user's email address you set this value to `mail`. The value that you specify must match the User Name Attribute that you are using in the authentication provider.
Users	Use Retrieved User Name as Principal	Specifies whether or not the user name retrieved from the LDAP server should be used as the Principal in the Subject. Oracle recommends that you select this check box as it helps to enforce consistent case usage. For example, if your LDAP user name is JSmith, but you logged in as jsmith (lower case) the Principal is still JSmith (mixed case). This means that any application role memberships granted directly to users, instead of indirectly through groups, are consistently applied at authentication time.

Reconfigure Microsoft Active Directory as the Authentication Provider

Follow this procedure to reconfigure your Oracle Analytics Server installation to use Microsoft Active Directory.

The example data in this section uses a fictional company called XYZ Corporation that wants to set up SSO for Oracle Analytics Server 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 in to the corporate network, the log in to the Active Directory domain. The domain controller is addc.xyzcorp.com, which controls the Active Directory domain.
Oracle Analytics Server WebLogic domain

The XYZ Corporation has a WebLogic domain called bi, 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)

Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.
Select Security Realms from the left pane and click myrealm.

myrealm is the default Security Realm.
Display the Providers tab, then display the Authentication sub-tab.
Click New to launch the Create a New Authentication Provider page.
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.
Click DefaultAuthenticator in the Name column to display the Settings page.
In the Common Authentication Provider Settings page, change the Control Flag from REQUIRED to SUFFICIENT and click Save.
In the authentication providers table, click ADDirectory in the Name column to display the Settings page.
Display the Configuration\Common tab, and use the Control Flag list to select 'SUFFICIENT', then click Save.
Display the Provider Specific tab to access the options which apply specifically to connecting to an Active Directory LDAP authentication store.
Use the Provider Specific tab to specify the provider specific details.
Optional: If the User Name attribute, or the Group Name attribute is configured to a value other than cn in Microsoft Active Directory, you must change corresponding values in Oracle WebLogic Server Administration Console.

Note:

The LDAP authenticators provided by WebLogic including OracleInternetDirectoryAuthenticator and ActiveDirectoryAuthenticator, use cn as the default user name and group name attributes. You can use alternative attributes for the user name, for example uid or mail.
Click Save.
In Settings for myrealm page, click the Providers tab, then click the Authentication tab.
Click Reorder.
In the Reorder Authentication Providers page, select ADDirectory and use the arrow buttons to move it into the first position in the list, then click OK.
In the Change Center, click Activate Changes.
Restart Oracle WebLogic Server.

Microsoft Active Directory Authentication Provider Specific Reference

Review the table to complete the values required in the Microsoft Authenticator.

Use this table to get the details about the fields in the Provider Settings page of Microsoft Active Directory.

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 that connects to Active Directory 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 specified Principal.
Groups	Group Base DN	The LDAP query used to find groups in AD. 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.
Users	All Users Filter	LDAP search filter. Click More Info...for details.
Users	User From Name Filter	LDAP search filter. Blank by default in AD. Click More Info... for details.
Users	User Object class	The name of the user.
Users	Use Retrieved User Name as Principal	Specifies whether or not the user name retrieved from the LDAP server should be used as the Principal in the Subject. Click More Info... for details. Oracle recommends that you select this check box as it helps to enforce consistent case usage. For example, if your LDAP user name is JSmith, but you logged in as jsmith (lower case) the Principal is still JSmith (mixed case). This means that any application role memberships granted directly to users, instead of indirectly through groups, are consistently applied at authentication time.

Configure User and Group Name Attributes in the Identity Store

The LDAP authenticators provided by WebLogic, including OracleInternetDirectoryAuthenticator and ActiveDirectoryAuthenticator, default to using cn as the user name and group name attributes.

You might need to use alternative attributes for the user name, for example uid or mail. The need to use different group name attributes is less common. This section explains how to reconfigure user names and group names.

Topics:

Configure User Name Attributes

This section describes how to reconfigure the OracleInternetDirectoryAuthenticator (OID), for example, to use mail as the User Name Attribute.

The Users section shows the User Name Attribute configured with the value mail.

Description of the illustration a_oid.gif

The UserNameAttribute in the alternative authentication provider is usually set to the value cn. If the UserNameAttribute is not set to cn, you must make sure the settings for AllUsersFilter and UserFromNameFilter are configured correctly as shown in the table. The table illustrates the default setting using the value cn, and a required new setting using a new value in the attribute AnOtherUserAttribute.

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, substitute the AnOtherGroupAttribute setting with your own value.

Configure Group Name Attributes

You can configure the ActiveDirectoryAuthenticator to use a group name other than cn.

If the group name for Active Directory server is set to anything other than the default value cn, you must change the group name. If you change the value, you must also change the values of AllGroupsFilter and GroupFromNameFilter as in the AnOtherGroupAttribute 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 the values in the table, substitute the AnOtherGroupAttribute setting with your own value. To display the Provider Specific tab, see Reconfigure Microsoft Active Directory as the Authentication Provider.

Configure LDAP as the Authentication Provider and Storing Groups in a Database

The examples provided in this section use Oracle Internet Directory (OID LDAP), and a sample database schema. However, you do not have to use OID LDAP as your LDAP identity store and your database schema does not have to be identical to the sample provided.

Oracle Analytics Server provides an authentication provider for WebLogic Server called BISQLGroupProvider that enables you to use this method. This authentication provider does not authenticate end user credentials but enables external group memberships held in a database table to contribute to an authenticated user's identity.

Topics:

Prerequisites

The following prerequisites must be satisfied before you attempt to configure LDAP authentication as described in this section:

Oracle Analytics Server must be installed and configured.
A suitable database schema containing at least one table with the required groups in it, and a mapping table which maps those groups to the names of users authenticated by LDAP must be running and accessible from the Oracle WebLogic Server on which Oracle Analytics Server is running.
The configuration must include a supported LDAP server to use as the identity store that contains users.
If you need Oracle Analytics Server to deliver content to members of an application role the following restrictions apply:
- You can only pair a single LDAP authenticator with a single BISQLGroupProvider.
  
  When you configure multiple LDAP authenticators and want to retrieve group membership from the BISQLGroupProvider, content cannot be delivered to all members of an application role. In this configuration Oracle Analytics Delivers cannot resolve application role membership based on users and group membership.
- You cannot define the same group in more than one identity store.
  
  You cannot have a group with the same name in both LDAP and database groups table. If you do, the security code invoked by Oracle Analytics Delivers cannot resolve application role membership.

Create a Sample Schema for Groups and Group Members

The sample schema described here is deliberately simplistic, and is intended only to illustrate how to configure Oracle Analytics Server to use the schema.

The ACME_BI_GROUPS sample schema contains two tables and a view. The GROUPS table defines the list of external groups. The GROUPMEMBERS table and GROUPMEMBERS_VW view describe group membership for users that exist in your primary identity store.

An advantage of defining tables or views identical to those shown in the diagram is that the configuration of the BISQLGroupProvider can use the default SQL outlined in the table in Configure the BISQLGroupProvider SQL Authenticator.

Description of ldapdblibovd_sample.gif follows

Description of the illustration ldapdblibovd_sample.gif

You must map the users in your LDAP store to groups in your database table by login name. In the diagram, the value of G_MEMBER in the GROUPMEMBERS table must match the value of the LDAP attribute used for login, for example, uid, cn, or mail, as specified in the LDAP authenticator. You should not, for example, map the database groups by uid if the login attribute is mail. Create a GROUPMEMBERS_VW view with an outer join between the GROUPMEMBERS and GROUPS tables.

Configure a Data Source and the BISQLGroupProvider Using Oracle WebLogic Server Administration Console

You configure a data source and the BISQLGroupProvider using Oracle WebLogic Server Administration Console as follows:

Topics:

Configure Oracle Internet Directory as the Primary Identity Store for Authentication Using Oracle WebLogic Server

Use the instructions in the link to configure WebLogic to authenticate your user population against OID LDAP.

See Reconfigure Oracle Internet Directory as an Authentication Provider.

Note:

When following the steps of this task, make a note of the value of the User Base DN and User Name Attribute in the Provider Specific configuration page for your OID LDAP authenticator for use later.

Install the BISQLGroupProvider

Before you can configure a BISQLGroupProvider authenticator, you must first install the JAR file bi-sql-group-provider.jar, which contains the authenticator. The file is available in the following location:

ORACLE_HOME/bi/plugins/security/bi-sql-group-provider.jar

You must copy the file to the following location:

ORACLE_HOME/wlserver/server/lib/mbeantypes

After copying the file into the specified location you must restart the Administration Server to enable the new provider to appear in the list of available authenticators.

Note:

If you install to create a clustered environment, then the installation cannot start the scaled-out Managed server because the bi-sql-group-provider.jar file is not available. When this situation occurs during installation, copy the Jar file to the correct location and click Retry in the installer.

Configure the Data Source Using Oracle WebLogic Server Administration Console

These steps enable you to configure the data source using Oracle WebLogic Server Administration Console.

Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.
Click Services, and click Data Sources.
In Summary of Data Sources, click New, and select Generic Data Source.
In JDBC Data Sources Properties , enter or select values for the following properties:
- Name, for example, enter BIDatabaseGroupDS.
  
  The name used in the config.xml configuration file and throughout the Oracle WebLogic Server Administration Console whenever referring to this data source.
  
  JNDI Name , for example, enter jdbc/BIDatabaseGroupDS.
  
  The JNDI path to where the JDBC data source is bound.
  
  Database Type, for example, select Oracle.
  
  The DBMS of the database that you want to connect to.
Click Next.
Select a database driver from the Database Driver list.

Note:

If using an Oracle database, select Oracle's Driver (Thin) for Service Connections; Releases:9.0.1 and later.
Click Next.
Click Next.
On the Connection Properties page, enter values for the following properties:
- Database Name - The name of the database that you want to connect to.
  
  Host Name - for example, enter: mymachine.example.com.
  
  The DNS name or IP address of the server that hosts the database.
  
  Note:
  
  Do not use local host if you intend to use a cluster.
  
  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 Create a Sample Schema for Groups and Group Members.
  
  For example, enter MYUSER.
- Password/Confirm Password
  
  The password for the Database User Name.
  
  For example, enter password.
Click Next.
Check the details on the page are correct, and click Test Configuration.
Click Next.
In Select Targets, choose the servers or clusters as deployment targets for your data source.
You should select the Administration Server and managed servers as your targets, for example:
- In the Servers pane
  
  Select the AdminServer option.
- In the Clusters pane
  
  Select the bi_server1 check box to deploy to the cluster.
Click Finish.
In the Change Center, click Activate Changes.

Note:

In this example, the data source is called BIDatabaseGroupDS.

Configure the BISQLGroupProvider SQL Authenticator

Follow these steps to create a BISQLGroupProvider against the BIDatabaseGroupDS data source using an example table structure.

This task explains how to create a BISQLGroupProvider against the BIDatabaseGroupDS data source using the example table structure outlined in Create a Sample Schema for Groups and Group Members. You may need to modify the SQL statements used (table or column names) if your structure differs from the example.

Note:

There is no authentication against the database, as it just stores the groups to be associated with users. Authentication occurs against LDAP and the database is exposed when the BISQLGroupProvider assigns groups to application roles in Oracle WebLogic Server Administration Console.

Log in to Oracle WebLogic Server Administration Console as a WebLogic administrator, and click Lock & Edit in the Change Center.
Select Security Realms from the left pane and click myrealm.

The default Security Realm is named myrealm.
Display the Providers tab, then display the Authentication sub-tab.
Click New to launch the Create a New Authentication Provider page.
Enter values in the Create a New Authentication Provider page as follows:
- Name: Enter a name for the authentication provider. For example, MySQLGroupProvider.
- From the Type list, select BISQLGroupProvider.
- Click OK to save the changes and display the authentication providers list updated with the new authentication provider.
In the authentication providers table, click MySQLGroupProvider in the Name column to display the Settings page.
Display the Provider Specific tab to specify the SQL statements used to query and authenticate against your database tables.
Specify the DataSource Name. Don't use the JNDI name. For example: jdbc/BIDatabaseGroupDS.
Enter all of the SQL statements appropriate to your authenticator.

The SQL is case sensitive.
Click Save.
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 BISQLGroupProvider and use the arrow buttons to move it into the first position in the list.
4. Click OK to save your changes.
Perform the following steps to configure the Control Flag setting of BISQLGroupProvider:
1. At the main Settings for myrealm page, display the Providers tab, then display the Authentication sub-tab, then select BISQLGroupProvider to display its configuration page.
2. Display the Configuration\Common tab and select OPTIONAL from the Control Flag list.
3. Click Save.
In the Change Center, click Activate Changes.
Restart the Oracle Analytics Server components, use Fusion Middleware Control once the Administration Server has been restarted, Oracle WebLogic Server, and Managed servers.

Note:

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

Configure the Virtualized Identity Store

You configure the virtualized identity store as follows:

Topics:

Enable Virtualization by Configuring the Identity Store

You configure the identity store to enable virtualization enabling the use of multiple identity stores with the identity store service.

You can split the user profile information across different authentication providers (identity stores), see Configure Identity Store Virtualization Using Fusion Middleware Control.

Configure SSL Against LDAP

If you have configured an LDAP Authenticator to communicate over SSL (one-way SSL only), you must put the corresponding LDAP server's route certificate and if necessary, any intermediate certificates in an additional keystore used by the virtualization (libOVD) functionality.

See Configure SSL when Using Multiple Authenticators.

Configure a Database Adaptor to Retrieve Group Information

You configure a database adaptor to make it appear like an LDAP server to enable the virtualized identity store provider to retrieve group information from a database using the database adapter.

In this task you create a file containing the elements for an adapter templates that specifies how to use your database tables as an identity store to map groups. The file describes the mapping of the GROUPMEMBERS_VW view to a virtual LDAP store. The view uses an outer join to ensure that you can reference fields from more than one table by the database adaptor.

Create a file named bi_sql_groups_adapter_template.xml.

Adapt the following elements to match your table and column attributes against LDAP server attributes.

Note:

For the element:

<param name="ReplaceAttribute" value="uniquemember={cn=%uniquemember%,cn=users,dc=oracle,dc=com}"/>

This must match the user attribute and root User DN of the main authenticator. For example, for the default authenticator:

uid=%uniquemember%,ou=people,ou=myrealm,dc=bifoundation_domain

<?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="GROUPMEMBERS_VW" field="G_NAME" type=""/>
            <attribute ldap="groupnameattr" table="GROUPMEMBERS" field="G_NAME" type=""/>
            <attribute ldap="description" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
            <attribute ldap="uniquemember" table="GROUPMEMBERS_VW" field="G_MEMBER" type=""/>
            <attribute ldap="orclguid" table="GROUPMEMBERS" field="G_NAME" type=""/>
         </objectClass>
      </mapping>
      <useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
      <connectionWaitTimeout>10</connectionWaitTimeout>
      <oracleNetConnectTimeout>0</oracleNetConnectTimeout>
      <validateConnection>false</validateConnection>
   </dataBase>
</adapters>

Customize appropriate sections for the following elements:
- ReplaceAttribute
  
  Specifies how to define the unique member for a group. The %uniquemember% is a placeholder for a value that is passed at runtime when looking up whether a user is a member of a group.
  
  The only aspect of this element you may want 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 7.
- groupofuniquenenames
  
  Specifies how group attributes are mapped to database fields.
  
  You must map the following attributes:
  - cn maps to a unique name for your group.
  - uniquemember maps to the unique name for your user in the user/group mapping table in your database schema.
  Mapping the following attribute is optional:
  - description is optional.
  No other attributes are configurable.
Copy the adapter file into the following folder:

ORACLE_HOME/oracle_common/modules/oracle.ovd/templates/
Open a command prompt/terminal at:

ORACLE_HOME/oracle_common/bin
Ensure the following environment variables are set, for example:
- ORACLE_HOME=oraclehome
- WL_HOME=ORACLE_HOME/wlserver/
- JAVA_HOME=ORACLE_HOME/jdk/jre

Run the libovdadapterconfig script to create a database adapter from the template file. 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 biSQLGroupAdapter -adapterTemplate bi_sql_groups_adapter_template.xml -host localhost -port 9500 -userName weblogic -domainPath /opt/oracle_bi/user_projects/domains/bifoundation_domain/ -dataStore DB -root cn=users,dc=oracle,dc=com -contextName default -dataSourceJNDIName jdbc/BIDatabaseGroupDS

Note:

Use the JNDI name and not just the DS name for the dataSourceJNDIName.

Note:

The root parameter value should match the root dn specified in the <param name>="replaceattribute" element in the adaptor template. For example, if user is specified in the default authenticator, set the root to ou=people, ou=myrealm, dc=bifoundation_domain.

The script should exit without error.

Restart WebLogic Administration Server and Managed servers.

Note:

When you start WebLogic, you can ignore the following Warning: BISQLGroupsProvider: Connection pool not usable .

Log in to WebLogic and Oracle Analytics Server using credentials stored in the database.

Test the Configuration by Adding a Database Group to an Application Role

You can test the configuration by adding a database group to an application role.

Log in to Fusion Middleware Control, and open WebLogic domain and bifoundation_domain in the navigation menu on the left of the page.
Right-click bifoundation_domain and select Security, then Application Roles to display the Application Role Configuration page.
Add a database group which contains an LDAP user to one of the application roles, for example, BIServiceAdministrator, which that user does not currently have access to.
Log in to Oracle Analytics Server as a user that is a member of the group that was newly added to the application role.

In the top right of the page, you will see the text Logged in as <user id>.
Click the user id to display a drop down menu.
Select My Account from the menu.
Display the Roles and Catalog Groups tab and verify the user now has the new application role.

Correct Errors in the Adaptors

You cannot modify an existing database adapter, so if you make an error in either the libovdadapter command, or the templates you use to create the adapters, you must delete then recreate the adapter.

See Correct Database Adapter Errors by Deleting and Recreating the Adapter.

Configure a Database as the Authentication Provider

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

Topics:

Introduction and Prerequisites

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.

This topic explains how to configure Oracle Analytics Server 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 LDAP).

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.

Create a Sample Schema for Users and Groups

You have schemas that you were using in an earlier installation of Oracle Analytics Server. This sample schema is intended to illustrate how to configure the system to use this schema.

Note:

You must use a database schema containing the users, credentials and groups required for authentication that is accessible from the WebLogic Server where Oracle Analytics Server is running.

The diagram shows tables, USERS, USER_VW, GROUPMEMBERS, GROUPS, and GROUPMEMBERS_VW, where USER_VW is a view on the USERS table, and GROUPMEMBERS_VW is a view joining the GROUPMEMBERS and GROUPS tables.

Description of dblibovd_sample.gif follows

Description of the illustration dblibovd_sample.gif

If user or group information exists in more than one table, remove USER_VW must create a view over the tables of each type of information.

Create a view on the GROUPMEMBERS and GROUPS tables, for example, GROUPMEMBERS_VW, with an outer join on the GROUPS table and an inner join on the GROUPMEMBERS table, which enables you to see groups in Fusion Middleware Control even when they have no user assigned to them. To present the view shown in the diagram to the database adapter, you would need to follow the configuration shown in Configure a Database Adaptor.

Configure a Data Source and SQL Authenticator Using the Oracle WebLogic Server Administration Console

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

Topics:

Configure a Data Source Using the Oracle WebLogic Server Administration Console

Use these steps to configure a data source using the Oracle WebLogic Server Administration Console.

The schema owner of the tables is defined in Create a Sample Schema for Users and Groups.

Log in to Oracle WebLogic Server Administration Console, navigate to the Change Center, click Lock & Edit.
Click Services and click Data Sources.
In the Summary of Data Sources page, click New, and select Generic Data Source.
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/UserGroupDS
  
  The JNDI path to which this JDBC data source is bound.
- Database Type - For example, select: Oracle
  
  The DBMS of the database that you want to connect to.
Click Next.
Select a database driver from the Database Driver list.

For example, select: Oracle's Driver (Thin) for Service Connections; Releases:9.0.1 and later
Click Next.
Click Next.
On the Connection Properties page, enter values for the following properties:
- Database Name - For example, enter: ora12c
  
  The name of the database that you want to connect to.
- Host Name - For example, enter: mymachine.example.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
- Password/Confirm Password
  
  The password for the Database User Name.
Click Next.
Check the details on the page are correct, and click Test Configuration.
Click Next.
In the Select Targets page select the servers or clusters for deploying the data source.
You should select the Administration Server and Managed server as your targets, for example:
- In the Servers pane
  
  Select the AdminServer check box.
- In the Clusters pane
  
  Select the bi_server1 option.
Click Finish.
In the Change Center, click Activate Changes.
Restart the system.

Configure a SQL Authenticator Using the Oracle WebLogic Server Administration Console

A user with the appropriate privileges can log in to the Oracle WebLogic Server Administration Console using the WebLogic database authenticator.

When creating the SQL authenticator, select the read-only SQL authenticator. The read-only authentication provider type does not write back to the database.

When entering the SQL statements in the Provider Specific tab, if your password column is in plain text as the result of the query supplied for the SQL Get Users Password column was not hashed or encrypted, select the Plaintext Password Enabled option.

If the Plaintext Password Enabled option is cleared, the SQLAuthenticator expects passwords 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.

See SQL Authenticator Select Statement Reference for help in defining the Provider Specific SQL statements.

Log in to Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
From Domain Structure, select Security Realms and click myrealm.
In Settings for myrealm, click the Providers tab, and then click the Authentication tab.
In Authentication Providers, click New.
In Create a New Authentication Provider, in Name type a name for the authentication providers such as UserGroupDBAuthenticator.
From the Type list, select ReadOnlySQLAuthenticator, and click OK.
From the Authentication Providers table, select the provider you just created.
In the Settings for <your new authentication provider name>, click the Provider Specific tab.
Optional: In the Provider Specific tab, if your password column is in plain text, select Plaintext Password Enabled.
In the Data Source Name field, type the name of an existing data source, for example, UserGroupsDS, to use this authentication provider.
The data source name must match the existing data sources defined in Oracle WebLogic Server Administration Console.
In the Provider Specific tab, specify the SQL statements used to authenticate user access and to query your database tables.
After entering all of the required SQL statements for your authenticator, click Save.

You must configure the authentication provider control flag when using multiple authentication providers.

SQL Authenticator Select Statement Reference

Learn options available for creating SQL statements when implementing a SQL authentication provider.

When you create a SQL Authenticator in the Provider Specific tab, you specify the SQL statements used to query, and authenticate against, your database tables. See Configuring a SQL Authenticator Using the Oracle WebLogic Server Administration Console.

The table shows SQL statements for the sample schema outlined in Create a Sample Schema for Users and Groups.

If you are using a different table structure, you might need to adapt these SQL statements with the table or column names of your schema. You should use the question mark (?) as a runtime query placeholder rather than hard coding a user or group name.

Query	SQL	Notes
SQL Get Users Password	`SELECT U_PASSWORD FROM USERS WHERE U_NAME = ?`	This SQL statement looks 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 U_NAME FROM USERS WHERE U_NAME = ?`	This SQL statement looks 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 U_NAME FROM USERS WHERE U_NAME LIKE ?`	This SQL statement retrieves users that match a specific wildcard search. The SQL statement requires a single parameter for the usernames and returns a `resultSet` containing matching usernames.
SQL List Groups	`SELECT G_NAME FROM GROUPS WHERE G_NAME LIKE ?`	This SQL statement retrieves group names that match a wildcard. The SQL statement requires a single parameter for the group name and returns a `resultSet` containing matching groups.
SQL Group Exists	`SELECT G_NAME FROM GROUPS WHERE G_NAME = ?`	This SQL statement looks 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 G_MEMBER FROM GROUPMEMBERS WHERE G_NAME=? AND G_MEMBER LIKE ?`	This SQL statement looks up members of a group. The SQL statement requires two parameters, a group name and a member or group name. This SQL statement must return a `resultSet`.
SQL List Member Groups	`SELECT G_NAME FROM GROUPMEMBERS WHERE G_MEMBER = ?`	This SQL statement looks up the group membership of a user or group. 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 the criteria.
SQL Get User Description	`SELECT U_DESCRIPTION FROM USERS WHERE U_NAME = ?`	This SQL statement retrieves the description of a specific user. The SQL statement is valid only if `Descriptions Supported` is enabled. 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	`SELECT G_DESCRIPTION FROM GROUPS WHERE G_NAME = ?`	This SQL statement retrieves the description of a group. The SQL statement is valid only 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.

Configure the Default Authenticator Control Flag

Use a JAAS Control Flag for each provider to control how the authentication providers are used in the login sequence.

You must complete this task if you are using multiple authentication providers.

From the myrealm Settings page, click the Providers tab, and then click the Authentication tab.
From the Authentication Providers table, select DefaultAuthenticator.
In Settings for DefaultAuthenticator on the Configuration page in the Common tab, from the Control Flag list, select SUFFICIENT.
Click Save.

Reorder Authentication Providers

After adding a new authenticator, you can reorder the Authentication Providers table.

From the myrealm Settings page, click the Providers tab, and then click the Authentication tab.
In the Authentication Providers table, click Reorder.
In Reorder Authentication Providers, from Available, select the provider to use as the default, click the up arrow, and then click OK.
In the Change Center, click Activate Changes.

After restarting the Administration Server, use the Fusion Middleware Control to restart the Oracle Analytics Server components, Oracle WebLogic Server, and managed servers.

Configure the Virtualized Identity Store

Configure the virtualized identity store as follows:

Topics:

Configure a Database Adaptor

Follow these steps to configure a database adaptor to make the database appear like an LDAP server. This enables the virtualized identity store provider to retrieve user profile information from a database using the database adapter.

This task shows how to edit and apply adapter templates that specify how to use your database tables as an identity store. The example given here is for the sample schema that is used throughout Configure a Database as the Authentication Provider.

When customizing the adapter_template_usergroup1.xml file, map the elements by matching the classes and attributes used in a virtual LDAP schema with the columns in your database. The virtual schema is the same as that of WebLogic Embedded LDAP, you can map database columns to any of the attributes shown in the table.

The following is the schema file 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>DBGUID</name>
               <class>oracle.ods.virtualization.engine.chain.plugins.dbguid.DBGuidPlugin</class>
               <initParams>

					                  <param name="guidAtribute" 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="person" rdn="cn">
						<attribute ldap="cn" table="USER_VW" field="U_NAME" type=""/>
						<attribute ldap="uid" table="USER_VW" field="U_NAME" type=""/>
						<attribute ldap="usernameattr" table="USER_VW" field="U_NAME" type=""/>
						<attribute ldap="loginid" table="USER_VW" field="U_NAME" type=""/>
						<attribute ldap="description" table="USER_VW" field="U_NAME" type=""/>
						<attribute ldap="orclguid" table="USER_VW" field="GUID" type=""/>
						</objectClass>
      </mapping>
      <useCaseInsensitiveSearch>true</useCaseInsensitiveSearch>
      <connectionWaitTimeout>10</connectionWaitTimeout>
      <oracleNetConnectTimeout>0</oracleNetConnectTimeout>
      <validateConnection>false</validateConnection>
   </dataBase>
</adapters>

In the <objectClass> element:

The name="person" and rdn="cn" values declare the mapping of the LDAP person object class.
The cn attribute is used as its Relative Distinguished Name (RDN).
The child elements declare the LDAP attributes mapping to tables and columns in the database, for example:

The line <attribute ldap="uid" table="USER_VW" field="USER_ID" type=""/> maps the USER_ID field of the USER_VW table to the standard LDAP attribute uid, a unique user id for each user.
The USER_VW view should have a GUID column to match the orclguid attribute mapped to GUID column in adapter_template_usergroup1.xml, for example:

You could CREATE or REPLACE VIEW USER_VW as the following:
```
SELECT U_NAME, MAIL_ADDRESS, U_PASSWORD, U_DESCRIPTION, RPAD(U_NAME, 16, '0') AS GUID FROM USERS;
```

Attribute	Example
description	John Doe
cn	john.doe
uid	john.doe
sn	Doe
userpassword	password
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

You map groups using the same method as you used for mapping a person. When mapping groups, in the <objectClass name="groupofuniquenames" ...> element, define the unique member for a group. The %uniquemember% value is a placeholder for a value that is passed in at runtime during the look up to determine if the user is a member of a group. The only aspect of this element you might want to change is the specification of the root for your users. The %uniquemember% value matches the root of your user population when you run the libovdadapterconfig script.

The groupofuniquenames object class 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 maps to a unique name for your group.
uniquemember maps to the unique name for your user in the user/group mapping table in your database schema.
orclguid maps to a unique id, if available in your database schema.

Mapping the description attribute is optional.

Create a file named adapter_template_usergroup1.xml that maps the user table to a virtual LDAP store.

In the <mapping> element, add the <objectclass> element with attributes similar to the following example:

<mapping>
          <joins/>
	  <objectClass name="person" rdn="cn">
		<attribute ldap="cn" table="USER_VW" field="U_NAME" type=""/>
		<attribute ldap="uid" table="USER_VW" field="U_NAME" type=""/>
		<attribute ldap="usernameattr" table="USER_VW" field="U_NAME" type=""/>
		<attribute ldap="loginid" table="USER_VW" field="U_NAME" type=""/>
		<attribute ldap="description" table="USER_VW" field="U_NAME" type=""/>
		<attribute ldap="orclguid" table="USER_VW" field="GUID" type=""/>
	  </objectClass>
      </mapping>

Create a file, named adapter_template_usergroup2.xml, to map the group table to a virtual LDAP store.

In the <objectClass name="groupofuniquenames"> element map the group table to the virtual LDAP store, as shown in the example:

  <mapping>
         <joins/>
						<objectClass name="groupofuniquenames" rdn="cn">
						<attribute ldap="cn" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
						<attribute ldap="description" table="GROUPMEMBERS_VW" field="G_NAME" type=""/>
						<attribute ldap="uniquemember" table="GROUPMEMBERS_VW" field="G_MEMBER" type=""/>
						       <attribute ldap="orclguid" table="GROUPMEMBERS_VW" field="G_MEMBER" type=""/>
						</objectClass>
      </mapping>

Copy the two adapter files into the following folder:

ORACLE_HOME/oracle_common/modules/oracle.ovd/templates/
Open a command prompt/terminal from within:

ORACLE_HOME/oracle_common/bin
Verify that the environment variables are set:
- ORACLE_HOME=ORACLE_HOME/oraclehome
- WL_HOME=ORACLE_HOME/wlserver
- JAVA_HOME=ORACLE_HOME/jdk/jre

Run the libovdadapterconfig script to create each of the two adapters from the template files using the syntax as follows:

libovdadapterconfig -adapterName <name of adapter> -adapterTemplate <name (NOT including path) of template file which defines adapter> -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 9500 -userName weblogic -domainPath /opt/oracle_bi/user_projects/domains/bifoundation_domain/ -dataStore DB -root cn=users,dc=oracle,dc=com -contextName default -dataSourceJNDIName jdbc/UserGroupDS

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

Restart WebLogic Administration Server and Managed servers.
Sign in to WebLogic and Oracle WebLogic Server using credentials stored in the database.

Troubleshoot the SQL Authenticator

This section provides troubleshooting information on the SQL authenticator in the following topics:

Topics:

Add a User to the Global Admin Role Using the Oracle WebLogic Server Administration Console

You can use this diagnostic test if you are unable to login to Oracle Analytics Server using a database user.

If you cannot log in to Oracle Analytics Server 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 the user can log in to the Oracle WebLogic Server Administration Console to test whether the SQLAuthenticator is working at all.

If the user can log in to the console, but cannot log in to Oracle Analytics Server, the SQLAuthenticator is working correctly, but there may be issues in the identity store service. Check that you have specified the virtualize=true, and OPTIMIZE_SEARCH=true properties in Configure Identity Store Virtualization Using Fusion Middleware Control and that your DBAdapter templates are correct in Configure a Database Adaptor.

Log in to Oracle WebLogic Server Administration Console, and click Lock & Edit in the Change Center.
Select Security Realms from the left pane and click myrealm.

The default Security Realm is named myrealm.
Display the Roles and Policies tab, then display the Realm Roles tab.
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.
Ensure the conditions specified match your user, directly or by membership in a group.

For example, a possible condition is User=myadminaccount or Group=Administrators.
If you have made any changes, click Save.

Changes are applied immediately.
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://example.com:9500/console.

An Incorrect Data Source Name is Specified for the SQLAuthenticator

If you specify the wrong name for the data source field of the SQLAuthenticator, then errors are included in the log files for Administration Server and Managed Servers.

The following is an example of an error written to the log files.

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)

Use the data source name as in the example shown in Configure a Data Source Using the Oracle WebLogic Server Administration Console.

Incorrect SQL Queries

Ensure that the SQL queries that you specify when configuring the SQLAuthenticator are syntactically correct and refer to the correct tables.

For example, the following error occurs in the Administration Server.log file 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)

Correct Database Adapter Errors by Deleting and Recreating the Adapter

Use this procedure to create a replacement adapter.

You cannot modify an existing database adapter, if you make an error in the libovdadapter command or the templates, you must delete then recreate the adapter.

Log in to the Oracle WebLogic Server console by running the WLST script.

ORACLE_HOME\oracle_common\common\bin\wlst.cmd (Windows)
Connect to your Administration 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://myserverexample:9500')
Delete the poorly configured adapter using the following syntax:

deleteAdapter(adapterName='<AdapterName>')

For example:

deleteAdapter(adapterName='userGroupAdapter2')
Exit the WLST console using the exit() command.

Recreate the adapter with the correct settings by following the steps outlined in Configure a Database Adaptor.

Configure Identity Store Virtualization Using Fusion Middleware Control

Use these steps to configure identity store virtualization using Fusion Middleware Control.

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

Configure supported authentication providers as described in Configure Oracle Analytics Server to Use Alternative Authentication Providers.

Log in to Fusion Middleware Control.
From the navigation pane expand the WebLogic Domain folder and select bi.
Right-click bi and select Security, then Security Provider Configuration to display the Security Provider Configuration page.
Expand Security Store Provider and Identity Store Provider, and click Configure to display the Identity Store Configuration page.
In the Custom Properties area, use the Add option to add the following custom properties:
- Property Name=virtualize
  Value=true
- Property Name=OPTIMIZE_SEARCH
  Value=true
Note:

Use lowercase for the Property Name virtualize , and use uppercase for OPTIMIZE_SEARCH.
Note:

If you are using multiple authentication providers, go to Configure Oracle Analytics Server to Use 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.
  
  Set the value of Control Flag for all authentication providers to OPTIONAL.
  
  For example, if a user's group membership is spread across more than one authentication provider
Click OK to save the changes.
Restart the Administration Server and Managed Servers.

Configure Multiple Authentication Providers

This section explains how to configure an authentication provider so that when it fails, users from other authentication providers can still log in to Oracle Analytics Server.

If you configure Oracle Analytics Server to use multiple authentication providers, and one authentication provider becomes unavailable, users from the other authentication providers cannot log in to Oracle Analytics Server.

When you cannot log in due to an authentication provider becoming unavailable, the following error message is displayed:

Unable to Sign In
An error occurred during authentication.
Try again later or contact your system administrator

If an authenticator from multiple configured authenticators is unavailable and is not critical, use the following procedure to enable users from other authenticators to log in to Oracle Analytics Server.

Open the adapters.os_xml file for editing located in

ORACLE_HOME\user_projects\domains\bi\config\fmwconfig\ovd\default
Locate the following element in the file:

<critical>true</critical>

Change the value of the <critical> element to false for each authenticator provider that is not critical, as follows:

<critical>false</critical>
If the target authenticator is using TLS/SSL, then locate the following element in the file:

<secure>false</secure>

Change the value of the <secure> element to true for each secure authenticator provider, as follows:

<secure>true</secure>
Save and close the file.
Restart WebLogic Administration Server and Managed Servers.

Set 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.

You can also use the Oracle 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.

Configure a Single LDAP Authentication Provider as the Authenticator

This topic explains how to reconfigure Oracle Analytics Server to use a single LDAP authentication provider by disabling the default WebLogic Server LDAP authenticator.

When you install Oracle Analytics Server, the system is automatically configured to use WebLogic Server LDAP as the default authenticator. The install process automatically generates the required users and groups in WebLogic Server LDAP. If you may have your own LDAP directory, for example, Oracle Internet Directory, that you want to use as the default authenticator, you must disable the WebLogic Server default authenticator. A single source authentication provider prevents deriving user names and passwords from multiple authentication sources which could lead to multiple points of attack, or entry from unauthorized users.

Topics:

Configure Oracle Internet Directory LDAP Authentication as the Only Authenticator

Use the examples for configuring Oracle Internet Directory (OID LDAP). You can apply these examples to other LDAP authentication providers with minor changes.

Topics:

Task 1 - Enable Backup and Recovery

Before you begin the process of disabling the WebLogic Server 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 cannot restart it.

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

As you make changes, you keep copies of this file.

Task 2 - Configure the System to use WebLogic Server and an Alternative Authentication Provider

To remove the default WebLogic Server authenticators and use an alternative LDAP source (for example, OID LDAP), you must configure the system to use both WebLogic Server and the alternative method.

See Configure Oracle Analytics Server to Use Alternative Authentication Providers. Your starting point should be that the WebLogic Server LDAP users (default authenticator) and the new alternative LDAP users are both configured to allow access to Oracle Analytics Server.

When you have configured the system 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 the table are migrated from WebLogic Server LDAP to OID LDAP.

Standard WebLogic Server Users	New Users Required in OID LDAP
LCMManagerUser	OID_LCMManagerUser; you can use any existing OID LDAP user.
For example, weblogic	OID_Weblogic; you can use any existing OID LDAP user.
OracleSystemUser	OracleSystemUser, this user must exist with this name in OID LDAP which is a fixed requirement of OWSM.

Three users are created during install:

weblogic or whatever is 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 LDAP but this user can have any name, which needs to be part of a group called Administrators.
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 LDAP using this exact name.

Task 4 - Associate OID LDAP Groups with Global Roles in the WebLogic Console

Configure the global roles by mapping to OID LDAP groups.

Global Roles	Current WebLogic Server Groups	New OID LDAP Groups Required
Admin	Administrators	OID_Administrators
AdminChannelUsers	AdminChannelUsers	OID_AdminChannelUsers
AppTester	AppTesters	OID_AppTesters
CrossDomainConnector	CrossDomainConnectors	OID_CrossDomainConnectors
Deployer	Deployers	OID_Deployers
Monitor	Monitors	OID_Monitors
Operator	Operators	OID_Operators
OracleSystemRole	OracleSystemGroup	OracleSystemGroup (fixed requirement)

You must associate the global roles from the table, displayed in the Oracle WebLogic Server Administration Console, with your replacement OID LDAP groups, before you can disable the default WebLogic Server authenticator.

The default Security Realm is named myrealm.

Do not do add a new condition for the Anonymous and Oracle System roles, which can both remain unchanged.

Log in to Oracle WebLogic Server Administration Console.
In the Change Center, click Lock & Edit.
Select Security Realms from the left pane and click myrealm.
Click Realm Roles.
Click Global Roles and expand Roles.
Add a new condition for each Role.
Click View Role Conditions.
Select group from the Predicate steps.
Enter your newly-associated OID LDAP group, for example, assign the Admin role to the OID_Administrators role.
Save your changes.

After disabling the Default WebLogic Server Authentication, you can remove the old WebLogic Server groups, see Task 8 - Remove WebLogic Server Roles

Task 5 - Set User to Group Membership in OID LDAP

Now that you have created new users and groups in OID LDAP to replicate the users and groups automatically created in WebLogic Server LDAP you must ensure that these users and groups also have the correct group membership in OID LDAP as shown in the table.

New OID LDAP User	Is A Member Of These New OID LDAP Groups
OID_Weblogic	OID_Administrators OID_BIServiceAdministrators
OracleSystemUser A user with this exact name must exist in OID LDAP.	OracleSystemGroup A group with this exact name must exist in OID LDAP

New OID LDAP User

Is A Member Of These New OID LDAP Groups

OID_Weblogic

OID_Administrators

OID_BIServiceAdministrators

OracleSystemUser

A user with this exact name must exist in OID LDAP.

OracleSystemGroup

A group with this exact name must exist in OID LDAP

Note:

In order to achieve the user and group membership shown in the table, you must have suitable access to update your OID LDAP server, or someone else must be able to update group membership on your behalf.

Task 6 - Remove the Default Authenticator

You are now ready to remove the Default Authenticators.

You must create an LDAP authenticator that maps to your LDAP source before performing this task, see Task 2 - Configure the System to use WebLogic Server and an Alternative Authentication Provider.

See Set the JAAS Control Flag Option.

Change the Control Flag from SUFFICIENT to REQUIRED in the Oracle WebLogic Server Administration Console.
Save the changes.
Delete any other authenticators so that your OID LDAP authenticator is the single source.

Task 7 - 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 Oracle 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 Model Administration Tool online you must now provide the OID LDAP user and password, for example, OID_Weblogic, along with the semantic model password.

Task 8 - Remove WebLogic Server Roles

Complete this task if everything is working correctly.

The following are examples of WebLogic Server roles to remove using this procedure:

Admin
AdminChannelUsers
AppTester
CrossDomainConnector
Deployer
Monitor
Operator

See Task 4 - Associate OID LDAP Groups with Global Roles in the WebLogic Console.

Back up your config.xml file, before performing this step, see Task 1 - Enable Backup and Recovery.

Edit global roles.
Remove all WebLogic Server roles that were automatically created, from the OR clause.
Save your changes.

Task 9 - Stop Alternative Methods of Authentication

You must remove the USER variable and may need to update initialization blocks in the semantic model.

Note:

Oracle Analytics Server initialization block authentication has been deprecated and is no longer enabled for any use other than integrating with Oracle E-Business Suite Applications. You can use the information in this topic to update your existing initialization blocks.

Oracle Analytics Server 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. To implement a single source of authentication, you must remove the authentication methods that use initialization blocks from the semantic model.

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

Remove the USER system variable from the semantic model.
Ensure that initialization blocks in the semantic model have the Required for authentication check box cleared.
Check that initialization blocks in the semantic model that set the PROXY and PROXYLEVEL system session variables do not allow users to bypass security.

The PROXY and PROXYLEVEL system variables allow connected users to impersonate other users with their security profile. This method is acceptable when the impersonated user account has less privileges, but if the account has more privileges it can be a security issue.
Disable or remove initialization blocks associated with the following system session variables: USER, GROUP, and ROLES.

If you disable an initialization block, then any dependent initialization blocks are also disabled.

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

Troubleshoot

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 LDAP administrator (oidweblogic), you are locked out, and the 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 LDAP Administrator group. You resolve this issue by adding the BIServiceAdministrators group (or an OID LDAP 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, see Task 1 - Enable Backup and Recovery.

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

Configure Oracle Identity Cloud Integrator as the Authentication Provider

This section describes how to use the Oracle Identity Cloud Integrator provider to integrate Oracle Analytics Server with Oracle Identity Cloud Service for authentication.

In addition to authentication, you can also use Oracle Identity Cloud Service for SSO integration. The authentication steps described in this section are a prerequisite for configuring SSO against Oracle Identity Cloud Service. For more information, see Configure SSO with Oracle Identity Cloud Service and App Gateway.

Topics:

Create a Confidential Application for OAuth Client

In Oracle Identity Cloud Service you must create and set up a confidential application that uses OAuth.

For Oracle WebLogic Server to authenticate users with Oracle Identity Cloud Service, the Oracle Identity Cloud Integrator provider must be associated with an OAuth client that is registered with Oracle Identity Cloud Service. The OAuth client allows the provider access to Oracle Identity Cloud Service.

Log into Oracle Identity Cloud Service with tenant administrator credentials.
In the Oracle Identity Cloud Service console, expand the Navigation menu, and then click Applications.
On the Applications page, click Add and then in the Add Application dialog click Confidential Application.
In the Details section, enter a name and description to identify the application, and then click Next.
In the Client section, click Configure this application as a client now to configure the application's authorization settings.
In Authorization, click Client Credentials in Allowed Grant Types.
Scroll to Token Issuance Policy to assign the client to the Identity Domain Administrator application role. Under Grant the client access to Identity Cloud Service Admin APIs, click Add.
In App Roles, select Identity Domain Administrator.
Click Next until you reach the last step in the wizard, and then click Finish.
When the Application Added dialog is displayed, record the Client ID and Client Secret for use later in the configuration.
In the application's information page, click Activate to activate the application.

Required Configuration Attributes

To configure the Oracle Identity Cloud Integrator provider in Oracle WebLogic Server, you must provide the OAuth client attributes:

The configuration attributes enable communication between the Oracle Identity Cloud Integrator and Oracle Identity Cloud Service.

Tenant - The name of the primary tenant in the Oracle Identity Cloud Service where you provisioned the OAuth client.

The Oracle Identity Cloud Service tenant name is displayed in the browser URL when you click My Services to log in, or if you click Open Admin Console from the Service Instances section. The tenant name begins with the characters idcs- and then is followed by a string of numbers and letters.
ClientID - The OAuth client ID used to access the Oracle Identity Cloud Service identity store.

To find the OAuth ClientID, go to Oracle Identity Cloud Service, expand the Navigation menu, click Applications, and in the Applications list locate and open the OAuth application's details.
ClientSecret - The OAuth Client Secret (password) used to generate access tokens.

To find the OAuth ClientSecret, go to Oracle Identity Cloud Service, expand the Navigation menu, click Applications, and in the Applications list locate and open the OAuth application's details.
Client tenant - (Optional) The name of the OAuth Client tenant where the Client Id resides. This attribute isn't required if the Client tenant is the same as the primary tenant.

Configure the Oracle Identity Cloud Integrator Provider

Use Oracle Analytics Server Oracle WebLogic Server Administration Console to configure the Oracle Identity Cloud Integrator provider.

The Oracle Identity Cloud provider configuration supplies access to the required users and groups.

To configure the Oracle Identity Cloud provider, you must add the provider to the security realm and specify the configuration attributes required to enable communication between the provider and Oracle Identity Cloud Service.

Note the following list of exceptions when you use the WebLogic Server documentation to configure Oracle Identity Cloud Service as an SSO provider for Oracle Analytics Server:

Oracle Analytics Server can't use multiple authenticators for users. The Weblogic Server documentation states that you can have multiple authenticators, but this doesn't consider the Oracle Platform Security Services integration, which can only use SCIM or LDAP. Therefore when you use Oracle Identity Cloud Service, you can't use the virtualize=true setting.
SSO uses perimeter authentication. App Gateway enforces the perimater protection and then passes a valid idcs_user_assertion token to Oracle WebLogic Server for an authenticated user.

You need the configuration attributes to complete the Oracle Identity Cloud Integrator configuration. See Required Configuration Attributes.

Log into Oracle Analytics Server WebLogic Server Administration Console.
Click Lock and Edit.
Navigate to Security Realms, then myrealm, then Providers, and then New.
In the Create a New Authentication Provider dialog, go to the Name field and enter a name for the authentication provider.
Go to the Type field and select OracleIdentityCloudIntegrator, and then click OK.
In the Authentication Providers dialog, move the authentication provider that you created to the top row of the table.
Navigate to Security Realms, then myrealm, then Providers, and then the name of the authentication provider that you created.
In new authentication provider's Settings page, click the Common tab.
In the Control Flag: field, select SUFFICIENT.
If you're using Oracle Identity Cloud Service for authentication and not for SSO, then in the Active Types field, move both idcs_user_assertion active types from the Chosen box to the Available box.
In the Settings page, click the Provider Specific tab to configure the Oracle Identity Cloud Integrator.
Scroll to Connection. Select the SSLEnabled field and provide values in the following fields:
- Host - Enter identity.oraclecloud.com.
- Port - Enter the port used to communicate with Oracle Identity Cloud Service. In most cases you can use 443.
- Tenant - Enter the name of the primary tenant in the Oracle Identity Cloud Service where you provisioned the OAuth client.
- Client Id - Enter the OAuth client ID used to access the Oracle Identity Cloud Service identity store.
- Client Secret - Enter the OAuth Client Secret (password) used to generate access tokens.
- Confirm Client Secret - Reenter the OAuth Client Secret (password).
- Client Tenant - (Optional) Enter the name of the OAuth Client tenant where the Client Id resides. This attribute isn't required if the Client tenant is the same as the primary tenant.
Click Save.
To change the idstore from ldap to scim, open Oracle Analytics Server and go here to open the jps-config.xml file
DOMAIN_HOME/bi/config/fmwconfig/jps-config.xml
Locate <serviceInstanceRef ref="idstore.ldap"/> and change .ldap to .scim.
Click Activate changes.

Configure TLS/SSL for the Oracle Identity Cloud Integrator Provider

The Oracle Identity Cloud Integrator provider supports one-way SSL. To secure the connection using TLS/SSL, you need to establish trust between Oracle WebLogic Server and Oracle Identity Cloud Service.

To do this, you may need to obtain the Oracle Identity Cloud Service SSL certificate and import it into the Oracle WebLogic Server trust store.

In most cases you don't need to import the certificate because Oracle Weblogic Server trusts the Oracle Identity Cloud Service certificate. Oracle Identity Cloud Service contains a certificate signed by a well-known certificate authority (CA) such as Symantec, and your WebLogic domain is using Java Standard Trust.

However, you should use this procedure if you need to configure Oracle Weblogic Server to accept certificates that use wildcards. Or if your domain is configured for custom trust, you may need to import the Intermediate CA and root CA certificates into your trust store, regardless of whether Oracle Identity Cloud Service is using a well-known CA.

To configure TLS/SSL, go to the Oracle Identity Cloud Integrator provider and set the SSLEnabled attribute to true. Then set the idcsPort attribute to the appropriate SSL port for Oracle Identity Cloud Service.
To configure host name verification in Oracle WebLogic Server using the wild card host name verifier to allow WebLogic Server to accept certificates containing wildcards, open the DOMAIN_HOME/bin/setDomainEnv.sh script.
In the setDomainEnv.sh script, navigate to the EXTRA_JAVA_PROPERTIES section, and add this property:
-Dweblogic.security.SSL.hostnameVerifier=weblogic.security.utils.SSLWLSWildcardHostnameVerifier
Restart Oracle Weblogic Server.

Add Users and Groups from Oracle Identity Cloud Service to Oracle Analytics Server

Users and groups from Oracle Identity Cloud Service aren’t listed in Oracle WebLogic Server Administration Console. Instead, you add and manage these users and groups from the Console in Oracle Analytics Server.

Adding the Oracle Identity Cloud Service users and groups to Oracle Analytics Server's application roles determines what the users can see and do after signing into Oracle Analytics Server. See Get Started with Application Roles.

In the Oracle Analytics Server's Home page, click Console.
Click Users and Roles.
Click Application Roles and then click the application role to add Oracle Identity Cloud Service users and groups to.
To add a new member (user or group) to the application role, click Add Users or Add Groups. Select one or more members, and then click Add.