Resources Protected Introduction to Oracle Reports Security

15-6 Publishing Reports to the Web with Oracle Reports Services If you specified Oracle Internet Directory information during the installation of Oracle Reports 11g Release 1 11.1.1, authentication based on Single Sign-On is enabled for both in-process servers and standalone servers. In addition, Portal-based security is enabled, so you can use Portal-based authorization if Portal is configured.

15.3 Authentication in Oracle Reports

This section describes authentication features, tasks, and concepts that are specific to Oracle Reports. It discusses the following topics: ■ OracleAS Single Sign-On Authentication ■ Non-SSO Authentication ■ Authentication Scenarios for JPS-Based Security ■ Authentication Scenario for Portal-Based Security Authentication Methods Oracle Reports 11g Release 1 11.1.1 supports the following authentication methods: ■ OracleAS Singe Sign-On. For more information, see OracleAS Single Sign-On Authentication . ■ Non-SSO, including the following: – Oracle Internet Directory rwsec, or JPS-OID configured – Embedded ID store in-process servers – JAZN-XML File-Based ID store standalone servers The following table summarizes the authentication methods for JPS-based security that Oracle Reports supports. The following table summarizes the authentication methods for Portal-based security that Oracle Reports supports. Note: If you did not specify Oracle Internet Directory information during the installation of Oracle Reports 11g Release 1 11.1.1, no authentication is enabled. Therefore, both in-process servers and standalone servers are not secure. Note: For more information about non-SSO authentication methods, see Non-SSO Authentication . Table 15–2 Authentication Methods for JPS-Based Security Type of Reports Server Oracle Internet Directory WebLogic ID Store Single Sign-On File-Based In-process servers Yes Yes Yes No Standalone servers Yes No Yes Yes Securing Oracle Reports Services 15-7

15.3.1 OracleAS Single Sign-On Authentication

OracleAS Single Sign-On makes use of an encrypted cookie to track authenticated application users. When rwservlet receives a request to execute a report on a secured Reports Server, it queries the Oracle HTTP Server through the getRemoteUser call to determine whether the user has already logged on through OracleAS Single Sign-On that is, a Single Sign-On cookie exists for the user: ■ If the user has logged on already that is, the cookie exists, then rwservlet gets the users identity from the Oracle HTTP Server. ■ If the user has not logged on already that is, the cookie does not exist yet, then the Oracle HTTP Server redirects the user to OracleAS Single Sign-On, which prompts the user to login. Once the user is authenticated, the Single Sign-On cookie is created and the user is redirected back to rwservlet, which then proceeds as described in the previous bullet item.

15.3.1.1 Report Request Flow with Single Sign-On

In this scenario, a report request is sent to a secured Reports Server with Single Sign-On enabled. Figure 15–1 Authentication Process with Single Sign-On The following numbered steps map to the numbers in Figure 15–2 :

1. User requests the report through a URL

. The report request is made through one of the following methods: Table 15–3 Authentication Methods for Portal-Based Security Type of Reports Server Authentication Based on Oracle Internet Directory Single Sign-On In-process servers Yes Yes Standalone servers Yes Yes 15-8 Publishing Reports to the Web with Oracle Reports Services ■ The user chooses a link on a Web page or a bookmark that contains a URL that requests the report. ■ From within Oracle Portal if configured, the user requests to run the report object for example, clicks the Run link. The user must be logged into Oracle Portal and, consequently, OracleAS Single Sign-On. As part of its security, Oracle Portal validates that the user has the required security permissions to see the report object. For example, if the report object is on a page, the user must have appropriate privileges to see the page and the reports object. Otherwise, Oracle Portal will not display the page or the report object to the user.

2. Oracle HTTP Server routes the request to rwservlet deployed on Oracle

WebLogic Server. The URL redirects the user to either rwservlet or the JSP depending upon whether this report has been set to execute through rwservlet or a JSP.

3. rwservlet

asks OracleAS Single Sign-On to authenticate the user. 4. OracleAS Single Sign-On server requests the user name and password. 5. Oracle HTTP Server displays the login page to the user, and the user provides user name and password. 6. User name and password are passed on to OracleAS Single Sign-On. 7. OracleAS Single Sign-On verifies the credentials with Oracle Internet Directory. 8. If the user is authenticated, OracleAS Single Sign-on server passes the user authenticated message to rwservlet. If you used SSOCONN in your URL, rwservlet checks the Single Sign-On key against Oracle Internet Directory to see if it already has been mapped to a data source connection string for example, scotttigermy_or_db. If you used SSOCONN and Oracle Internet Directory already has a connection string associated with the key, then rwservlet uses that connection string for the data source connection of the report. If you used SSOCONN but Oracle Internet Directory does not already contain a connection string for the key, the Oracle Delegated Administration Services Create Note: The URL may optionally contain or reference that is, through the key map file a Single Sign-On parameter SSOCONN with a value of the form: key_namedata_source_typeparameter_name In the case of an Oracle database, the Single Sign-On value would look something like the following: mykeyOracleDBuserid If you do not specify a data source type and parameter name, an Oracle database is assumed. Note: Because of this feature, many users can use the same report URL even if they all use different data source connection strings.