9
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

9.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

9.1.1 Resources Protected

OracleAS Reports Services encompasses functionality for three main areas of security:

• Application security (i.e., controlling access to the report application, where users launch report requests)

• Resource security (i.e., controlling access to reports, printers, calendars, and Reports Servers)

• Data source security (i.e., for controlling access to a particular database)

9.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: Configuring OracleAS Reports Services Security For more information on these interfaces.

9.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 via 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: Configuring OracleAS Reports Services Security For more information on these interfaces.

9.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 into 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 (e.g., 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 The Reports URL Syntax. For a complete discussion of key mapping, refer to 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: Configuring OracleAS Reports Services Security For more information on these interfaces.

9.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

9.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 (via the getRemoteUser call) to determine whether the user has already logged on through OracleAS Single Sign-On (i.e., a Single Sign-On cookie exists for the user):

• If the user has logged on already (i.e., the cookie exists), then rwservlet gets the user's identity from the Oracle HTTP Server.

• If the user has not logged on already (i.e., 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.

9.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.

1. If the report is to be run from within OracleAS Portal, 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.

   If the report is not to be run from within OracleAS Portal, the user must somehow have gained access to the URL that launches the report request (e.g., via a link on a Web page or a bookmark).

2. The report request is made via one of the following methods:
   • From within OracleAS Portal, the user requests to run the report object (e.g., clicks the Run link).

   • From outside of OracleAS Portal, the user chooses a link or a bookmark that contains a URL that requests the report.

     Note: The URL may optionally contain or reference (i.e., via 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.

3. The URL redirects the user to either rwservlet or the JSP depending upon whether this report has been set to execute via rwservlet or a JSP.

4. If you used SSOCONN in your URL, rwservlet checks the Single Sign-On key against the Oracle Internet Directory to see if it already has been mapped to a data source connection string (e.g., scott/tiger@my_or_db).

5. If you used SSOCONN and the 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. 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 is displayed and the user must enter their data source connection string. See Figure 9-1. 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.

   Note: Because of this feature, many users can use the same report URL even if they all use different data source connection strings.

Figure 9-1 Oracle Delegated Administration Services Create Resource

Text description of the illustration sec_sso_das.gif

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

7. The Reports Server validates the user credentials against the Oracle Internet Directory server. The 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.

8. The Reports Server delegates the job to a Reports Engine that accesses the data source, retrieves the data, and formats the report.

9. The completed output is sent to the specified destination. Depending upon the destination, the output may be sent to a printer, served back to the browser, or stored in a file for future reference.

9.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 via its own authentication mechanism (identical to the behavior of Oracle Reports6i). Because the HTTP 1.0 protocol is stateless (i.e., 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 option. 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 (e.g., 30 minutes), the cookie is rejected and the user is challenged to provide authentication information.

See Also: Configuring the Reports Servlet For more information about the COOKIEEXPIRE parameter and the rwservlet.properties file.

9.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.

1. The user must somehow gain access to the URL that launches the report request (e.g., via a link on a Web page or a bookmark), and choose the URL.

2. rwservlet checks for the AUTHID parameter on 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 Reports Authid Cookie. (If the report is launched from OracleAS Portal, AUTHID is added to the URL automatically.) If neither AUTHID nor a Reports Authid Cookie is found, rwservlet displays the System Authentication screen, where the user must supply their Single Sign-On username and password. This information is subsequently stored in the Reports Authid Cookie.

3. If only partial data source credentials are provided on the URL (e.g., USERID=scott@orqa), the Database Authentication page is displayed with the partial credentials priming the fields. 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 via the DBAUTH parameter in the rwservlet.properties file. If no data source credentials at all are provided, the Database Authentication page is not displayed and it is assumed the report does not require a data source.

   See Also: Configuring the Reports Servlet For more information about the DBAUTH parameter and the rwservlet.properties file.

4. rwservlet constructs a command line with the necessary information from the previous steps and passes it to the Reports Server.

5. The Reports Server validates the user credentials against the Oracle Internet Directory. It also 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.

6. The data source credentials are stored in a Reports Userid Cookie for possible future reference. Note that Pluggable Data Source credentials are not stored in the Reports Userid Cookies.

7. The Reports Server delegates the job to a Reports Engine that accesses the data source, retrieves the data, and formats the report.

8. The completed output is sent to the specified destination. Depending upon the destination, the output may be sent to a printer, served back to the browser, or stored in a file for future reference.

9.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.

9.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.

9.1.3.1.1 Single Sign-On Components

Figure 9-2 provides an overview of the Single Sign-On component architecture.

Figure 9-2 SSO Architecture

Text description of the illustration sec_ssoarch.gif

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 the 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 the Oracle Internet Directory for user and group privilege information. It also retrieves data source connection information from the Oracle Internet Directory.

• Oracle Delegated Administration Services

  The Delegated Administration Service provides a comprehensive interface for making updates to the 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 the Oracle Internet Directory.

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

9.2 Configuring OracleAS Reports Services Security

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

9.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 Resources Protected pre configured to work with your OracleAS Reports Services installation. If you choose to implement your own security configuration, you can follow the steps in Chapter 10, "Configuring and Administering OracleAS Single Sign-On" and Chapter 11, "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 the above security components, you can still configure a secured Reports Server, which provides security similar to that available in Oracle Reports6i.

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.

9.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 via 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: OracleAS Portal For a detailed description of report request flow within OracleAS Portal.

Refer to the Oracle Application Server 10g 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://otn.oracle.com).

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

9.2.1.2 Security Interfaces

The Security API of the Reports Software Development Kit (RSDK) allows 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

The tutorial and further information on the RSDK can be found on the Oracle Technology Network.