Security Considerations

Because client and server are separate processes (and can even be on different machines) with Zim Server Connectivity, there are some new options for providing security, although the same basic mechanisms are used.

Using ZIM Security

Within Zim, security is provided through a combination of log in user names, passwords, and entity set, relationship, and field level permissions. The following is a summary.

Zim Server uses the same facilities. When a Zim application connects to Zim Server, a Database Agent process is started to service requests from that application. The CONNECT command can contain a user name and password. If it does, a LOGIN is executed at the server. If a LOGIN is executed for a specific user, then all subsequent requests to the server are executed under that user. Thus any permissions that have been set up at the server are obeyed.

Permissions (which are set using the PERMISSIONS command) are set in the server database using a development version of Zim with that database on the server machine. Permissions cannot be set from a client Zim application.

Using Operating System Security Features

You can use operating system features to provide security as well. Many possibilities here exist here, but the following points provide some guidelines. Since the means of specifying operating system level security varies from one operating system to another, actual operating system commands are specified. Consult your system documentation for more details on setting file permissions.

Given the above, here is one scenario of how security could be provided by using operating system facilities:

Object Permissions

Entity sets, relationships and fields have security permissions that control how they can be accessed. The permissions defined at the remote database are independent of permissions defined at the client. The following chart illustrates the valid relationships.

Client LOGIN user name

CONNECT user name

Client Operation

Result

Ted

Bob

ADD Customers...

Client-side permissions disallow this.

Ted

Bob

LIST Customers...

Data is retrieved but Salary appears as $NULL because of server side permissions for Bob.

Ted

Carol

ADD Customers...

Client-side permissions disallow this.

Ted

Carol

LIST Customers...

All data is retrieved.

Alice

Bob

ADD Customers...

Operation fails on the server side because Bob cannot add to Customers.

Alice

Bob

LIST Customers...

Data is retrieved but Salary appears as $NULL because of server-side permissions for Bob.

Alice

Carol

ADD Customers...

The operation proceeds.

Alice

Carol

LIST Customers...

The operation proceeds.

Read-only fields

Read-only fields are database fields defined by in a table on the database server. The value of a read-only field is always assigned by the server. Such fields are often identity fields or primary keys that serve to uniquely identify a particular row or record in the table. To create a read-only field, set the Required field to the value of RO or ROE. RO and ROE both designate read-only fields. ROE fields are exported by the Export SQL Definitions facility in the Development Center. RO fields are not exported. When a field is defined as read-only, Zim does not generate syntax that assigns a value to this field, even if the language syntax assigns a value or a value is assigned implicitly because a form field name matches the name of the read-only field.

For example, RO is often useful for pseudo-columns that already exist on the server such as "ROWID" in Oracle database tables. If you create a field in a Zim entityset that reside sin an Oracle database with the name ROWID, Oracle always supplies a value for the field. Making it a read-only field in Zim ensures that Zim does not assign a value to it.