This section introduces security features and concepts in Oracle Reports. It also describes the new security features introduced in Oracle Reports 11g Release 2 (11.1.2).
This section discusses the following topics:
In addition to working with Oracle Single Sign-On Server 10g (OSSO), Oracle Reports 11g Release 2 can now run in a Single Sign-on environment using Oracle Access Manager 11g (OAM) as the authentication server. For more information see, Chapter 16, "Configuring and Administering Oracle Single Sign-On".
Oracle Reports 11g Release 2 (11.1.2) uses a standards-based Java EE security model through Oracle Platform Security Services. This provides a flexible, simple to administer security mechanism. It can be used with standalone Oracle Reports install or any Forms-Reports combination. The policy store and the identity store used for authentication and authorization can be standard JAZN-XML based or any LDAP server, including Oracle Internet Directory through JAZN-LDAP, providing flexibility.
Note:
JAZN-XML is an XML file which is configured by the user to use as an id store and/or policy store.Oracle Reports 11g Release 2 (11.1.2) accomplishes authentication through Single Sign-On, Oracle Internet Directory, Embedded ID Store, and JAZN-XML File-based ID Store. For authorization, Oracle Reports 11g Release 2 (11.1.2) supports Oracle Internet Directory, File-based, and Portal-based methods. In prior releases, Reports Server authentication was restricted to use only Oracle Internet Directory. If you want to revert to the security mechanism of prior releases, you can do so in Oracle Enterprise Manager, as described in Section 6.8.1.1, "Switching to Oracle Portal Security". If you want to use Single Sign-On without implementing data source security or Oracle Portal, refer to Chapter 16, "Configuring and Administering Oracle Single Sign-On".
Alternatively, you might have your own application for launching reports with its own login mechanism and user/group repository, or have your own mechanism for protecting data sources (for example, you might choose to use a different LDAP server to store user and group information). In this case, Oracle Reports Services provides interfaces that allow you to integrate it with these non-Oracle components, as described in Section 14.14, "Security Interfaces".
The previous release of Oracle Reports
Oracle Reports 11g Release 2 (11.1.2) uses Oracle Platform Security Services, enabling a new security mechanism that provides the features and functionality described in Table 14-1 (a subset of Table 1-1, "11g Functionality vs. 10g Functionality"):
Table 14-1 11g Security Features vs. 10g Functionality
| 11g New Features | Equivalent 10g Functionality |
|---|---|
|
A standards-based Java EE security model through Oracle Platform Security Services. This provides a flexible, simple to administer security mechanism. For more information, see Section 14.1, "Introduction to Oracle Reports Security" |
Reports Server authentication restricted to use only Oracle Internet Directory. Authorization of Reports Server required Oracle Portal-based security model (using Portal metadata repository for checking authorization). |
|
Oracle Enterprise Manager advanced user interface. Administrators can use Oracle Enterprise Manager to more easily define and manage granular security policies for reports, directories, Web commands, and read/write access to directories. For more information, see Section 6.8, "Securing Oracle Reports Services" in Chapter 6, "Administering Oracle Reports Services Using Oracle Enterprise Manager" |
Basic UI in Oracle Portal for defining the policies. Hard-coded Web command access to the Oracle Reports seeded roles. Access policies at file (report) level only, not folder level. |
|
Read/write access to directories at Reports Server level. Administrators can control the input folders from which reports can be served and output folders to which the output of reports servers can be pushed. This ensures there is no security vulnerability. For more information, see Section 14.4.6, "Defining Read/Write Access to Directories" |
|
|
Database proxy authentication. Support for database authentication using proxy users:
|
Not Applicable |
|
Security check for distribution destinations. Ability to define security policies for distribution jobs. For example, you can define a security policy that specifies report output may not be burst to |
No security check performed for destinations specified in the distribution XML file. |
|
Security check for system parameters. A security check is performed for all system parameters, including those specified in the report definition as well as on the command line. |
No security check performed for system parameters. |
|
Security auditing. Audit authentication and authorization on the Reports Server. |
|
|
Security for report output from Oracle Forms Services. With no configuration required, support for intermediate-level security even when Oracle Forms Services and Oracle Reports Services are not secured. For more information, see Section 14.11, "Intermediate-level Security for Forms and Reports", Section 16.7, "Oracle Forms Services Security Considerations" and Section 17.8.2, "Generating Random and Non-Sequential Job IDs". |
Anyone is able to see anyone else's report output by "guessing" the job ID based on sequential job ID assignment. |
Oracle Reports Services encompasses functionality for three main areas of security:
Application Security (that is, controlling access to the report application, where users launch report requests)
Resource Security (that is, controlling access to reports and Reports Servers)
Data Source Security (that is, for controlling access to a particular database)
Generally, users must log on to an application or site (for example, your own corporate Web site, Oracle WebCenter) from which they can access and run their reports. This launcher application is typically protected by some sort of login facility, such as OracleAS Single Sign-On. Once they successfully gain entry into the launcher application, resource security takes over and determines which reports and destinations a given user or group may request.
For application security, OracleAS Single Sign-On provides a single point of user log in and, optionally, data source security. In a typical configuration, the user logs on through OracleAS Single Sign-On to gain access to a report application, where they access and run their reports.
Resource security ensures that only authorized users or groups execute a specific report. It also keeps users or groups from accessing particular Reports Servers for the execution of the report. Certain servers might be reserved for a particular group of users, or may simply be inaccessible during certain times for maintenance activities.
Once it is determined that a user has the necessary privileges to execute a given report through the specified Reports Server to the specified destination, then the user's privileges to the data source accessed by the report must be ascertained.
Optionally, or for backward compatibility, you can configure Oracle Portal to provide resource security for reports and Reports Servers out of the box. In a typical configuration, the administrator or developer specifies which users and groups could access which reports and Reports Servers from Oracle Portal.
Data source security defines the users or roles that can access the data within the given data source. A report might access multiple data sources and the current user must have privileges on all of the data sources accessed by the report in order to run it and view the output. The data source administrator (typically a DBA) grants access to data sources. Data source security must be established and in place prior to configuring your reports environment.
You can provide for data source security in two different ways with Oracle Reports Services:
You can associate data source connection information with a Single Sign-On user. When using OracleAS Single Sign-On (OSSO) server, the first time a user attempts to access the data source, Oracle Delegated Administration Services prompts them to create a resource for their data source connection. After the user creates this data source resource, OracleAS Single Sign-On (OSSO) server associates it with the user in Oracle Internet Directory. When using OAM 11g server, the user must create a resource in the OID using batch loading. See Section 16.3.3.2.3, "Batch Loading". For more information about batch loading, see Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.
Once the data source resource is associated with the Single Sign-On user, it becomes part of their Single Sign-On identity and they can access the data source without having to log in to it separately. This method has two key advantages. First, it enables each user to gain access to the data source through their Single Sign-On identity without having to login separately. Second, it enables a single report URL to be used by many users because the data source login information is stored with the user's identity and therefore does not have to be hard coded into the report's URL or a key mapping.
In your report URLs or key mappings, you can code AUTHID for OracleAS Single Sign-On (OSSO) server and the necessary connection parameters (for example, USERID,SSOCONN). This functionality is much the same as it was in previous releases of Oracle Reports Services. For a complete discussion of URL syntax, refer to Section 17.1, "The Reports URL Syntax". For a complete discussion of key mapping, refer to Section 17.13, "Using a Key Map File".
A Credential Store is the repository of security data that certify the authority of entities used by Java 2, JavaEE and ADF applications. Applications can use the credential store, a single, consolidated service provider to store and manage the credentials securely.
A domain includes one credential store. Application-specific credentials are supported and migrated to credentials in the domain credential store when the application is deployed. Thus, all servers and all applications deployed in a domain use a common credential store, the domain credential store.
Oracle Reports 11g Release 2 (11.1.2) uses credential store to store a password as a key. You can also use the credential store to configure database connection information for jobStatusRepository and jobRepository elements.
For example:
Portal password is stored in the reports credential map with key in the following syntax:
"portalpasswd_DomainName_InstanceName"
Note:
You must create credentials under the Reports folder as the server accesses credentials from this folder in CSF.Oracle Platform Security supports the following types of credentials according to the data they contain:
A password Credential encapsulates a user name and a password
A generic credential encapsulates any customized data or arbitrary token, such as a symmetric key.
In Credential Store Framework (CSF), a credential is uniquely identified by a map name and a key name. Typically, the map name corresponds with the name of an application and all credentials with the same map name define a logical group of credentials, such as the credentials used by the application. All map names in a credential store must be distinct. If the credential store is intended to be the repository of X.509 certificates, it is recommended the use of an Oracle Wallet or a Java keystore. The credential store does not allow the storage of end-user digital certificates.
Note:
CSF keys are stored inrwserver.conf and rwservlet.properties file.For more information on how to manage credentials in a domain credential store through Oracle Enterprise Manager, see Section 6.8.8, "Managing Credentials".
For more information about Wallet-Based and LDAP-Based Credential Stores and Configuring the Credential Store, see Oracle Fusion Middleware Security Guide.