User-Validation Support

The Global system class provides the getAndValidateUser and isUserValid methods. You can reimplement these methods in the Global class of your subschema to selectively apply user validation for applications defined in that subschema. (For more details, see "Global Class", in Chapter 1 of the Encyclopaedia of Classes.)

The getAndValidateUser and isUserValid methods of the Global class allow for a separation between obtaining user code and password information that often requires a dialog interaction with the end-user at the client and secondary validation, which may need to be executed at the server.

Use secondary (server-side) user validation to limit the possibility of illegal system access. The getAndValidateUser method provides an extra level of protection at the start of a process or application in conjunction with the isUserValid secondary validate method run at the server.

If you do not implement the isUserValid method (which in turn depends on the getAndValidateUser method), a hacker can bypass your application security entirely by substituting his or her own client program and then accessing your schema directly. Without this level of security, you would be unable to stop this illegal access of your system.

When no user code is supplied in the jomSignOn API call, the Jade Object Manager invokes the Global class getAndValidateUser method. The isUserValid method secondary validation is always invoked. In practice, this means that for:

Jade applications, both validation methods are invoked.
Non–Jade applications that do not supply a user code in the jomSignOn API call, both validation methods are invoked. Higher-level interfaces (for example, ODBC) require that a user code is supplied to establish a database connection, which is in turn passed to the jomSignOn API call, so that secondary validation only is invoked.

When developing the getAndValidateUser and isUserValid methods, consider that these methods will be called in non-GUI applications Creating and attempting to show forms in non-GUI applications will raise an exception.

In the Global class getAndValidateUser method, check if the type of application is non-GUI or web-enabled non-GUI. If so, manufacture your own user code and password; for example, you could set the user code to the application name and the password to the current schema name. Your isUserValid method can then check that the combination of non-GUI, user code, and password are valid, to protect against running non-GUI applications that are defined in the schema and are not intended to be run in production.

The user-validate methods have normal access to the database and can create and manipulate forms. The validate methods provide update capability so that you can retain state information, if required; for example, the number of log-on attempts for each user or a security audit trail in persistent objects.

The default implementation of the user-validate methods performs the following actions.

Manufactures a user code
Allows applications to be run without any user validation

The user-validate methods are invoked from a tentative process created by the Jade Object Manager as a result of the jomSignOn Application Program Interface (API) call. (For more details, see "Opening a Process", in Chapter 3.)

If user-validation succeeds, the jomSignOn API returns a valid process handle to the caller, which allows the application to proceed as usual. If the user-validate methods signal failure, the Jade Object Manager destroys the tentative application and process objects, and a null process handle is returned to the caller.