Kbase 21641: Implementation of SSL with WebSpeed Applications.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
15/10/2008 |
|
Status: Verified
GOAL:
Notes on Implementing SSL with WebSpeed Applications
GOAL:
Secure the webspeed messenger with SSL
GOAL:
How to secure webspeed messenger with web server?
GOAL:
How to set up IIS for secure access?
FIX:
WebSpeed applications can access both HTTP (non-secured hyper text transport protocol) and HTTPS (secured hyper text transport protocol).
Some people may wonder why the static pages work with SSL and not the dynamic pages developed with WebSpeed even though both static and dynamic pages are in the same virtual directory. There are situations where static pages behave as they should, i.e., the static page can only be accessed using HTTPS but not the dynamic pages, i.e., the dynamic pages can be accessed by using both HTTP and HTTPS.
Dynamic pages should not be in the WebSpeed virtual directory for security reasons. They should reside anywhere on a separate transaction server, or if the transaction server is in the same machine, they can reside in any folder as long as the WebSpeed agent's propath is setup to access those dynamic pages. The static pages do not need broker interactions or WebSpeed messenger interactions to be displayed in the web browser. They can be displayed as is if they are referenced with a virtual directory. That is why in the above scenario when you link the virtual directory with static pages it can only be accessed by the https URL. In order to secure the WebSpeed applications, you need to have a virtual directory with messenger in the secured area, i.e., associated with the SSL.
The SSL encrypts the data that flows between client's browser and the web server using public key. When the web server receives the encrypted information it decrypts the information using private key. After the information is decrypted in the web server, the information becomes a plain text format. The WebSpeed messenger and agents then handle this plain text for the transactions.
Here is how the setup can be done:
Method A: IIS with CGIIP
1) If the scripts directory with cgiip.exe messenger that is mapped to scripts virtual directory, create another directory anywhere in the web server machine.
2) Copy the cgiip.exe messenger to it.
3) Cerate a new virtual directory, for instance, named sscripts under the default web site in IIS MMC console, with the execute permission.
4) Map the directory created in step (1).
5) Configure this virtual directory to the secured area in the web server.
6) In the secured application, use the logic to check if the URL contains https and sscripts words. If not redirect to an error page displaying the message of your choice.
Method B: IIS with CGIIP script file. Please note that .wsc configuration is applicable within WebSpeed 3.1C and higher
Follow the same steps as listed in method A but, copy the cgiip.wsc script file as opposed to the cgiip.exe.
The advantage of using cgiip.wsc script file is, you can hide the messenger directory from the end users, and bypass the NameServer interaction that may reduce the request processing time.
Method C: Use a second broker
The advantage of using a second broker is to isolate the secure pages so the broker with the non-secured pages cannot access the secured pages.
1) Follow method B.
2) Create a second broker that only has the access to the secured pages (the agent's propath should point to the folder that only has the secured pages).
Be sure to modify the cgiip.wsc file so that it has the appropriate broker port that was created in step (2). In this way you may not need the application logic to check for the https and sscripts folder in the url as described in step (6) under Method A.