| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence 11g Release 1 (11.1.1) Part Number E15722-03 |
|
|
View PDF |
| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence 11g Release 1 (11.1.1) Part Number E15722-03 |
|
|
View PDF |
This chapter describes how to integrate Oracle Business Intelligence with Oracle Identity Management.
Before you perform the steps in this chapter, you must have successfully completed the installation and configuration steps described in both of the following:
Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management
The previous chapters of this guide
Important:
Oracle strongly recommends that you read Oracle Fusion Middleware Release Notes for any additional installation and deployment considerations before starting the setup process.This chapter contains the following topics:
This section contains the following topics:
Section 9.1.1, "Overview of Credential and Policy Store Configuration"
Section 9.1.5, "Regenerating User GUIDs After Identity Store Reassociation"
Oracle Fusion Middleware allows using different types of credentials and policy stores in a WebLogic domain. Domains can use stores based on an XML file or on different types of LDAP providers. When a domain uses an LDAP store, all policy and credential data is kept and maintained in a centralized store. However, when using XML policy stores, the changes made on Managed Servers are not propagated to the Administration Server unless they use the same domain home. Because the Oracle Business Intelligence EDG topology uses different domain homes for the Administration Server and the Managed Server, Oracle requires the use of an LDAP store as policy and credential store for integrity and consistency.
By default, Oracle WebLogic Server domains use an XML file for the policy store. The following sections describe the steps required to change the default store to Oracle Internet Directory LDAP for credentials or policies.
Note:
The back-end repository for the policy store and the credential store must use the same kind of LDAP server. To preserve this coherence, note that reassociating one store implies reassociating the other one, that is, the reassociation of both credential and the policy stores is accomplished as a unit using Oracle Enterprise Manager Fusion Middleware Control or the WLST command
reassociateSecurityStore.This section explains how to configure the credential store and contains the following topics:
Section 9.1.2.3, "Configuring the Identity Store to Use LDAP"
Section 9.1.2.5, "Moving the WebLogic Administrator to LDAP"
Create the users and groups you need in Oracle Internet Directory, if you have not done so already. See Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for more information.
To be safe, first back up the relevant configuration files:
ORACLE_BASE/admin/domain_name/mserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig/system-jazn-data.xml
Also back up the boot.properties file for the Administration Server.
To configure the credential store to use LDAP, set the proper authenticator using the Oracle WebLogic Server Administration Console, as follows:
Log in to the Administration Console.
Click the Security Realms link on the left navigation bar.
Click the myrealm default realm entry to configure it.
Open the Providers tab within the realm. Notice that there is a DefaultAuthenticator provider configured for the realm.
In the Change Center, click Lock & Edit.
Click New to add a new provider.
Enter a name for the provider, such as OIDAuthenticator.
Select the OracleInternetDirectoryAuthenticator type from the list of authenticators.
Click OK.
In the Providers screen, click the newly created authenticator.
Set the control flag to SUFFICIENT. This indicates that if a user can be authenticated successfully by this authenticator, then that authentication should be accepted and any additional authenticators should not be invoked. If the authentication fails, it will be passed to the next authenticator in the chain.
Make sure that all subsequent authenticators also have their control flag set to SUFFICIENT. In particular, check the control flag for the DefaultAuthenticator and set it to SUFFICIENT if necessary.
Click Save.
Open the Provider Specific tab, then enter details specific to your LDAP server, as shown in Table 9-1.
Table 9-1 LDAP Server Details
| Parameter | Value | Description |
|---|---|---|
|
Host |
For example: oid.mycompany.com |
The host name of the LDAP server. |
|
Port |
For example: 636 |
The LDAP server port number. |
|
Principal |
For example: cn=orcladmin |
The LDAP user DN used to connect to the LDAP server. |
|
Credential |
your_password |
The password used to connect to the LDAP server. |
|
SSL Enabled |
Selected |
Specifies whether SSL protocol is used when connecting to the LDAP server. |
|
User Base DN |
For example: cn=Users,dc=mycompany, dc=com |
Specifies the DN under which your Users start. |
|
Group Base DN |
For example: cn=Groups,dc=mycompany, dc=com |
Specifies the DN that points to your Groups node. |
|
User Name Attribute |
cn |
The user name attribute. |
|
Use Retrieved User Name as Principal |
Selected |
This option must be enabled. |
Click Save when done.
Click Activate Changes to propagate the changes.
Restart the Administration Server and the Managed Servers.
Reorder the OID Authenticator and Default Authenticator and ensure that the control flags for each authenticator is set as follows:
OID LDAP Authenticator: SUFFICIENT
Default Authenticator: SUFFICIENT
Restart the Administration Server.
After LDAP has been configured, all users (including administrative users) should be LDAP users. This must be configured by the LDAP administrator. An administration group should be created with the necessary users. For information about the required steps, see section 8.5 of Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management. Use 'BIAdministrators' for the group name.
After this group is created, you must update the role definition for the WLS Global Admin role in WebLogic Server, as follows:
Log in to the Administration Console.
Go to the location that defines the Admin role by selecting Security Realms, then your realm name, then Role and Policies, then Global Roles, then Roles, and then Admin. Click the View Role Conditions link.
By default, you can see that the Administrators group in Oracle Internet Directory defines who has the Admin role in WebLogic Server.
Click Add Conditions to add a different group name (BIAdministrators). Then, delete the Administrators group, leaving the new one you added.
Click Save.
After making this change, any members of the new group specified will be authorized to administer WebLogic Server.
The boot.properties file for the Administration Server must be updated with the WebLogic admin user created in Oracle Internet Directory. Follow these steps to update the boot.properties file:
On APPHOST1, go to the following directory:
APPHOST1> cd ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security
Rename the existing boot.properties file:
APPHOST1> mv boot.properties boot.properties.backup
Use a text editor to create a file called boot.properties under the security directory. Enter the following lines in the file:
username=admin_user password=admin_user_password
Save the file.
Stop and restart the Administration Server.
The domain policy store is the repository of system and application-specific policies. In a given domain, there is one store that stores all policies that all applications deployed in the domain can use. This section provides the steps to configure Oracle Internet Directory LDAP as the policy store for the Oracle Business Intelligence EDG topology.
To ensure proper access to the Oracle Internet Directory LDAP server directory used as a policy store, you must set a node in the server directory.
An Oracle Internet Directory administrator must follow these steps to create the appropriate node in the Oracle Internet Directory server:
Create an LDIF file (jpstestnode.ldif in this example) specifying the following DN and CN entries:
dn: cn=jpsroot_bi,dc=mycompany,dc=com cn: jpsroot_bi objectclass: top objectclass: OrclContainer
The DN of the root node (jpsroot_bi in the previous step) must be distinct from any other DN. One root node can be shared by multiple WebLogic domains. It is not required that his node be created at the top level, as long as read and write access to the subtree is granted to the Oracle Internet Directory administrator.
Import this data into the Oracle Internet Directory server using the command ldapadd, as shown in the following example:
OIDHOST1> ORACLE_HOME/bin/ldapadd -h ldap_host -p ldap_port -D cn=orcladmin -w password -c -v -f jpstestnode.ldif
Verify that the node has been successfully inserted using the command ldapsearch, as shown in the following example:
OIDHOST1> ORACLE_HOME/bin/ldapsearch -h ldap_host -p ldap_port -D cn=orcladmin -w password -b "cn=jpsroot_bi,dc=mycompany,dc=com" objectclass="orclContainer"
When using Oracle Internet Directory as the LDAP-Based policy store, run the utility oidstats.sql in the INFRADBHOST to generate database statistics for optimal database performance:
OIDHOST1> connect ods/welcome1
OIDHOST1> @ORACLE_HOME/ldap/admin/oidstats.sql
Note: The oidstats.sql utility only needs to be run once after the initial provisioning.
To reassociate the policy and credential store with Oracle Internet Directory, use the WLST reassociateSecurityStore command, as follows:
From APPHOST1, start the wlst shell:
APPHOST1> cd ORACLE_HOME/common/bin
APPHOST1> ./wlst.sh
Connect to the WebLogic Administration Server using the wlst connect command, as follows:
connect ("AdminUser", "AdminPassword", "t3://hostname:port")
For example:
connect ("weblogic", "welcome1", "t3://ADMINHOSTVPN1:7001")
Run the reassociateSecurityStore command, as follows:
reassociateSecurityStore(domain="domainName", admin="cn=admin_user_name", password="orclPassword", ldapurl="ldap://LDAPHOST:LDAPPORT", servertype="OID", jpsroot="cn=jpsroot_bi")
For example:
wls:/bifoundation_domain/serverConfig> reassociateSecurityStore(domain="bifoundation_domain", admin="cn=orcladmin", password="welcome1", ldapurl="ldap://oid.mycompany.com:389", servertype="OID", jpsroot="cn=jsproot_bi,dc=mycompany,dc=com")
Restart the Administration Server after the command completes successfully.
Note:
For credential and policy changes to take effect, the servers in the domain must be restarted.This section contains the following topics:
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 completely 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.
Oracle recommends that you follow these two best practices to ensure that GUIDs are consistently applied in each phase of the development to production lifecycle:
Ensure that a fan-out replica of the identity store is used between development, test, and production systems, so that user GUIDs are consistent and identical across the complete development to production lifecycle. See "Setting Up Replication" in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for further information about creating fan-out replicas.
Wherever possible, secure access to data and metadata using application roles rather than individual users.
GUID regeneration is the process of regenerating any metadata references to user GUIDs in the Oracle BI repository and Oracle BI Presentation Catalog. During the GUID regeneration 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 regeneration 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 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 regeneration 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 regenerate user GUIDs, perform the following steps on APPHOST1 and APPHOST2. Note that GUID regeneration must occur with only one node operating at a time.
Stop Oracle BI Server and Presentation Services on all nodes except where you are regenerating the user GUIDs. For example:
cd ORACLE_BASE/admin/instancen/bin ./opmnctl stopproc ias-component=coreapplication_obips1 ./opmnctl stopproc ias-component=coreapplicaiton_obis1
Update the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS parameter in NQSConfig.INI:
Open NQSConfig.INI for editing at:
ORACLE_INSTANCE/config/OracleBIServerComponent/coreapplication_obisn
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;
Save and close the file.
Update the Catalog element in instanceconfig.xml:
Open instanceconfig.xml for editing at:
ORACLE_INSTANCE/config/OracleBIPresentationServicesComponent/ coreapplication_obipsn
Locate the Catalog element and update it as follows:
<Catalog>
<UpgradeAndExit>false</UpgradeAndExit>
<UpdateAccountGUIDs>UpdateAndExit</UpdateAccountGUIDs>
</Catalog>
Save and close the file.
Restart the Oracle BI Server and Presentation Services using opmnctl:
cd ORACLE_BASE/admin/instancen/bin ./opmnctl stopproc ias-component=coreapplication_obips1 ./opmnctl stopproc ias-component=coreapplication_obis1 ./opmnctl startproc ias-component=coreapplication_obis1
After you confirm that the Oracle BI Server is running, then start Presentation Services:
./opmnctl startproc ias-component=coreapplication_obips1
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.
Update the Catalog element in instanceconfig.xml to remove the UpdateAccount GUIDs entry.
Restart the Oracle Business Intelligence system components using opmnctl:
cd ORACLE_BASE/admin/instancen/bin ./opmnctl stopall ./opmnctl startall
This section describes how to set up Oracle Access Manager 10g as a single sign-on solution for the Oracle Business Intelligence topology.
This section contains the following topics:
The instructions for Oracle Access Manager 10g assume an existing Oracle Access Manager installation, complete with Access Managers and a policy protecting the Policy manager. For more information about installing and configuring an Oracle Access Manager installation, see Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.
The configuration described in this chapter includes a directory service such as Oracle Internet Directory, either as a standalone component or as part of an Oracle Virtual Directory configuration. This section provides the necessary steps for configuring your Oracle Business Intelligence installation with Oracle Internet Directory.
In addition, the Oracle Access Manager installation should have its own Web server configured with WebGate. This section also provides steps for using the Oracle Access Manager Web server as a delegated authentication server.
This section explains how to use the Oracle Access Manager Configuration Tool and contains the following topics:
Section 9.2.2.1, "About the Oracle Access Manager Configuration Tool"
Section 9.2.2.2, "Collecting Information for the Oracle Access Manager Configuration Tool"
Section 9.2.2.3, "Running the Oracle Access Manager Configuration Tool"
Section 9.2.2.4, "Verifying Successful Creation of the Policy Domain and AccessGate"
The Oracle Access Manager Configuration Tool (oamcfgtool) starts a series of scripts and sets up the required policies. It requires various parameters as inputs. Specifically, it creates the following:
A Form Authentication scheme in Oracle Access Manager
Policies to enable authentication in Oracle WebLogic Server
A WebGate entry in Oracle Access Manager to enable Oracle HTTP Server WebGates (from your Web tier) to protect your configured application
A Host Identifier, depending on the scenario chosen (a default host identifier would be used, if not provided)
Policies to protect and unprotect the application-specific URL
Collect or prepare the following information before running the Oracle Access Manager Configuration Tool:
Password: Create a secure password. This will be used as the password for the WebGate installation performed later.
LDAP Host: The host name of the Directory Server or load balancer address, for HA/EDG configurations.
LDAP Port: The port number of the Directory Server.
LDAP USER DN: The DN of the LDAP administrator user (for example, "cn=orcladmin").
LDAP password: The password of the LDAP administrator user.
OAM_AA_HOST: The host name of the Oracle Access Manager instance.
OAM_AA_PORT: The Oracle Access Manager port number.
The Oracle Access Manager Configuration Tool is located in the following directory:
MW_HOME/oracle_common/modules/oracle.oamprovider_11.1.1
The tool can be run from any computer with the required installation files. In this case, you run it from APPHOST1.
Run the Oracle Access Manager Configuration Tool, as follows (all on a single line):
MW_HOME/jrockit_160_22_D1.1.1-3/bin/java -jar oamcfgtool.jar mode=CREATE app_domain="bifoundation_domain" protected_uris="$PROTECTED_URI_LIST" public_uris="$PUBLIC_URI_LIST" ldap_host="oid.mycompany.com" ldap_port=389 ldap_userdn="cn=LDAP_admin_user_name" ldap_userpassword=LDAP_admin_user_password oam_aaa_host=OAMHOST1 oam_aaa_port=OAMPORT1 oam_aaa_mode=simple
For $PROTECTED_URI_LIST, use:
"/analytics/saw.dll,/xmlpserver,/ui,/bioffice,/em,/console,/ui/adfAuthentication"
For $PUBLIC_URI_LIST, use:
"/analytics,/analytics/saw.dll/wsdl,/xmlpserver/services,/xmlpserver/ report_service,/xmlpserver/ReportTemplateService.xls,/xmlpserver/Guest, /ui/do/logout,/ui/images,/bioffice/services/saw?WSDL"
You will be prompted for the app_agent_password.
Note:
If additional URLs need to be protected later, run the Oracle Access Manager Configuration Tool again using the same app_domain. Be sure to include all the URLs that need to be protected, not just the new ones.This section covers how to validate that the Policy Domain and AccessGate were created successfully.
Verifying the Policy Domain
Follow these steps to verify the policy domain:
Log on to Oracle Access Manager at:
http://OAMADMINHOST:port/access/oblix
Click Policy Manager.
Click the My Policy Domains link on the left panel. A list of all policy domains is displayed, including the domain you just created.
Click the link to the policy domain you just created. The General area of the domain is displayed.
Click the Resources tab. The URIs you specified are displayed. You can also click other tabs to view other settings.
Verifying the AccessGate Configuration
Follow these steps to verify the AccessGate configuration:
Click the Access System Console link on the top right. Note that this link toggles between Access System Console and Policy Manager when you click it.
Click the Access System Configuration tab.
Click the AccessGate Configuration link in the left pane.
Enter 'bifoundation_domain' as the search criterion (or another substring in your app_domain), and then click Go.
The AccessGate for the domain you just created is displayed. This result will have the suffix _AG (for example, bifoundation_domain_AG).
Click the AccessGate for your domain to see details.
The Oracle Access Manager Configuration Tool uses the value of the app_domain parameter to create a host identifier for the policy domain. This host identifier must be updated with all the host name variations for the host so that the configuration works correctly.
Follow these steps to update the host identifier created by the Oracle Access Manager Configuration Tool:
Navigate to the Access System Console by entering the following URL in your Web browser:
http://hostname:port/access/oblix
where hostname refers to the host where the WebPass Oracle HTTP Server instance is running, and port refers to the HTTP port of the Oracle HTTP Server instance.
When prompted for a username and password, log in as an administrator. Click OK.
On the Access System main page, click the Access System Console link.
On the Access System Console page, click the Access System Configuration tab.
On the Access System Configuration page, click Host Identifiers on the bottom left.
On the List all host identifiers page, click the host identifier created by the Oracle Access Manager Configuration Tool. For example, select bifoundation_domain.
On the Host Identifier Details page, click Modify.
On the Modifying host identifier page, add all the possible host name variations for the host. Click the plus and minus symbols to add or delete fields as necessary.
The Preferred HTTP Host value used in the Access System Configuration must be added as one of the host name variations. For example:
bifoundation_domain, webhost1.mycompany.com:7777, admin.mycompany.com:7777
Select Update Cache and then click Save.
The following message is displayed: "Updating the cache at this point will flush all the cache in the system. Are you sure?"
Click OK to finish saving the configuration changes.
Verify the changes on the Host Identifier Details page.
The Oracle Access Manager Configuration Tool populates the Preferred_HTTP_Host and hostname attributes for the WebGate profile that is created with the value of the app_domain parameter. Both of these attributes must be updated with the correct values for the configuration to work.
Follow these steps to update the WebGate profile created by the Oracle Access Manager Configuration Tool:
Navigate to the Access System Console by entering the following URL in your Web browser:
http://hostname:port/access/oblix
where hostname refers to the host where the WebPass Oracle HTTP Server instance is running, and port refers to the HTTP port of the Oracle HTTP Server instance.
When prompted for a username and password, log in as an administrator. Click OK.
On the Access System main page, click the Access System Console link.
On the Access System Console page, click the Access System Configuration tab to display the AccessGate Search page.
Enter the appropriate search criteria and click Go to display a list of AccessGates.
Select the AccessGate created by the Oracle Access Manager Configuration Tool. For example: bifoundation_domain_AG
On the AccessGate Details page, select Modify to display the Modify AccessGate page.
On the Modify AccessGate page, update the following:
Hostname: Update the hostname with the name of the computer where WebGate is running. For example: webhost1.mycompany.com
Preferred HTTP Host: Update the Preferred_HTTP_Host with one of the host name variations specified in the previous section. For example: webhost1.mycompany.com:7777
Primary HTTP Cookie Domain: Update the Primary HTTP Cookie Domain with the Domain suffix or the host identifier. For example: mycompany.com
Port: Update the port with the port where WebGate is running. For example: 7777*
Maximum Connections: Set to 4.
Click Save, then click OK to confirm.
Verify the values displayed on the Details for AccessGate page to confirm that the updates were successful.
WebGate must be installed on each of the WEBHOSTn computers to secure the Web tier. To do this, follow these steps:
Launch the WebGate installer using the following command:
./Oracle_Access_Manager10_1_4_3_0_linux_OHS11g_WebGate -gui
The Welcome screen is displayed. Click Next.
In the Customer Information screen, enter the user name and user group under which the Web server is running. Click Next to continue.
In the installation target screen, specify the directory where WebGate should be installed. Click Next to continue.
In the installation summary screen, click Next.
Download the required GCC runtime libraries for WebGate as instructed in the WebGate configuration screen, and use Browse to point to their location on the local computer. Click Next to continue.
The installer now creates the required artifacts. After that process is complete, click Next to continue.
In the transport security mode screen, select the same mode that was configured for the BI Access Gate (for example, Simple) and click Next to continue.
In the WebGate Configuration screen, provide the details of the Access Server that will be used. You must provide the following information:
WebGate ID, as provided when the Oracle Access Manager Configuration Tool was executed
Password for WebGate
Access Server ID, as reported by the Oracle Access Manager Access Server configuration
Access Server host name, as reported by the Oracle Access Manager Access Server configuration
Access Server port number, as reported by the Oracle Access Manager Access Server configuration
Global Access Protocol Pass Phrase
You can obtain these details from your Oracle Access Manager administrator. Click Next to continue.
In the Configure Web Server screen, click Yes to automatically update the Web server. Click Next to continue.
In the next Configure Web Server screen, specify the full path of the directory containing the httpd.conf file. Click Next to continue.
In the next Configure Web Server page, a message informs you that the Web Server configuration has been modified for WebGate. Click Yes to confirm.
Stop and start your Web server for the configuration updates to take effect. Click Next to continue.
In the next Configure Web Server screen, a message about SSL is displayed. Click Next to continue.
In the next Configure Web Server screen, a message with the location of the document that has information about the rest of the product setup and Web server configuration is displayed. Choose No and click Next to continue.
The final Configure Web Server screen appears with a message to manually launch a browser and open the HTML document for further information on configuring your Web server. Click Next to continue.
The Oracle COREid Readme screen appears. Review the information on the screen and click Next to continue.
A message appears, providing details of the installation and informing you that the installation was successful.
The instructions in this section assume that you have already set up the LDAP Authenticators.
This section contains the following topics:
To set up the Oracle Access Manager ID Asserter, follow these steps:
Log in to the Administration Console.
In the Change Center, click Lock & Edit.
Navigate to SecurityRealms\myrealm\Providers.
Click New and select OAM Identity Asserter from the drop-down menu.
Name the asserter (for example: OAM ID Asserter) and click OK.
Click the newly added asserter to see the configuration screen for OAM Identity Asserter.
Set the control flag to REQUIRED and click Save.
Open the Provider Specific tab to configure the following required settings:
Primary Access Server: Provide the Oracle Access Manager server endpoint information in HOST:PORT format.
AccessGate Name: Provide the name of the AccessGate (for example, bifoundation_domain_AG).
AccessGate password: Provide the password for the AccessGate.
Click Save when done.Click Activate Changes to propagate the changes.Restart the Administration Server and the Managed Servers.
Reorder the Oracle Access Manager Identity Asserter, Oracle Internet Directory Authenticator, and Default Authenticator by ensuring that the control flag for each authenticator is set, as follows:
OAM Identity Asserter: REQUIRED
OID LDAP Authenticator: SUFFICIENT
Default Authenticator: SUFFICIENT
Then, restart the Administration Server and the Managed Servers.
This section explains how to configure applications, and contains the following topics:
Section 9.2.7.1, "Enabling SSO/Oracle Access Manager for Oracle BI Enterprise Edition"
Section 9.2.7.2, "Enabling SSO/Oracle Access Manager for Oracle BI Publisher"
Section 9.2.7.3, "Enabling SSO/Oracle Access Manager for Oracle BI for Microsoft Office"
Section 9.2.7.4, "Enabling SSO/Oracle Access Manager for Oracle BI Search"
Section 9.2.7.5, "Enabling SSO/Oracle Access Manager for Oracle Real-Time Decisions"
To enable SSO and Oracle Access Manager for Oracle BI Enterprise Edition, follow these steps:
Log in to Fusion Middleware Control.
Go to Business Intelligence > coreapplication > Security.
Click Lock and Edit Configuration.
Choose Enable SSO and select Oracle Access Manager for SSO Provider.
Configure the login/logout information for the Oracle BI Presentation Services processes by entering the logon and logoff URLs in the following fields:
The SSO Provider Logon URL: http://OAM_host:OAM_port/oamsso/login.html
The SSO Provider Logoff URL: http://OAM_host:OAM_port/access/oblix/lang/en-us/logout.html
Click Apply.
Click Activate Changes.
Restart all Oracle Business Intelligence system components using opmnctl or Fusion Middleware Control.
To enable SSO and Oracle Access Manager for Oracle BI Publisher, follow these steps:
In Oracle BI Publisher, go to the Administration > Security Configuration page to enable SSO.
On the Security Configuration Page, provide the following information in the Single Sign-On section:
Select Use Single Sign-On.
For Single Sign-On Type, select Oracle Access Manager.
For Single Sign-Off URL, enter a URL of the following format:
http://OAM_host:OAM_port/access/oblix/lang/en-us/logout.html
For example:
http://bi.mycompany.com:7777/access/oblix/lang/en-us/logout.html
Click Apply.
Restart the bipublisher application from the Administration Console.
SSO configuration for Oracle BI for Microsoft Office was covered in Section 6.5.4.1, "Configuring Oracle BI for Microsoft Office Properties." If you have not already enabled SSO for Oracle BI for Microsoft Office, perform the steps in Section 6.5.4.1 to accomplish this task.
To enable SSO and Oracle Access Manager for Oracle BI Search, follow these steps:
Open the BISearchConfig.properties file for editing. You can find this file at:
DOMAIN_HOME/config/fmwconfig/biinstances/coreapplication/
Set the value of BIServerSSOUrl to the following:
https://bi.mycompany.com/analytics
Save and close the file.
This section provides information about Oracle Real-Time Decisions configuration with Oracle Access Manager.
This section contains the following topics:
Section 9.2.7.5.1, "Oracle RTD and Oracle Access Manager Logout Guidelines"
Section 9.2.7.5.2, "Avoiding Problems with Decision Center Logout Redirection"
For Oracle RTD to comply with Oracle Access Manager logout guidelines (in particular, invoking a logout through /adfAuthentication?logout=true&end_url=/ui/do/logout), integration with Oracle Access Manager 10g requires additional WebGate configuration to handle the end_url. Without this additional configuration, you are logged out, but not redirected to the end URL because Oracle Access Manager 10g WebGate does not process end_url.
For information about configuration procedures, see Oracle Fusion Middleware Application Security Guide.
When Webgate 10g against Oracle Access Manager (OAM) 11g is configured as the SSO provider for Oracle RTD Decision Center access, logging out of, then back into Decision Center should ask users for their user name and password credentials on the re-login. To ensure that this occurs correctly, you must configure the following Oracle RTD Decision Center resources in OAM/Webgate as public (unprotected or anonymous access):
Decision Center logout URI /ui/do/logout
Decision Center images /ui/images/*
|
 Copyright © 2010, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|