10 Securing OracleAS Reports Services

The celebrated openness of the Internet brings with it concerns about controlling who has access to what confidential company information. OracleAS Reports Services provides a number of security options that enable you to ensure that the appropriate users are getting important data in a secure fashion. This chapter provides an overview of the available security options.

About OracleAS Reports Services Security
Configuring OracleAS Reports Services Security

10.1 About OracleAS Reports Services Security

This section describes how OracleAS Reports Services security operates to secure access to your reports and the data they include.

Resources Protected
Authorization and Access Enforcement
Leveraging Oracle Identity Management Infrastructure

10.1.1 Resources Protected

OracleAS 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, printers, calendars, and Reports Servers)
Data source security (that is, for controlling access to a particular database)

10.1.1.1 Application Security

Typically, users must log on to an application or site 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 login and, optionally, data source security. In a typical configuration, the user would log on through OracleAS Single Sign-On to gain access to a report application, where they would access and run their reports.

Oracle Internet Directory stores user and group privilege information which is used by OracleAS Single Sign-On. Oracle Internet Directory also stores data source security information on a per user basis. Oracle Delegated Administration Services edits the information stored in Oracle Internet Directory. Oracle Delegated Administration Services can be accessed from within OracleAS Portal or separately, as a standalone component.

Alternatively, you might have your own application for launching reports with its own login mechanism and user/group repository. In this case, OracleAS Reports Services provides interfaces that allow you to integrate it with these non-Oracle components.

See Also:

Section 10.2, "Configuring OracleAS Reports Services Security" for more information on these interfaces.

10.1.1.2 Resource Security

Resource security ensures that only authorized users or groups execute a specific report. It also keeps users or groups from accessing particular printers or Reports Servers for the execution of the report. You might well imagine a situation where certain printers and servers might be reserved for a particular group of users. Alternatively, some printers and servers 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.

OracleAS Portal provides resource security for reports, printers, calendars, and Reports Servers out of the box. In a typical configuration, the administrator or developer could specify which users and groups could access which reports, Reports Servers, and printers from OracleAS Portal.

As with application security, you might have your own mechanism for protecting resources. In this case, OracleAS Reports Services provides interfaces that allow you to integrate it with these non-Oracle components.

See Also:

Section 10.2, "Configuring OracleAS Reports Services Security" for more information on these interfaces.

10.1.1.3 Data Source Security

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 OracleAS Reports Services:

You can associate data source connection information with a Single Sign-On user. In this case, 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 associates it with the user in 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 and the necessary connection parameters (for example, USERID) for your report. This functionality is much the same as it was in previous releases of OracleAS Reports Services. For a complete discussion of URL syntax, refer to Section 13.1, "The Reports URL Syntax". For a complete discussion of key mapping, refer to Section 13.12, "Using a Key Map File".

As with the other security areas, you might have your own mechanism for protecting data sources. In this case, OracleAS Reports Services provides interfaces that allow you to integrate it with these non-Oracle components.

See Also:

Section 10.2, "Configuring OracleAS Reports Services Security" for more information on these interfaces.

10.1.2 Authorization and Access Enforcement

Access control for report requests can be maintained with or without OracleAS Single Sign-On.

Handling Report Requests with OracleAS Single Sign-On
Handling Report Requests without OracleAS Single Sign-On

10.1.2.1 Handling Report Requests with OracleAS Single Sign-On

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.

Note:

If the report request is launched from within OracleAS Portal rather than rwservlet, OracleAS Reports Services will similarly validate the user's privileges on the report before running it. Even for unauthenticated (PUBLIC) users viewing public pages, OracleAS Reports Services verifies that the PUBLIC user account has appropriate privileges on the report.

10.1.2.1.1 Report Request Flow with Single Sign-On

In this scenario, a report request is sent to a secured Reports Server with Single Sign-On enabled. The report request goes through two levels of security checks: authentication, as shown in Figure 10-1, and authorization, as shown in Figure 10-3.

Figure 10-1 Authentication Process with SSO

Description of "Figure 10-1 Authentication Process with SSO"

The following numbered steps map to the numbers in Figure 10-1:

User requests the report (through a URL).

The report request is made through one of the following methods:

From within OracleAS Portal, the user requests to run the report object (for example, clicks the Run link). The user must be logged into OracleAS Portal and, consequently, OracleAS Single Sign-On. As part of its security, OracleAS 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, OracleAS Portal will not display the page or the report object to the user.

From outside OracleAS Portal, 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.

Oracle HTTP Server routes the request to rwservlet deployed on OC4J.

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 10-2.

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 10-2 Oracle Delegated Administration Services Create Resource

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

Once the user is authenticated, the report request must go through the authorization process, as shown in Figure 10-3.

Figure 10-3 Authorization Process with SSO

Description of "Figure 10-3 Authorization Process with SSO"

The following numbered steps map to the numbers in Figure 10-3:

rwservlet forwards the request to Reports Server.

rwservlet constructs a command line from the URL (and Oracle Internet Directory information if you used SSOCONN) and passes it to Reports Server.

Reports Server validates the user privileges against the OracleAS Portal schema in OracleAS Metadata Repository.

Reports Server checks whether the user has the necessary privileges to run the report on the specified server at the specified time to the specified destination. If the validation check fails for any reason, then an error condition is returned to the user and the process terminates.

Note:

If the user is executing rwservlet Web commands such as showjobs and getserverinfo, instead of executing a report, Reports Server validates the user credentials with Oracle Internet Directory. Reports Server verifies that the user has administrative privileges to run the rwservlet Web commands. For more information on controlling access to reports in OracleAS Portal, see Section 12.1, "Creating Reports Users and Named Groups"

Reports Server executes the report request and passes the report output to rwservlet.

Reports Server delegates the job to an engine that accesses the data source, retrieves the data, and formats the report.
Report output is passed to Oracle HTTP Server.
Report output is passed to the user.

The completed output is sent to the specified destination. Depending upon the destination, the output may be served back to the browser (as shown in Figure 10-3), sent to a printer, stored in a file for future reference, sent to an FTP server, and so on.

10.1.2.2 Handling Report Requests without OracleAS Single Sign-On

If Single Sign-On is not being used, then any user accessing a secured instance of the Reports Server is challenged to identify themselves by rwservlet through its own authentication mechanism (identical to the behavior of Oracle Reports 6i). Because the HTTP 1.0 protocol is stateless (that is, each call to the server is effectively independent of all others), users might need 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 ORACLE_HOME\reports\conf. %S forces users to enter their username and password each time the report is called.

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 in the rwservlet.properties file. 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 3.4, "Configuring Reports Servlet" for more information about the COOKIEEXPIRE parameter and the rwservlet.properties file.

10.1.2.2.1 Report Request Flow without OracleAS Single Sign-On

In this scenario, the report request is sent to a secured Reports Server with Single Sign-On disabled. In this case, rwservlet or a JSP report might be called through the use of a bookmark or from an OracleAS Portal component. The report request goes through two levels of security checks: authentication, as shown in Figure 10-4, and authorization, as shown in Figure 10-5.

Figure 10-4 Authentication Process without SSO

Description of "Figure 10-4 Authentication Process without SSO"

The following numbered steps map to the numbers in Figure 10-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 OC4J.
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 OracleAS 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 Single Sign-On 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 3.4, "Configuring Reports Servlet" 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) with Oracle Internet Directory.

Reports Server validates the user credentials against Oracle Internet Directory. If the validation check fails for any reason, then an error condition is returned to the user and the process terminates.

Once the user is authenticated, the report request must go through the authorization process, as shown in Figure 10-5.

Figure 10-5 Authorization Process without SSO

Description of "Figure 10-5 Authorization Process without SSO"

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

Reports Server validates the user privileges against the OracleAS Portal schema in OracleAS Metadata Repository.

Note:

If the user is authorized to execute the report, Reports Server executes the report request and passes the report output to rwservlet.

Reports Server delegates the job to an engine that accesses the data source, retrieves the data, and formats the report.
Report output is passed to Oracle HTTP Server.
Report output is passed to the user.

The completed output is sent to the specified destination. Depending upon the destination, the output may be served back to the browser (as shown in Figure 10-5), sent to a printer, stored in a file for future reference, sent to an FTP server, and so on.

10.1.3 Leveraging Oracle Identity Management Infrastructure

OracleAS Reports Services can take advantage of the capabilities in OracleAS Single Sign-On, which is part of the Oracle Identity Management infrastructure.

10.1.3.1 OracleAS Single Sign-On

With the increasing number of Web-based, e-business applications that companies deploy for use by their employees, customers, and partners, many businesses must now consider Single Sign-On functionality. Single Sign-On refers to the ability to log on to a single security system once, rather than logging on separately to multiple security systems. With Single Sign-On, each user maintains a single identity and password for all data and associated resources to which they need access.

Within a given Web application, OracleAS Reports Services eases the user's experience with OracleAS Single Sign-On. OracleAS Single Sign-On ensures that each user authenticates only once.

10.1.3.1.1 Single Sign-On Components

Figure 10-6 provides an overview of the Single Sign-On component architecture.

Figure 10-6 SSO Architecture

Description of "Figure 10-6 SSO Architecture"

The components of the Single Sign-On environment include:

A client Web browser
Oracle HTTP Server

The Oracle HTTP Server processes requests from the client browser.
Reports Servlet
Oracle Application Server Containers for J2EE

The Reports Servlet is a component of OracleAS Reports Services that runs inside of the Oracle HTTP Server's Oracle Application Server Containers for J2EE (OC4J). When a report request comes to the Oracle HTTP Server, the Reports Servlet passes the job request to the Reports Server.
Reports Server

The Reports Server processes client requests, which includes ushering them through authentication and authorization checking, scheduling, caching, and distribution.
OracleAS Single Sign-On

OracleAS Single Sign-On is responsible for managing users' Single Sign-On sessions. It verifies users' login credentials by looking them up in Oracle Internet Directory.
Oracle Internet Directory

Oracle Internet Directory is Oracle's highly scalable, native LDAP version 3 service and hosts the Oracle common user identity. OracleAS Single Sign-On authenticates users against the information stored in Oracle Internet Directory. As noted in earlier sections, when Single Sign-On is enabled for OracleAS Reports Services, it checks Oracle Internet Directory for user and group privilege information. It also retrieves data source connection information from Oracle Internet Directory.
Oracle Delegated Administration Services

The Delegated Administration Service provides a comprehensive interface for making updates to Oracle Internet Directory. OracleAS Reports Services displays Oracle Delegated Administration Services when it encounters a Single Sign-On key that does not already have a data source connection string associated with it in Oracle Internet Directory.

For more information, refer to Chapter 11, "Configuring and Administering OracleAS Single Sign-On".

10.2 Configuring OracleAS Reports Services Security

This section provides an overview of configuration considerations for OracleAS Reports Services.

10.2.1 Configuring OracleAS Reports Services Security Options

The out-of-the-box implementation of OracleAS Reports Services security includes all of the Oracle components described in Section 10.1.1, "Resources Protected" preconfigured to work with your OracleAS Reports Services installation. If you choose to implement your own security configuration, you can follow the steps in Chapter 11, "Configuring and Administering OracleAS Single Sign-On" and Chapter 12, "Deploying Reports in OracleAS Portal" to use all or only some of these components. For example, you can choose to use OracleAS Single Sign-On without implementing data source security or OracleAS Portal. In another configuration, you might choose to use a different Internet directory to store user and group information. If you prefer to implement none of these security components, you can still configure a secured Reports Server, which provides security similar to that available in Oracle6i Reports.

Note:

At the highest level, all communication to and from Oracle HTTP Server may be configured to use SSL. The Oracle HTTP Server incorporates an OpenSSL module to provide support for Secure Sockets Layer (SSL) and HTTP Secure Sockets Layer (HTTPS). Once this is set up in the Oracle HTTP Server (see Oracle HTTP Server Administrator's Guide), rwservlet automatically detects the SSL port number.

10.2.1.1 OracleAS Portal

OracleAS Portal provides a number of security features available to OracleAS Reports Services that enable you to ensure that the appropriate users are getting important data in a secure fashion. With OracleAS Portal security features in place, your users see only the data they're supposed to see.

Use OracleAS Portal to control:

Who has access to each report
When a report can be run
Which servers and printers can be used to run a report
Which report parameters a user can edit with what range of values

OracleAS Portal is a browser-based, data publishing and developing solution that offers Web-based tools for publishing information on the Web and building Web-based, data-driven applications.

OracleAS Portal is tightly integrated with OracleAS Reports Services to create a robust and secure data publishing environment. OracleAS Portal provides easy-to-use wizards for setting up OracleAS Reports Services security. These include wizards for defining user access to reports, Reports Servers, printers, output formats, and report parameters.

Once you define access control information, it's stored in the OracleAS Portal repository. As an OracleAS Portal user, you can then, optionally, publish registered RDFs and JSPs to an OracleAS Portal page. As with all OracleAS Portal functionality, using Portal to deliver your reports is not required. You can deliver reports through command lines, as you may always have, and still benefit from the access control features available to you through OracleAS Portal.

Access to OracleAS Reports Services' security features is not dependent on whether you also use Portal to publish report links or report content. Even if you don't publish through Portal, you can still take advantage of the OracleAS Reports Services' security features available in OracleAS Portal to control user access to all of your reports.

When you expose a report as a portlet through OracleAS Portal, OracleAS Reports Services leverages the Single Sign-On feature. Single Sign-On eliminates the need for users to enter multiple logins, first to the portal then to each of the reports exposed through portlets within the portal. With OracleAS Single Sign-On, when you log in, OracleAS Portal automatically logs you into all registered portlet providers and subsystems.

See Also:

Section 10.2.1.1, "OracleAS Portal" for a detailed description of report request flow within OracleAS Portal.

Refer to the Oracle Application Server Security Guide for more information about OracleAS Single Sign-On and OracleAS Portal. You'll find this and other related documentation on the Oracle Technology Network, (http://www.oracle.com/technology/index.html).

For more information, refer to Chapter 12, "Deploying Reports in OracleAS Portal".

10.2.1.2 Security Interfaces

The Security API of the Reports Software Development Kit (RSDK) enables you to integrate your own security model with the Reports Server. OracleAS Reports Services enables you to plug in any security you wish, using the provided API.

The Security API can control:

Who has access to each report
When a report can be run
Which servers and printers can be used to run a report
Which report parameters a user can edit with what range of values

The RSDK includes a tutorial that shows you how to integrate your own security using an XML file to store the authorization information. At the end of this tutorial, you will be able to:

Implement a security class with OracleAS Reports Services
Register a security class with OracleAS Reports Services
Use the security class with OracleAS Reports Services

For the tutorial and more information, refer to the Reports Software Development Kit (RSDK) on the Oracle Technology Network (OTN): on the Oracle Reports 10g page (http://www.oracle.com/technology/products/reports/index.html), click SDK.