Authorization tables

You can register Table objects as Authorization Tables via a dialog window by choosing Tools, Fill Authorizer Tables from the menu, or via a wizard by right-clicking the Authorization Tables node in the project catalog and then choosing Fill Authorizer Tables.

Check the Remove Obsolete Entries box if you wish to delete any Authorization Table entries that are obsolete, ie., that are no longer defined in the application they belonged to. This option must be used with care. You may lose valuable information if you check this box.

•You can view Authorization Tables and their columns. Choose View, "Authorization Tables" from the menu.

•You can alternatively view a list of Authorization Tables by Application. Choose View, "Authorization Tables by Application" from the menu.

In USoft Authorizer, each Authorization Table belongs to a specific Application. It is not possible to have the same Authorization Table in multiple applications: the list of Authorization Tables must be a "flat" list of unique names, otherwise, it's an error.

In practice, in each USoft environment, table names are unique across applications. In your User Application, this is checked when you define a new table in USoft Definer. If you use modules, this is checked when you synchronise a consumed module. USoft tools have naming conventions that cause their tables to be uniquely associated with each application: for example, all the Definer tables start with "T_..." and all the Service Definer tables with "T_SVC_...".

To get unique Authorization Table names, all you need to do is make sure that the tables you define yourself do not start with "T_...".

You can define rights on Logical Views just like you can define rights on Database Tables. Logical Views are Authorization Tables in the same way as database tables:

A difference with Database Tables is that Logical Views exist only in the USoft layer and not as physical database tables. When you add or change authorisation on Logical Views, you do not need to (re)run the Update Application Rights routine that generates database grants.

Logical Views and Database Tables entertain complex relationships, since a Logical View is defined on (based on) one or more Database Tables: Logical Views are said to have underlying tables. A Logical View can also be defined, partly or wholly, on another Logical View.

USoft Authorizer is completely ignorant of these relationships. It simply allows you to define rights (Table Rights and Column Rights) on Database Tables and Logical Views alike.

When you view Authorization Tables in USoft Authorizer, the Logical View Y/N flag allows you to identify an Authorization Table as a Logical View:

Run-time effect of table rights on Logical Views

When you define Table Rights or Column Rights on a Logical View, you must consider the runtime effect of the Logical View's relationship with its underlying table(s) (including any other Logical Views that it is defined on).

The general rule is that it makes no sense to define rights on a Logical View if you do not define at least the same rights on the underlying table.

If you give wider authorisation on a Logical View than on its underlying table, the effect is that the run-time user gets an error message mentioning the underlying table when she attempts to access unauthorised data on the underlying table through the Logical View. This effect is undesirable, especially if you do not want to disclose the name of the underlying table.

In practice, the same rights are often defined on Logical Views and on their underlying tables. It may or may not make sense to define narrower rights on a Logical View than on its underlying table.

Comparing underlying tables and background scope

"Underlying table" is NOT the same as "table with background access". At first sight, you might think that giving access to a Logical View would involve granting foreground access on the Logical View and background access on the underlying table. But "background" and "underlying" are unrelated concepts.

Typically, if you want a user to have foreground access on a Logical View, you also want to give him foreground access on the underlying table. To give a user read‑only access on a Logical View, typically you give him SELECT‑only foreground access on the Logical View AND SELECT‑only foreground access on the underlying table.

If a user is allowed to perform some action that activates a constraint or a relationship attribute that indirectly affects a Database Table or Logical View, but, for some reason, you do not want him to access the table or view otherwise, then you need to grant background access only, regardless of whether the object is a Database Table or a Logical View.

USoft Authorizer does not "see" that a table is a Component Table. You can define Table Rights and Column Rights on Component Tables just like you can define Table Rights and Column Rights on Database Tables. Component Tables are Authorization Tables in the same way as database tables:

A difference with Database Tables is that Component Tables exist only in the USoft layer and not as physical database tables. When you add or change authorisation on Component Tables, you do not need to (re)run the Update Application Rights routine that generates database grants.

It could be that all of the 4 Access Rights (SELECT, INSERT, UPDATE, DELETE) apply to a Component Table. It could also be that only a subset applies. This depends on implementation details of the Component associated with the Component Table. Make sure that you only define access rights for operations that are actually implemented.

USoft Authorizer does not "see" that a table is an Interface Table. You can define Table Rights and Column Rights on Interface Tables just like you can define Table Rights and Column Rights on Database Tables.

Interface Tables, like Database Tables, exist as physical database tables. When you add or change authorisation on Interface Tables, you must (re)run the Update Application Rights routine that generates database grants.

Interface Tables reflect a concern with development-time modularisation, but authorisation is concerned only with the run-time use of tables and views. For this reason, when you come to define authorisation, the distinction between Interface Tables and other tables and views is no longer relevant.

Subtype tables are Authorization Tables in their own right, independently of whether they are implemented as separate Database Tables or not (something that you decide by setting or unsetting their "Create Separate Table" flag). If users are allowed full use of a subtype constellation, you must be careful to give them the same rights separately for each supertype and subtype.

Run-time effect of table rights on subtypes

This gives you much flexibility, but it also requires you to analyse each situation carefully if you decide to define different rights on supertypes than on subtypes. For example, if you define full table rights on a supertype but not on its subtype(s), users will be able to see and query the subtype indicators in the supertype table. But despite having UPDATE rights on the supertype, they will not be able to update these subtype indicators from Y to N or from N to Y, because that would be tantamount to deleting from or inserting into the subtype table, which they have no right to do.

For a detailed discussion, go to Authorisation for supertypes and subtypes.

Update rights on subtypes

Authorisation on subtype constellations is dealt with by the Rules Engine. Its run-time effect is fully independent of whether subtypes are implemented as separate physical database tables or not.

Technically, at the database level, separate grants are required for separate physical tables. When you (re)run the Update Application Rights routine, USoft automatically generates separate database grants if subtypes are implemented as separate physical database tables.