14.3 Authentication in Oracle Reports

This section describes authentication features, tasks, and concepts that are specific to Oracle Reports.

It discusses the following topics:

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 2 (11.1.2) supports the following authentication methods:

Singe Sign-On. For more information, see 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)
Note:
For more information about non-SSO authentication methods, see Non-SSO Authentication.

The following table summarizes the authentication methods for JPS-based security that Oracle Reports supports.

Table 14-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

The following table summarizes the authentication methods for Portal-based security that Oracle Reports supports.

Table 14-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

14.3.1 Single Sign-On Authentication

In addition to working with Oracle Single Sign-On Server 10g (OSSO), Oracle Reports Services applications can now run in a single sign-on environment using Oracle Access Manager 11g (OAM) and Oracle Internet Directory (OID) to eliminate the need for additional or different logins to access many applications during the same user session. Oracle Reports Services applications in Oracle FMW 11g Release 2 can be protected by one of the following authentication servers in the single sign-on environment:

Oracle Single Sign-On Server (OSSO) 10g
Oracle Access Manager (OAM) 11g

During the installation of authentication servers, users can choose to authenticate their Reports Applications using one of these authentication servers. It is required that these authentication servers are configured to use Oracle Internet directory as the backend Identity Store. Authentication servers are designed to work in Web environments where multiple Web-based applications are accessible from a browser. Without an authentication server, each user must maintain a separate identity and password for each application they access. Maintaining multiple accounts and passwords for each user is unsecure and expensive.

Oracle Access Manager 11g is a Java Platform, Enterprise Edition (Java EE)-based enterprise-level security application that provides restricted access to confidential information and centralized authentication and authorization services. Oracle Access Manager 11g, a component of Oracle Fusion Middleware 11g, is a Single Sign-On solution for authentication and authorization.

14.3.1.1 Authentication Flow with Oracle Single Sign-On Server (OSSO) 10g

OracleAS Single Sign-On server 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 user's 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 server, 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.

Figure 14-1 describes the authentication process with Oracle Sign-On server (OSSO).

Figure 14-1 Authentication Process with OracleAS Single Sign-On Server

Description of "Figure 14-1 Authentication Process with OracleAS Single Sign-On Server"

The following numbered steps map to the numbers in Figure 14-2:

User requests the report (through a URL).

The report request is made through one of the following methods:
- The user chooses a link on a Web page or a bookmark that contains a URL that requests the report.
  
  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_name/data_source_type/parameter_name
  
  In the case of an Oracle database, the Single Sign-On value would look something like the following:
  
  mykey/OracleDB/userid
  
  If you do not specify a data source type and parameter name, an Oracle database is assumed.
- 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.
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.
rwservlet asks OracleAS Single Sign-On to authenticate the user.
OracleAS Single Sign-On server requests the user name and password.
Oracle HTTP Server displays the login page to the user, and the user provides user name and password.
User name and password are passed on to OracleAS Single Sign-On.
OracleAS Single Sign-On verifies the credentials with Oracle Internet Directory.
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, scott/tiger@my_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.

Note:
Because of this feature, many users can use the same report URL even if they all use different data source connection strings.

If you used SSOCONN but Oracle Internet Directory does not already contain a connection string for the key, the Oracle Delegated Administration Services Create Resource page displays for the user to enter their data source connection string. See Figure 14-4.

Oracle Delegated Administration Services stores the string in Oracle Internet Directory for future use and rwservlet uses the newly entered connection string for the data source connection string of the report.

Figure 14-2 Oracle Delegated Administration Services Create Resource

Description of "Figure 14-2 Oracle Delegated Administration Services Create Resource"

14.3.1.2 Authentication Flow with Oracle Access Manager (OAM) 11g

Figure 14-3 describes the authentication process with Oracle Access Manager as the authentication server.

Figure 14-3 Authentication Process with OAM 11g Server

Description of "Figure 14-3 Authentication Process with OAM 11g Server"

User requests the report (through a URL).
Oracle HTTP Server routes the request to the OAM server.
OAM server sends a page requesting the user name and password.
The credentials, provided by the user, are sent to the OAM server.
Oracle Access Manager (OAM) verifies the credentials with Oracle Internet Directory.
If the user is authenticated, OAM 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, scott/tiger@my_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.

Note:
When your Reports application is authenticated with OAM 11g server, even if the Single Sign-On parameter is set to No, the OAM authentication page is displayed and not the Reports authentication page.

If you used SSOCONN but Oracle Internet Directory does not already contain a connection string for the key, then Oracle Reports raises a 'key does not exist' error message.

14.3.2 Non-SSO Authentication

If any of the non-SSO authentication methods is used (based on Oracle Internet Directory, File-based in case of JPS-based security, and Embedded ID store), then any user accessing a secured instance of the Reports Server is challenged to identify themselves by rwservlet or Reports clients through their own authentication mechanism.

Table 14-4 Non-SSO Authentication Methods

ID Store	Authentication
Oracle Internet Directory (`rwsec`, or JPS-OID configured)	Authentication against Oracle Internet Directory
Embedded ID store (in-process servers)	Authentication against embedded ID store of WebLogic Server
JAZN-XML File-based ID store (standalone servers)	Authentication against file-based ID store

Because the HTTP 1.0 protocol is stateless (that is, each call to the server is effectively independent of all others), users may want to authenticate themselves for each report request unless a cookie is maintained. To allow users to authenticate themselves only once per session, rwservlet has its own client-side cookie, the AUTHID cookie, in which it stores the required authentication information for the current session. Once the user is authenticated, an encrypted cookie is created in the browser to enable the user to submit multiple report jobs without re-authenticating for each request.

Note:

If you want to force users to authenticate themselves for a specific report, you can use the SHOWAUTH command line keyword. Alternatively, you can include a %S in the corresponding report entry in the key map file. This file is usually called cgicmd.dat and is located in $DOMAIN_HOME/config/fmwconfig/servers/<WLS_SERVER_NAME>/applications/reports_<version>/configuration/cgicmd.dat. %S forces users to enter their username and password each time the report is called. For more information, see Section 17.13, "Using a Key Map File".

The AUTHID cookies are terminated when the user closes their browser session, but you should not rely strictly on this method of terminating the cookie. You should limit the lifetime of the cookie within a given session. For example, a user might log on and then go to lunch, leaving the browser session open. To minimize the potential for a security breach in this situation, the administrator may specify the COOKIEEXPIRE parameter as an attribute of the element cookie in the rwservlet.properties file.

For example, you can specify the cookie element in the rwservlet.properties file as follows:

<cookie cookieexpire="30" encryptionkey="reports"/>

When rwservlet receives a job request, it compares the time saved in the cookie with the current system time. If the time is longer than the number of minutes defined in the environment variable (for example, 30 minutes), the cookie is rejected and the user is challenged to provide authentication information.

14.3.2.1 Report Request Flow with Non-SSO (Oracle Internet Directory-Based, File-Based, or Embedded ID Store)

In this scenario, the report request is sent to a secured Reports Server with Single Sign-On disabled. Non-SSO authentication methods include Oracle Internet Directory-based, File-based, and Embedded ID store. In this case, rwservlet or a JSP report might be called through the use of a bookmark or from an Oracle Portal component.

Figure 14-4 Authentication Process Without Single Sign-On

Description of "Figure 14-4 Authentication Process Without Single Sign-On"

The following numbered steps map to the numbers in Figure 14-5:

User requests the report (through a URL).

The user must somehow gain access to the URL that launches the report request (for example, through a link on a Web page or a bookmark), and choose the URL.
Oracle HTTP Server routes the request to rwservlet deployed on Oracle WebLogic Server.
rwservlet asks for user credentials (that is, user name and password).

rwservlet checks for the AUTHID parameter in the URL or an existing Oracle Reports AUTHID cookie. If it finds the AUTHID parameter, it uses that to authenticate the user. If it does not find the AUTHID parameter, it looks for an existing Oracle Reports AUTHID cookie. (If the report is launched from Oracle Portal, AUTHID is added to the URL automatically.) If neither the AUTHID parameter nor an Oracle Reports AUTHID cookie is found, rwservlet sends the System Authentication page to the Oracle HTTP Server, to display to the user.
Oracle HTTP Server displays the login page to the user, and the user provides user name and password.

On the login page, the user must supply a user name and password. This information is stored in an Oracle Reports AUTHID cookie for future reference.
User name and password are passed on to rwservlet.

If only partial data source credentials are provided in the URL (for example, USERID=scott@orqa), the Database Authentication page displays with the partial credentials shown. The user must supply the remainder of the data source credentials before proceeding further. Note that you can control which Database Authentication page is used through the DBAUTH parameter in the rwservlet.properties file. If no data source credentials are provided, the Database Authentication page does not display and it is assumed the report does not require a data source.

See Also:
Section 7.3, "Oracle Reports Servlet Configuration File" for more information about the DBAUTH parameter and the rwservlet.properties file.

The data source credentials are stored in an Oracle Reports USERID cookie for future reference. Note that pluggable data source (PDS) credentials are not stored in Oracle Reports USERID cookies.
rwservlet forwards user name and password to Reports Server.

rwservlet constructs a command line with the necessary information from the previous steps and passes it to Reports Server.
Reports Server authenticates the user (that is, verifies the user name and password) against the ID Store.

Reports Server validates the user credentials against the ID store (Oracle Internet Directory, embedded ID store or file-based Oracle Internet Directory). If the validation check fails for any reason, then an error condition is returned to the user and the process terminates.

14.3.3 Authentication Scenarios for JPS-Based Security

This section discusses the following authentication scenarios:

If Reports is using JPS security, JPS-OID for security policies, and an embedded ID store
If Reports is using JPS security and JPS-OID as ID store

Note:
By default, an in-process server uses the embedded ID store of Oracle WebLogic Server as the ID store and the system-jazn-data.xml file as the policy store. Standalone servers use the system-jazn-data.xml file as both ID store and policy store.

14.3.3.1 If Reports is using JPS security, JPS-OID for security policies, and an embedded ID store

It is recommended that you move users in your current ID store, such as embedded ID store, to Oracle Internet Directory, which is an LDAP-based ID store. Subsequently, you can map users to application roles. For information about moving users to Oracle Internet Directory, see the section "Migrating Identities Manually" in the Oracle Fusion Middleware Security Guide. For information about mapping users to application roles, see Mapping Users to Application Roles.

14.3.3.2 If Reports is using JPS security and JPS-OID as ID store

You must map users in Oracle Internet Directory to the default application roles. For information about mapping users to application roles, see Mapping Users to Application Roles.

Note:

In the above authentication scenarios, if Single Sign-On is enabled, the Single Sign-On screen is displayed. If Single Sign-On is disabled, the Reports sysauth screen is displayed. In either case, users are authenticated against Oracle Internet Directory. If you have not moved your users to Oracle Internet Directory, then users are authenticated against the embedded ID store for in-process servers. For standalone servers, such users are authenticated against the file-based ID store.

14.3.4 Authentication Scenario for Portal-Based Security

If you are using Portal-based security, Oracle Internet Directory-based authentication is used.

You can map users to application roles. For information about mapping users to application roles, see Mapping Users to Application Roles.

Note: