Oracle Application Server Reports Services Publishing Reports to the Web 10g (9.0.4) Part Number B10314-01 |
|
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.
This section describes how OracleAS Reports Services security operates to secure access to your reports and the data they include.
OracleAS Reports Services encompasses functionality for three main areas of 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. |
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. |
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:
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. |
Access control for report requests can be maintained with or without 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):
rwservlet
, which then proceeds as described in the previous bullet item.
In this scenario, a report request is sent to a secured Reports Server with Single Sign-On enabled.
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).
rwservlet
or the JSP depending upon whether this report has been set to execute via rwservlet
or a JSP.
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
).
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.
rwservlet
constructs a command line from the URL (and Oracle Internet Directory information if you used SSOCONN
) and passes it to the Reports Server.
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.
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 |
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.
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.
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.
Configuring the Reports Servlet
For more information about the
See Also:
DBAUTH
parameter and the rwservlet.properties
file.
rwservlet
constructs a command line with the necessary information from the previous steps and passes it to the Reports Server.
OracleAS Reports Services can take advantage of the capabilities in OracleAS Single Sign-On, which is part of the Oracle Identity Management infrastructure.
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.
Figure 9-2 provides an overview of the Single Sign-On component architecture.
The components of the Single Sign-On environment include:
The Oracle HTTP Server processes requests from the client browser.
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.
The Reports Server processes client requests, which includes ushering them through authentication and authorization checking, scheduling, caching, and distribution.
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 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.
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".
This section provides an overview of configuration considerations for OracleAS Reports Services.
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.
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:
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.
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"
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:
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:
The tutorial and further information on the RSDK can be found on the Oracle Technology Network.
|
![]() Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|