This section describes some of the administrative tasks you may need to perform as you maintain security for Oracle Reports Services.
To take advantage of Single Sign-on out-of-the-box, the SINGLESIGNON parameter in the Oracle Reports Servlet (rwservlet) configuration file (rwservlet.properties) is set to YES, which specifies that you will use OracleAS Single Sign-On to authenticate users. Oracle considers this to be the normal security deployment model and you should set <singlesignon>no</singlesignon> only if you plan to run in a completely custom security configuration.
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.
To enable or disable OracleAS Single Sign-On, see Section 6.3.6, "Enabling and Disabling Single Sign-On".
You can enable JPS-based security, including JAZN-XML authorization. See Chapter 15, "Securing Oracle Reports Services".
To enable or disable security, see Section 6.3.1, "Enabling and Disabling Security and Changing Security Mechanism used".
During Oracle Fusion Middleware installation, you are asked to select an identity store, a policy store, and a credential store. By default, these are file-based stores. After installation, you can change either of these to LDAP-based stores, such as Oracle Internet Directory. See the "Understanding Identities, Policies, Credentials, Keys, Certificates, and Auditing" chapter in Securing Applications with Oracle Platform Security Services.
To enable data source security through Single Sign-On, you must do the following:
Include SSOCONN in the URL that launches the report.
Populate Oracle Internet Directory with data source connection information using one of three methods.
If you wish to implement data source security through Single Sign-On for your own pluggable data sources, you must perform the following additional task:
Add a new resource type to Oracle Internet Directory.
The following sections explain how to perform these operations.
To enable data source security through Single Sign-On, the URL must contain or reference (that is, through the key map file) an Single Sign-On parameter (SSOCONN) with a value of the form:
key_name/data_source_type/conn_string_parameter
key_name maps to a string stored in Oracle Internet Directory that provides the necessary information to connect to the database.
The mapping of the key_name functions differently depending on the authentication server used in the Single Sign-On environment:
Mapping when Oracle Access Manager is used as the authentication server
In this case, when Oracle Reports encounters a key_name, it checks to see if the current user has a corresponding key stored in Oracle Internet Directory. If yes, Oracle Reports uses the string stored in that key to connect to the data source. If not, Oracle Reports checks to see if the key_name maps to a publicly available key and uses that key. Otherwise, Oracle Reports raises a "key does not exist" error message.
See Also:
Section 17.3.3.2, "Populating Oracle Internet Directory" for more information about populating Oracle Internet Directory with resources.data_source_type is the kind of data source to which you are connecting, to identify the format in the string associated with key_name. The data_source_type value must be a valid resource type stored in Oracle Internet Directory. Oracle Reports provides default resource types for the following:
Oracle database (OracleDB)
JDBC PDS (JDBCPDS)
You can also create additional resource types in Oracle Internet Directory for your own pluggable data sources.
conn_string_parameter specifies the Oracle Reports system or user parameter to be used to pass the connection string to Oracle Reports. For example, in the case of the OracleDB data source, Oracle Reports receives the connection string through the USERID parameter and uses it to connect to the specified Oracle database. Similarly, for JDBCPDS, P_JDBCPDS is used. If you have your own custom pluggable data sources, you must define your own user parameter for passing the connection string to Oracle Reports and specify it as conn_string_parameter for SSOCONN.
See Also:
Section A.8.15, "SSOCONN"In the case of an Oracle database, the URL to call a report with SSOCONN would look something like the following:
http://myhost.mycompany.com:7779/reports/rwservlet?server=rs_cped
&report=my.rdf&destype=cache&ssoconn=mykey/OracleDB/userid&desformat=html
In the case of a JDBC data source, the Single Sign-On value would look something like the following:
http://myhost.mycompany.com:7779/reports/rwservlet?server=rs_cped
&report=Jdbcthin.rdf&destype=cache&desformat=html&ssoconn=jd1/jdbcpds/p_jdbcpds
In this case, jd1 is an Oracle Internet Directory resource name.
See Also:
Section 14.1, "Configuring and Using the JDBC PDS" for more information on how to configure a JDBC data source.When you use SSOCONN in a command line, you cannot:
Specify AUTHID in the same command line.
Run against a Reports Server that is not secure.
Have SINGLESIGNON set to NO in rwservlet.properties.
Performing any of these actions with SSOCONN in the command line results in an error.
For data source security to function with Single Sign-On, you must store the data connection information for each user in Oracle Internet Directory or make the resource a default one available to every user. You can populate Oracle Internet Directory with this information in any one of the following ways:
If you prefer to have users enter their own connection string information, you do not have to prepopulate Oracle Internet Directory with data source connection information at all.
In case of OAM as the authentication server, if you use SSOCONN when launching the report 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. You must create a resource using the sample LDIF available on OTN located at http://www.oracle.com/technetwork/middleware/reports/overview/index.html. For more information about creating a resource in OID, see Section 17.3.3.2.2, "Batch Loading".
Note:
Because of this feature, many users can use the same report URL even if they all use different data source connection strings.Resources for Oracle Reports Services are created in Oracle Internet Directory under the following entry:
orclresourcename=resource_name, cn=Resource Access Descriptor, orclownerguid=guid, cn=Extended Properties, cn=OracleContext, dc=us,dc=oracle,dc=comFoot 1
Before You Begin You must create orclownerguid=guid in the Oracle Internet Directory entry before you can proceed with the batch loading of resources. If you used Oracle Delegated Administration Services to create your users, orclownerguid=guid was created automatically and you can proceed to Batch Loading Resources.
If you seeded users into Oracle Internet Directory with an LDIF file, then, before following the steps in Batch Loading Resources, you must complete the following steps:
Get the users' GUIDs.
Depending on how your users are created in Oracle Internet Directory, you can use any number of methods to get their GUIDs. You can get user GUIDs using the Oracle Internet Directory LDAP API. You can also get it using the ldapsearch command:
D:\Oracle\BIN>ldapsearch -h host_name -p port_num -L -D cn=orcladmin -w orcladmin's_password -b "cn=users,dc=us,dc=oracle,dc=com" -s sub "objectclass=*" dn orclguid
Create the user entry orclownerguid=guid under cn=Extended Properties, cn=OracleContext, dc=us, dc=oracle, dc=com.
Modify the sample script, OTN\scripts\createuser.ldif by replacing the place holder with real values.
Load createuser.ldif using ldapadd. For example:
D:\Oracle\BIN>ldapadd -D cn=orcladmin -w welcome1 -h host_name -p port_num -f createuser.ldif
Note:
In the sub-step a, OTN referred to, is located at the Oracle Reports Sampleshttp://www.oracle.com/technetwork/middleware/reports/downloads/index.html.Once you have created orclownerguid=guid, proceed to Batch Loading Resources.
Note:
You can now find sample LDIF in the Oracle Reports page on OTN located athttp://www.oracle.com/technetwork/middleware/reports/overview/index.html.Batch Loading Resources Follow the steps below to batch load data source resources for your users:
Create the user's resource entry orclresourcename=resource_name, cn=Resource Access Descriptor under orclownerguid=guid, cn=Extended Properties, cn=OracleContext, dc=us, dc=oracle, dc=com, where orclownerguid=guid is the GUID created in Before You Begin.
Modify the sample script, C:\Samples\scripts\createresource.ldif by replacing the place holder with real values.
Load createresource.ldif using ldapadd. For example:
D:\Oracle\BIN>ldapadd -D cn=orcladmin -w orcladmin's_password -h host_name -p port_num -f createresource.ldif
Note:
In the sub-step a, the Samples referred to, should be downloaded from OTN locationhttp://www.oracle.com/technetwork/middleware/reports/downloads/index.html and then be placed at local location C:\Samples.As described in Chapter 15, "Securing Oracle Reports Services", Oracle Reports Services must connect to Oracle Internet Directory to verify user privileges and obtain existing data source connection information. In connecting to Oracle Internet Directory, you must consider:
When Oracle Reports Services connects to Oracle Internet Directory, it does so as an application entity. By default, each Oracle Reports Services application entity is unique to its Oracle Fusion Middleware installation. Every Reports Server started from the same Oracle Fusion Middleware installation (that is, ORACLE_HOME) uses the same application entity to connect to Oracle Internet Directory. This setup ensures that each Reports Server can only access information in Oracle Internet Directory that is relevant to its instance of Oracle Fusion Middleware.
For example, suppose you have two instances of Oracle Fusion Middleware, one for your Finance group and one for your Human Resources group. A Reports Server from the Finance group's Oracle Fusion Middleware instance would be prevented from accessing information relevant only to the Human Resources group, and vice versa. Thus, information stored in Oracle Internet Directory is more secure by default.
In previous releases of Oracle Reports Services, all Reports Servers connected to Oracle Internet Directory as the same application entity. As a result, it was not possible to restrict a Reports Server's access to information in Oracle Internet Directory.
To revert to the less restrictive security mode, refer to the Oracle Reports Services chapter of the Oracle Fusion Middleware Release Notes.
By default, the Reports Server is configured to use the Oracle Internet Directory instance installed with Oracle Fusion Middleware. If you are building your system anew, this arrangement is fine. However, if you have an existing Oracle Internet Directory instance that you want to use for the Reports Server, you have to make some adjustments to your configuration.
Changing Oracle Internet Directory instances must be done as part of a complete change of your Oracle Fusion Middleware middle tier. For more information about this process, refer to the chapter on reconfiguring Application Server instances in the Administering Oracle Fusion Middleware.
Footnote Legend
Footnote 1: dc=us,dc=oracle,dc=com is merely an example in this instance. You would normally enter your own values for these items.