Beruflich Dokumente
Kultur Dokumente
INTRODUCTION
The benefit of Internet Computing, that is universally accessible information, is also one of the greatest causes of concern for those whose job it is to administer the web site. That is, the web site must scale to meet the requirements of the increased user community and also ensure that only those authorized to see the information can do so. User satisfaction for a web site is determined not only by the information served, but also by the speed at which it is delivered. If the site is unable to serve information in a timely manner due to increased load, users are less likely to use the site. Therefore it is extremely important that the underlying architecture scales to meet the user expectations. In addition, it is often the case that user authorization is defined not only by the privileges on the data itself (that is, database object level privilege) but also the functions performed on it. As access to a web document is through the use of its Uniform Resource Locator (URL), knowledge of the URL allows access to any unprotected document. To combat this, most web servers allow for the securing of the directory in which the documents may be found but are unable to secure individual files within that directory. The use of CGI executables to serve up dynamic pages has allowed many organizations to personalize the users view of the available information. These complex CGI coding techniques have not really addressed the issue of application-level security. Hence, it has been difficult for most web sites or information Portals to implement much more than the most rudimentary of security models. This paper focuses on the security and scaleability issues faced by system administrators when implementing a centralized reporting infrastructure. Specifically, it looks at the functionality available within the Oracle Reports Server to address these issues, and indicates the tasks required to implement it. It does not cover the design of the Reports Server and assumes a basic understanding of the architecture and the methods required to implement it. Note: For further information on the Oracle Reports Server please refer to the white paper Enterprise Reporting available from http://www.oracle.com.
FUNCTIONAL SECURITY
In its simplest form, an authorization scheme designed to enforce application level security (one based on the right of the user to access the function as well as the data) should allow for the definition of the following criteria:
Advanced Techniques for the Oracle Reports Server March 2000 2
Who has the appropriate privileges to access the defined function or object. What business functions and objects are available to be accessed. When may the defined function or object be accessed. That is, is the availability determined by either organizational or procedural controls (e.g. only available during business hours or after the close of books in a financial period). How may the function be implemented by the user. That is, given the authorization to access given function a user may only specify certain parameters to that function (e.g. may only specify output formats or printers).
NOTE: Application users are currently authenticated as a user defined within the database, future releases of WebDB, however, will allow for the authentication of users in a number of different ways, from a lightweight authentication model to use of external sources, such as an LDAP server.
In order to implement the Secure Reports Server it is first necessary to perform a number of steps prior to the definition of the security model itself.
1. The definitions held within the WebDB repository which relate to the running of secured Oracle Reports are an extension to the standard WebDB installation. As such, it is necessary to insert the required object definitions and related menu structure into the Administration area of the WebDB application environment. This is achieved by running the supplied installation script (%ORACLE_HOME%\Reports60\Server\Security\RWWWVINS) within the same schema that was used to install WebDB itself. The script will create the appropriate Object definitions and menu entries as well as define the RW_BASIC_USER, RW_DEVELOPER, and RW_ADMINISTRATOR roles.
NOTE: In order to define Reports access security via the Oracle Reports Security Wizards within Oracle WebDB the user must be granted the RW_ADMINISTRATOR role (otherwise Reports Security Option will not appear as the user menu structure). In addition the user must have BUILD IN privileges to any schema that will own the Reports Packaged Procedure or List of Values used within a parameter form.
1. The Reports Server must know where to look in order to find access privilege information. That is the server must be told the name of the database instance in which WebDB and the security repository have been installed. It is necessary to:
1.1 Add an alias in the TNSNAMES.ORA file on the machine where the Reports Server is located which points to the instance where WebDB is installed. 1.2 Add an entry SECURITYTNSNAME=<tnsname alias> in the Reports Server configuration file (e.g. RepServer.ora) which references the alias to the WebDB SID.
Once the SECURITYTNSNAME entry has been added to the servers configuration file (and the Reports Server restarted) access control will be enforced. Users who request a report run against this server will be challenged and required to identify themselves for subsequent authentication. Once the WebDB integration has been installed and the Report Server started as a secure server it is possible to define the required access security model. From the Oracle Reports Security page (linked to the WebDB Administer page), it is possible to define the objects which define the criteria of the security model.
What: As a given report may reside on more than one Reports Server the definition of a users access privileges must go beyond the report itself to include the available hardware on which that report may be executed/output. For example, a given report resides on both the central Reports Server and the one used by senior management. Even though a given user may have the right to run the report, he/she should be prevented from executing it on the management server. execution of a report. As such, the Oracle Reports Security allows for the securing of a number of different objects relating to the
Printer Access:
What local or network printers are available. Who has the appropriate privileges to use a given printer. When is this printer available for printing reports.
Servers Access:
What Report Servers have been registered within the WebDB repository and hence are available to accept job requests. What Printers are available on a given Reports Server. Who has the appropriate privileges to submit job requests to a given Reports Server. When is a given Reports Server available to accept job requests. What is the URL required to call a given server via the Web. Can a given Reports Server run any available report or only those registered with WebDB that have secure access control.
When: It is often the case that a users ability to access a report, server, or printer is determined by the point in time the job was submitted to execute. With the universal access afforded by the web, the simple physical security of not being able to access the appropriate hardware (PC, Printer etc.) outside of a defined time period is removed, hence the need to define an availability window as part of the report/object definition becomes paramount. For example, it has been decided that a given report may only be accessed during standard business hours. By applying an availability calendar which defines standard business hours employees would not be able to log-in from home after hours and access the report. The secure Oracle Reports Server supports the ability to define availability calendars for either:
The individual report. The Reports Server on which jobs may be executed. The printers to which the report output may be sent.
6
In all cases, the availability calendar determines when the specific object is accessible for processing. There are two different availability calendar types, simple and combined.
Simple: An availability calendar based on a single rule (e.g., between 9:00am and 5:00pm daily). Combined: A compound availability calendar determined from the addition of two or more simple calendars. The definition of a combined calendar supports both the inclusion and exclusion of the time periods specified within included simple calendars. That is, the combined availability calendar may be defined as
Availability := (Sum of all included Calendars) - (Sum of all excluded Calendars) For example, to define a standard business hours availability calendar, it would first be necessary to create two simple calendars to be included/excluded as follows; 1. 2. 9:00am - 5:00pm repeat every day. (Include) Saturday/Sunday repeat every week. (Exclude)
The resultant availability calendar would only allow access during the period of 9am to 5pm, Monday to Friday.
Note: combined availability calendars can also include/exclude other combined calendars. Hence it is possible to create complex calendar definitions from a hierarchy of both simple and complex calendars. Only one availability calendar can be applied to a given secured Reports Server object (i.e., report definition, server or printer). Hence, if more complex time frames are required, it is necessary to build a single combined calendar (through the addition or exclusions of simpler calendars), which reflects the desired time period.
Include
Exclude
Rule:
How: It is often important not only to specify which report a user may access (and when) but also how that user may interact with the report. The secure Reports Server achieves this by restricting the report request options (i.e. required and optional report parameters), which are exposed to a given user at job submission. By specifying which parameters are exposed, the administrator can allow different users or groups to apply different options to the same physical report definition file. For example, a given report may limit not only the server and printers to which it may be run but also the possible values for DESTYPE and DESFORMAT. In this case, the administrator wants to restrict the report to Web viewing only, hence DESTYPE will be fixed at CACHE and the possible options for DESFORMAT limited to HTML and HTMLCSS.
To solve this issue, and to allow a user to authenticate only once, the report makes use of client side cookies to store the required authentication information within the browser for the current session. Once the user is authenticated, an encrypted cookie is created in the browser allowing for multiple report jobs to be submitted without the need to re-authenticate at each request.
NOTE: If there is a requirement to force a re-authentication on the submission of a given report, use the SHOWAUTH and AUTHTYPE command line arguments or include a %D in the respective report entry in the keymap file (use of %D will force the user to re-enter their username and password each time the report is called) . It is often the case that within a given Web site that users will access reports which run against multiple instances of the Oracle database (or ODBC data sources). To minimize the number of times a user must authenticate themselves (once to each different server), multiple encrypted cookies are created. Each cookie is keyed to the SID used in the connection string. If a report s submitted using the place holder $<username> in conjunction with a SQL*Net80 i database alias, a separate cookie will being created in the browser for each referenced SID.
For example the following keymap file entries
REP1: Report=Rep1.rdf userid=$username@ORCL Destype=CACHE Desformat=HTML REP2: Report=Rep2.ref userid=$username@PROD Destype=CACHE Desformat=HTML
would result in the user being authenticated against the two different servers and two encrypted cookies being created in the browser. One for ORCL and one for PROD.
With any subsequent request for either server the User name and Password will be retrieved from the appropriate cookie and used to authenticate the user against that server.
If no connect string is defined in the command line (i.e. either no USERID is defined or no SQL*Net80 alias is specified), the Oracle Reports CGI executable will use the last database connect string which achieved a successful connection. This value is stored in a separate cookie within the client browser ("lastdbid"). The cookies will be removed if the user closes the browser session, but it is also important to limit the lifetime of the cookie within a given session. For example, a user may have logged on then gone off to lunch leaving the browser session open! To control this type of security breach the
Advanced Techniques for the Oracle Reports Server March 2000 9
administrator may define the REPORTS60_COOKIE_EXPIRE environment variable on the server. When the Oracle Reports CGI executable (or OWS cartridge) receives a job request from the client it will compare the tme saved in the cookie with the current system time. If the time is i longer than the number of minutes defined in the environment variable (e.g., 30 minutes), the cookie is rejected and the user again challenged to identify themselves for authentication.
REPORTS60_DB_AUTH
REPORTS60_ENCRYPTION_KEY
10
REPORTS PROFILE
The Reports Profile option, when set, produces a log file that gives accurate figures as to where the report spent its processing time. To set the profile option, use the PROFILE=<filename> command line argument, where <filename> is the name of the required log file. A typical profile is shown below:
+------------------------------+ | Reports Profiler statistics | +------------------------------+
29.00 seconds 24.00 seconds (82.75% of TOTAL) 5.00 seconds (17.24% of TOTAL) 1.00 seconds 4.00 seconds
11
From the profile it is possible to see the total execution time for the report, the amount of time that was spent formatting the retrieved data (Reports Time), and the amount of time spent waiting for the data to be retrieved (ORACLE Time). UPI time is the time spent establishing the database connection, and parsing and executing the SQL, whilst the SQL time is the time spent performing the RDBMS fetches and execution of SRW.DO_SQL() statements. Note: From initial internal testing within the Oracle Tools Division it was found that the number of Runtime engines which could be supported by a given CPU was as follows;
Format Intensive reporting: 2 Engines per available CPU Data Intensive Reporting: 4 Engines per available CPU
12
Time
# Reports Engines
By registering individual Reports Servers into a cluster (maintained through a master server), they are able to act as a single logical, but distributed, reporting engine. As jobs are submitted to the Reports Server they are automatically re-routed to an available engine running on any machine within the cluster. In this manner, if the reporting needs of the user base is such that performance is degrading, it is simply a matter of defining a new machine to the cluster, to further extend the available processing power. As machines are added to the cluster the Reports Server will automatically recognize their existence and start to issue job requests to them. Conversely, if one of the machines becomes unavailable (due to failure or shutdown) the server will automatically cease to issue requests to that specific machine. The automatic Plug-n-play nature of an Oracle Reports Server cluster means that scaleabilty is limited by the total number of available machines, and not by the processing power of any one computer.
Note: It is possible for a slave server to be a fully functional Reports Server in its own right. That is, it may start and own its own runtime engines independent of the Master server. In this case, any job submission would be to the slave server directly rather than the master and would be local to that server. That is, the master server would be unaware of any direct requests to the slave and hence would be unable to either check for a duplicate request or use any cached output.
Advanced Techniques for the Oracle Reports Server March 2000 13
All servers in the cluster must be able to share a file system such that the reporting engines on each slave are able to write their output to a centralized cache. A central cache ensures that the master server is able to serve duplicate job requests, both current and those within tolerance, regardless of the server on which a job request was processed.
Note: A further benefit of a shared file system is the use of a centralized source directory which would eliminate the need to copy the report definition files to each slave server. Reports Servers within a cluster communicate via SQL*Net80 and as such each individual server must have an entry in their tnsnames.ora which refers to any server with which it will need to communicate. That is, each slave must have an entry referencing the master server and vice versa. The following examples show the tnsnames.ora file for both master and slave servers. Master Server (RepServ)
RepServ.world = (Address=(Protocol=TCP)(Host=RepServ)(Port=1949))
RepSlave1.world = (Address=(Protocol=TCP)(Host=RepServ)(Port=1949))
RepSlave2.world = (Address=(Protocol=TCP)(Host=RepServ)(Port=1949))
RepServ.world = (Address=(Protocol=TCP)(Host=RepServ)(Port=1949))
RepSlave2.world =
Advanced Techniques for the Oracle Reports Server March 2000 14
(Address=(Protocol=TCP)(Host=RepServ)(Port=1949))
When the master server is started, it evaluates the value of the CLUSTERCONFIG parameter within its own configuration file. From this parameter it is able to determine which remote Reports Servers are slaves and how many engines are to be started on each. Master Server Configuration File (RepServ.ora)
MaxConnect=4096 SourceDir=P:\Rep60\Source CacheDir=P:\Rep60\Cache CacheSize=50 MinEngine=1 MaxEngine=4 InitEngine=4 MaxIdle=60 EngLife=50 ClusterConfig=(RepSlave1 MinEngine=1 MaxEngine=2 InitEngine=2 CacheDir=M:\ReportsCache) (RepSlave2 MinEngine=1 MaxEngine=3 InitEngine=3 CacheDir=/Shared/Cache)
In this example the master server would start two engines on the slave server RepSlave1 , and three on RepSlave2. The MinEngine and MaxEngine parameters within the ClusterConfig would specify the minimum and maximum number of engines the server should control on each of the respective slave Reports Servers. It is not necessary that each slave server see the shared cache directory by the same name, nor do they have to be based on the same operating system. As long as each can write to the shared drive.
Note: To allow more even distribution of load across the available servers, it is important to have both the maximum allowable idle time and engine life be consistent across all runtime engines. As such, the values of MAXIDLE and ENGLIFE defined for the master servers engines are implied for all slave engines.
15
Communication is now directly to the runtime engines, rather than through the slave server. The master only contacts the slave if there is the requirement to spawn further engines on that machine. If the master cannot communicate with one or more of the slaves defined in the list, they will be assumed to be off line, and hence unable to accept job submissions. In this case, the round-robin based job assignment will jump over this server and send the request to the next one that is in the list of active servers. In order for the master server to determine when new cluster members have become available, it explicitly polls for those machines that are in the cluster definition but not in its list of active servers. Note: The polling interval is approximately every five seconds. However, polling only takes place during the times when the server is in an idle state, i.e., when there have been no job submission for the previous five seconds. Once the slave indicates it is available (i.e. the server is now up), the master will automatically add it to its list of active servers, obtain control of the appropriate number of runtime engines, and start issuing submissions to be executed on that platform . The master server also maintains a connection to all slaves in its active list. If a given slave server was to go down for some reason, this connection would be broken and hence the master would remove it from the active list of servers. following will result:
1. If the slave Reports Server process dies, the runtime engines controlled by the master are still available. In this case, job submissions would continue until the currently spawned engines are either saturated or they expire through idle time or engine life. No new engines can be spawned, hence if all the current engines are processing reports, this server will be skipped in the roundrobin.
16
2. The entire machine is taken off line, no runtime engines are available. With the connections to both slave server and runtime engines broken, the master would skip this machine until it was notified (via poll) that the slave node was once again available to receive job requests.
ClusterConfig=(RepSlave1) (RepSlave2)
RepServ (Master)
Runtime Engine
Runtime Engine
Runtime Engine
Runtime Engine
RepSlave1
Runtime Engine
RepSlave2
Runtime Engine
Runtime Engine
RepSlave1 - OnLine
RepSlave2 - OffLine
Once the cluster has been defined, the actual nodes may be added or removed at any time and the Reports Server will adjust accordingly. In a master/slave hierarchy the failure of the master node can result in the breakdown of the cluster structure (though each slave server may still act independently). If a high availability solution is required, the Oracle Reports Server tightly integrates with Oracle Fail-safe to allow for the automatic switching of the master server if it should go down. In this manner the Reports Server may not only scale to the required number of users but also support a 24x7 environment. Note: information on Oracle FailSafe may be found on the Oracle web site (http://www.oracle.com)
17
The Oracle Reports Server makes it possible to answer both of these questions, by posting the current Report queue to the database each time a job request is submitted. This information is inserted into a table RW_SERVER_QUEUE and includes such data as:
The name of the Job Who submitted it What output format was chosen The jobs current status When it was queued, started, and subsequently finished
(See appendix for description of the RW_SERVER_QUEUE table structure.) By granting users SELECT access to this, they may query the job submission of interest and determine its current status. In the same manner it is possible to implement a Reports Server Queue screen directly within the Web site itself simply by creating a report based directly on this table. In this case the queue report itself would appear as a job submission by the user!
Note: For Oracle Forms based applications the basing of a block against the RW_SERVER_QUEUE table would allow users to track their reports without the need to leave the forms environment or resort to use of the Web.Show_Document built-in. Conversely, the real time update of the table with the status of jobs submissions makes it very easy for administrators to know exactly how many concurrent users have requested jobs to be executed on the Reports server. By counting the number of entries in the RW_SERVER_QUEUE table which have a status code indicating that the job has been queued but not completed, it is possible to return an accurate number of the current active users on the server.
E.g. SELECT Count(*) FROM RW_SERVER_QUEUE WHERE STATUS_CODE IN (1, -- ENQUEUED 2, -- OPENING 3 -- RUNNING) AND JOB_TYPE != Scheduled
18
Note: Whereas the table contains the date and time a report was Queued, Run, and subsequently Finished, it is not a good idea to use a query based on the that fact that a job has a defined QUEUED and STARTED time but no FINISHED value. If a report terminates due to an unexpected error, such as an invalid input, the FINISHED column will remain NULL, however, the STATUS_CODE and STATUS_MESSAGE will both indicate that there has been a failure and the cause thereof. (See appendix for definition of available status codes.)
When the server starts it will connect as the defined user, clear out the queue table and begin to log job submissions. Note: If the Reports Server and Oracle RDBMS have been installed on a single stand-alone Windows-NT machine, the definition of REPOSITORYCONN may prevent the automatic startup of the Reports Server service as NT boots. This is due to the fact that the Oracle RDBMS service may yet to have started, thus preventing the Reports Server from performing the required login. Once the RDBMS has started, the Reports Server Service may be started manually.
CONCLUSION
The move to a centralized reporting infrastructure based on Internet Computing, allows organizations to both minimize their costs and maximize access to information. It does, however, introduce issues which till now have made many system administrators reticent to adopt the new paradigm, i.e., the security implications of a Web-based solution and the need to scale to a larger user community.
19
Oracle Reports, in conjunction with Oracle WebDB, answers these issues by allowing for the implementation of both a scaleable, clustered environment and user authentication and access control.
20
APPENDIX
REPEAT_INTERVAL Frequency on which to execute a job REPEAT_PATTERN Repeat pattern (every minute, hour, day, etc.)
21
22
Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: +1.650.506.7000 Fax +1.650.506.7200 http://www.oracle.com/ Copyright Oracle Corporation 1999 All Rights Reserved This document is provided for informational purposes only, and the information herein is subject to change without notice. Please report any errors herein to Oracle Corporation. Oracle Corporation does not provide any warranties covering and specifically disclaims any liability in connection with this document. Oracle is a registered trademark, and Oracle8i, Oracle8, PL/SQL, and Oracle Expert are trademarks of Oracle Corporation. All other company and product names mentioned are used for identification purposes only and may be trademarks of their respective owners.