| Previous | Table of Contents | Next |
In a traditional client-server environment, users log in to a system by entering a user name and password. This causes the client to issue a request to establish a connection to the server. The server receives the request, validates the user, and established a connection. Then, as long as the user stays connected to the system, the server can confidently recognize each new user request as coming from the validated user.
In HTTP, it is not possible to stay “connected.” Each request sent from a client to a server is an independent, autonomous request. The server can receive the client’s first request to log in, validate the request, and send back a confirmation. But the client and server cannot connect, meaning that each new request from the client requires some sort of validation.
It’s something like the difference between making a phone call and writing an email letter. When you telephone someone, a connection is established. Once you identify the person on the other end, you can confidently assume the rest of the conversation is, indeed, with the person you identified at the beginning of the phone call.
But when you exchange letters with someone, you need to identify that each new letter is, indeed, from the person with whom you are intending to correspond.
In Web-enabled applications, the burden of confirming the identity of each new client request (not just each login session, but each individual request, for example, to display one new page) is generally on the application. For one example of how to implement this, see the section about the PL/SQL cartridge and Cookies.
Tip:
WAS 3.0 offers a new feature in the PL/SQL cartridge to help control user access: the Package/Procedure Protection feature. When a stored package or procedure is protected, no one is able to access the URL directly—you can’t just type the URL for that procedure in your browser and get access, only another stored procedure can get access. In other words, if you build your application so that the initial login procedures are unprotected, and then protect all other packages and procedures, the user will always have to enter via the login procedures. This is a great security feature. But it may cause a problem if a user wants to use any third party tools, such as Microsoft Excel and its Web Query feature (available in Excel 97 with the Web Authoring Option), which downloads Web information directly from a given URL into an Excel spreadsheet (complete with formatting). If you find that you must leave some procedures unprotected, you can user a cookie check and IP address confirmation to lock out any invalid users, by having each unprotected procedure perform these checks up front, and raising an exception for any users without the right cookie number and IP address combination.
The WAS supports Secure Sockets Layer, which is a standard for both encryption of transmitted information, as well as for confirmation of the identity of either the client or server to each other. The SSL works as a layer in the TCP/IP stack (beneath the Application Layer).
SSL not only encrypts communication between the client and server, but it also incorporates digital certificates to confirm the identity of either the client, server, or both. A digital certificate is an encoded digitized alphanumeric code that uniquely identifies the server to a third party, usually Verisign, an independent organization. It is a time- consuming thing to obtain a digital certificate. It usually requires the corporation, organization, or whoever is operating the server, to provide documentation to confirm their identity, such as their Articles of Incorporation. A Dun and Bradstreet number is required under certain circumstances, as well as other information confirming the requesting party’s identity, address, type of business, and so on. The process can take as much as several weeks to get approval. But once the identity is established, the digital certificate is provided to the server, and the administrator must configure the server software to incorporate the certificate. Then, when any client attempts to connect to the server using SSL, the server provides the certificate as confirmation of the server’s identity. The user is then usually notified, through his browser, that an SSL request has been made, and he is given a choice to accept or deny. The user is also often given the option of viewing the digital certificate’s associated text information—in other words, the server owner’s name (the corporation, organization, and so on), address, and so on. Once the user accepts the request, SSL transmission begins. The browser usually displays some graphic, such as a key, or lock, or something, to indicate that the browser is operating in SSL.
All of this is to help guarantee to the client that the server is, indeed, who it claims to be. But what if the server requires confirmation of who the client is? Client-side digital certificates are also possible, but require a similar effort to obtain. Obviously, this is not a simple effort. For those regular users who will be accessing your system from the same location every time, client-side digital certificates are possible, but not always practical. Each situation has its own demands, and the choice is up to you.
Once SSL has been set up on your server, it’s relatively easy to implement in an application: one slight change in the URL for any given resource is all that is required. For example, this is a URL for a non-SSL hyperlink:
http://www.corbinian.com/macmillan/article.htm
And this is a URL that incorporates SSL:
https://www.corbinian.com/macmillan/article.htm
In other words, to have your users log in with SSL transmission, just publish a slightly different URL and your client’s first connection will incorporate SSL. On the other hand, you can have a client connect to your application as usual, and then within your application incorporate a hyperlink to a portion in which you choose to incorporate SSL by just modifying the hyperlink.
As long as your application’s internal hyperlinks use relative addressing, the application will not require modification to incorporate SSL.
| Previous | Table of Contents | Next |