This section introduces security features and concepts in Oracle Reports.
This section discusses the following topics:
In addition to working with Oracle Reports 12c Release (220.127.116.11), you can now run in a Single Sign-on environment using Oracle Access Manager 11g (OAM) as the authentication server. For more information see, Chapter 17, "Configuring and Administering Oracle Single Sign-On".
Oracle Reports 12c Release (18.104.22.168) 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 12c Release (22.214.171.124) accomplishes authentication through Single Sign-On, Oracle Internet Directory, Embedded ID Store, and JAZN-XML File-based ID Store. For authorization, Oracle Reports 12c Release (126.96.36.199) 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 as described in Section 188.8.131.52, "Switching to Oracle Portal Security". If you want to use Single Sign-On without implementing data source security or Oracle Portal, refer to Chapter 17, "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 15.14, "Security Interfaces".
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 OAM 11g server, the user must create a resource in the OID using batch loading. See Section 184.108.40.206.2, "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 18.1, "The Reports URL Syntax". For a complete discussion of key mapping, refer to Section 18.14, "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 12c Release (220.127.116.11) uses credential store to store a password as a key. You can also use the credential store to configure database connection information for
Portal password is stored in the reports credential map with key in the following syntax:
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 in
For more information on how to manage credentials in a domain credential store through Oracle Enterprise Manager, see Section 6.3.8, "Managing Credentials".
For more information about Wallet-Based and LDAP-Based Credential Stores and Configuring the Credential Store, see Securing Applications with Oracle Platform Security Services.