Publishing Reports to the Web - Downloads - Oracle

About OracleAS Reports Services Security
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
Securing OracleAS Reports Services 9-3