Thank you for your feedback!This section describes authentication features, tasks, and concepts that are specific to Oracle Reports.
It discusses the following topics:
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)
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 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 |
The following table summarizes the authentication methods for Portal-based security that Oracle Reports supports.
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 |
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 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, 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.
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:
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 15-3.
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 15-2 Oracle Delegated Administration Services Create Resource
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 15-4 Non-SSO Authentication Methods
| ID Store | Authentication |
|---|---|
|
Oracle Internet Directory ( |
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 18.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.
See Also:
Section 8.3, "Oracle Reports Servlet Configuration File" for more information about the COOKIEEXPIRE parameter and the rwservlet.properties file.
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 15-3 Authentication Process Without Single Sign-On
The following numbered steps map to the numbers in Figure 15-4:
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 8.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.
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.
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.
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.
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:
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.
Sign In
