- Security Protocols continued...

HTTP Referrer

You can use the HTTP Referrer sign on to allow only users coming from a certain web page into your

application. This can be useful when combining an existing web site with WOW – when the user arrives

at a WOW application from a page on the existing web application you may not want to force the user

to sign on again. It is possible, though unlikely, that someone with an understanding of the HTTP

protocol could trick WOW into thinking they came from a particular page.

To use HTTP Referrer sign on, you must first create an operation of type “Referrer Authorization”. In the

operation code list the comma separated URL prefixes of permitted referrers. For example, if your operation

looked like this:

Users coming from the following pages would be granted access to your application:

http://www.planetjavainc.com

http://www.planetjavainc.com/wow

http://www.myownwebpage.com/test

Users coming from http://www.myownwebpage.com would not be given access.

SQL Operation

This type of authentication allows for a very versatile way to secure the sign-on of an application. SQL

Operation sign on is the most powerful type of application sign on. It allows for a couple additional

features to be used; Securing Operations (as described later in this chapter) and using user properties as

parameters in other operations.

SQL Operation sign on requires that the given application contains an authentication operation. An

authentication operation is a regular SQL Operation that has a different type (authentication) to denote

that it should be used for sign on authentication. This allows any number of values to be retrieved as user

properties, as well as allowing authentication against any data in the database. See the two examples

below for more details.

SQL Operation sign on example 1:

To properly setup an Application with a Sign On Type of SQL Operation, the user must specify this setting

while editing an Application. Once this is set, the user creates the SQL Operation that will be used to

authenticate the Sign On. To do this, create an SQL Operation for the Application and set the required

property of Operation Type to Authentication.

The user must specify the SQL Query that contains the field or fields to be authenticated against. Save this

information with the Operation and run the Application. A screen should appear that presents TextFields for

the fields specified in the query and a “Login” button.

The order of the fields presented on the screen is determined by the order of the fields in the SQL Operation. In

order to provide nicer values for the labels on the TextFields, be sure to specify the external name in the Field

Data for that file.

When the login button is pressed, the authentication operation is run using the values the user supplied. If the

operation returns any rows from the database, the sign on is successful. If no rows are returned, the sign on fails.

SQL Operation sign on example 2:

This example is the same as example 1, but the SQL is different to give a more clear explanation of how user

properties and sign on fields are generated. In this example, we will also authenticate against the same table as

the first example, but we will change our SQL. This time, we will authenticate against the user name, user

password, and last name columns of the table.

Here is the sign on page:

You’ll notice that this example selects certain fields from the user table. These fields may then be used by other

operations as parameters. For example, the query

SELECT * FROM PLANETJ.CUST_DATA WHERE F_NAME = ???URFIRSTNAME

would select from the CUST_DATA table where the F_NAME field contains the same value as the URFIRSTNAME

field in the current user’s row of the USER table. (See section 10.1 for more information on user parameters.) In

addition, the urseclevel field selected has a usage id (see Appendix A) set to denote that it’s a security level field.

This means that the application could contain operations that are secured by level and each user signing in would

have a security level (see the next section for more information on security levels).

Multiple Sign On Operations

Most applications which use SQL for signing on do so in a single operation. However, it is possible to use multiple

operations for a single sign on. For example, on the first screen you may want to have the user enter in his or her

ID and check that against the list of authorized users before presenting the user with a second page for entering

in a password.

To configure your application to use two sign on operations (as in the above example) follow these three steps:

• 1. Define both of your operations normally. Be sure to set their operation type to Authentication. This is a

     1. screenshot of the first operation (for checking the user’s name):

This is the second sign on operation (for verifying a user’s password):

Notice that this operation refers to data returned by the first operation with the double question mark syntax

(??USERID). This is necessary because we need to check not only that the password is valid, but that it is

valid for the particular user ID obtained from the first operation

• 1. In the second sign on operation, the first sign on operation must be identified as the parent operation.

     1. This lets WOW know that after running the first operation, the sign on isn’t complete until the second

     2. operation is run as well.

• 1. Finally, the application’s sign on type should be set to SQL Operation, and the primary (first) sign on

     1. operation specified. Now the application is set up to use multiple sign on operations.