17.3 Oracle Application Server Web products are usually implemented with a three-tier configuration if a database is involved. While this usually means three computers a client PC, a middle- tier computer used to support the application code, and a back-end computer that houses the database, as we discussed in Chapter 8 it does not have to. These are functional concepts, and two computers (or even one) can run with the three-tier model, although that is not common. A two-tier, client server configuration could be used. Most applications dealing with a database must maintain a constant connection. A web application, on the other hand, is stateless and can connect and disconnect from a database as needed to support the web site users' requests . We'll describe what we mean by the terms "constant" and "stateless" in the following section. 17.3.1 Constant-State Versus Stateless Connections Oracle Corporation provides a product called the Oracle Application Server (OAS), which serves a broad spectrum of applications for web-based interaction. With each new version of the Oracle Application Server, new security features are introduced or current features are enhanced. Therefore, this section provides a very general overview of some basic security features available in the OAS version 3.0 product. While you are dealing with a database from a web site, the actions of the application are remembered internally by the database. This allows you to either keep what you have done (commit) or undo your work (roll back). The actions you can take rely on the database knowing who you are and what you have done. If you disconnect, the database would have to undo all the work you have not committed before you disconnect. The database must also know that you have modified a record and must prevent other users from modifying the same record. The ability of the database to keep track of your actions for example: can only be accomplished if the transactions all occur within one session. The act of remaining connected to the database until a full set of transactions has been completed is referred to as a constant-state transaction. If you disconnect, the database should restore the data to the last stable state, that is, to your last commit. Web applications, on the other hand, are stateless . They access the server but do not maintain a constant session connection. When you have downloaded a page from the server, the connection link is idle and the server does not know what you are doing with or to that page. We will describe the OAS functionality and connection states for two situations, one using a typical Oracle Forms type of application and the other using dynamic HTML. 17.3.1.1 Running a form using the OAS The OAS uses a three-tier architecture. Working at tier one, the workstation, you establish a link to tier two, the Oracle Application Server. You initiate an application that uses the database, typically an Oracle form. This application is actually executed on the web server by a modified form engine. The part that handles the display is downloaded to your workstation while the application, running on the web server, establishes a permanent connection with the third tier, the database server. Tier two, the Oracle Application Server, actually functions as a client with tier three, the database server. The Oracle Application Server maintains the necessary connection to the database while keeping the data link with your workstation free for other users when you are not using it. From a security standpoint, there is nothing new here. If you consider the web server and the database server to be running in client/server mode, then the usual security problems exist. If the network is external, as with access through the Internet, then anybody can monitor or "sniff " the line. If the access is internal, as with an intranet, sniffing can still occur, but the potential is marginally reduced simply because the population is smaller. Thus, it does not matter if the network is internal or external; the problem of someone else snooping and intercepting your data still exists whether the data is being transmitted from your client PC to the Oracle Application Server or from the Oracle Application Server to the database. In order to establish a secure environment, the entire session must be encrypted from the point in time when you submit your username and password through your final exit. As we mentioned before in the "Advanced Networking Option" section, all networks can be sniffed. Data can be intercepted, read, changed, or even completely stopped . The only complete solution to protecting your data and database is to use a secure connection between the workstation and the Oracle Application Server, and between the Oracle Application Server and the database server. 17.3.1.2 Running a dynamic HTML application In this scenario, the database PL/SQL packages are used to generate HTML for display on the workstation. The execution of the PL/SQL is handled by a cartridge on the OAS that passes the execution requests with appropriate arguments to the database server. This is a transaction-oriented approach. The user works on the HTML page within the browser until he or she is ready to commit the work. At that time, the data is sent to the OAS where it is packaged with the PL/SQL request and sent to the database. While the cartridge maintains a connection to the database server, it does not maintain a session with the database. Thus, the entire link is stateless except for the brief periods of communication during which data is requested from or passed to the database server. Work is committed whenever the "page" of data is sent. This has a significant impact on the development approach, since a request for "rollback" of the work will now require a DELETE statement and not a ROLLBACK. The advantage of using dynamic HTML applications is reduced load on the network and generally faster throughput. 17.3.2 How the OAS Works The Oracle Application Server contains security software from RSA Corporation. There are two types of communications that can be performed with OAS. Each type uses a different form of an Object Request Broker (ORB): -
For distributed communications, an Oracle-provided protocol called Oracle Media Exchange (OMX) is used -
For non-distributed communications, an industry-standard protocol called UDP is used An Object Request Broker manages objects using an industry standard for cross-platform communications between executable programs called the Common Object Request Broker Architecture (CORBA). There are several components that make up the OAS. Some of the components are supplied with the Oracle OAS and some are not supplied by Oracle Corporation. The components you need to use the OAS effectively are: -
A browser usually Netscape Navigator or another form of web-based application (non-Oracle supplied) -
An HTTP listener listening for requests (Oracle provides the Spyglass HTTP listener) -
Cartridges to execute applications and return HTML content back to the browser (six cartridges supplied with OAS 3.0) -
A dispatcher for requests that require cartridges (one dispatcher for each listener) (Oracle-supplied) -
The Web Request Broker (WRB), which creates and destroys cartridges for the network (Oracle-supplied) -
An Oracle database (you build your own using Oracle software) Cartridges communicate with the database using either Oracle Calls Interface (OCI) calls or PL/SQL.  | In OAS 3.0, a version of the Spyglass HTTPS listener is included to support SSL-3 communications (SSL-3 is the Secure Socket Layer protocol). However, you must have a digital certificate issued by Verisign Corporation for the Spyglass HTTPS listener to work. Oracle's OAS also supports Netscape Enterprise and FastTrack HTTPS servers (versions 2.0 and 2.01). Microsoft Internet Information Server (IIS) is supported. The "S" indicates that a Secure Socket Layer (SSL) connection is being requested. | | Figure 17.1 shows the OAS architecture. Figure 17.1. The Oracle Application Server architecture  17.3.3 OAS Security The Oracle Application Server supplies security features for user authorization in several different ways. Based on the way you connect to the web site and which web pages you want to access, the OAS will authorize your access to information using: -
The dispatcher or the cartridge itself for WRB cartridges -
A Secure Socket Layer (SSL) or digest authentication for encryption of passwords over SQL*Net -
The listener for HTTP static pages or CGI scripts -
The database server through username/password (in a file or from the database) and/or roles -
An authentication server with username/password stored in a file or in the database As we mentioned in Chapter 16, there are products that can be used to limit access to your web site in several different ways. The Oracle Application Server enables you to restrict access to information by prompting for the username and password, restricting access by IP address and/or domain, or checking for the presence of a digital signature.  | 
