USoft Authorizer as a module

USoft recommends that in USoft 9, you declare the USoft Authorizer application as a module in your Development environment by following these steps:

1.	Open Definer in your Development environment.

2.	In the Application Modules window (accessible from the menu via Tools, Manage Internal Interfaces, Modules), declare USoft Authorizer as a module:

•Module Name: USAUTH

•Load Module: Yes

•Description: the USoft Authorizer

3.	In the Internal Interface Consumers window (accessible from the menu via Tools, Manage Internal Interfaces, Consumed Interfaces), declare the USAUTH module as a consumed module:

•Module Name: USAUTH

•File to be used in the synchronization process: <USoft installation directory>\APP\USAUTH.con

4.	Press the "Synchronize Internal Interfaces" button.

The remainder of this help topic helps you understand the implications of declaring USoft Authorizer as a module. For more general information about modules, please go to USoft Definer Help.

The "classic" view of USoft Authorizer as a separate application

The layer of authorization rules is always checked by the runtime Rules Engine. The "classic" or default view of authorization rules in USoft is as a separate layer defined in a separate application (USoft Authorizer). In this setup, the application rules (the Rules Engine) defined in USoft Definer and the authorization rules defined in USoft Authorizer are in different metamodels:

•The Rules Engine has no knowledge of authorization rules.

•USoft Authorizer has no knowledge of application rules other than a list of tables and columns (obtained through USoft Authorizer's Fill Authorizer Tables routine).

Example

A user application may have Projects, Persons, and Project Team Members, with Project Team Member as an intersection table between the Project and Person tables. Content in these (3) tables must determine which projects a given person has access to. In the "classic" USoft Authorizer setup, the only way to achieve this is to run the Fill Authorizer Tables routine, define a Table Right on the Project table, and append an Authorization Condition to that Table Right of the following type:

project_id in (

select ''

from project_team_member ptm

, person p

where ptm.person_id = p.person_id

and p.login_name = USER

)

This arrangement is cumbersome. As the example shows, data access is often controlled by a combination of content in application tables and content in authorizer tables. But the application has no knowledge of the authorization layer.

Workaround: declared authorization tables

For this reason, in the past, many USoft teams declared authorization tables (T_AUTH_... prefixed tables delivered by USoft) AS IF they were part of the user application. This is possible because in the USoft architecture, T_AUTH_... tables are always present (for more help on this point, go to USoft Authorizer as a runtime application).

This workaround, however, is suboptimal. It implies illegal use of the USoft Authorizer tables. The workaround does not guarantee that restrictions implemented by domains, relationships and constraints within the USoft Authorizer application (as delivered by USoft in the "USAUTH.con" binary file) are enforced at data manipulation time. Violations could surface at a later time.

Optimal solution: authorization as a module

USoft is now able to deliver modular development. To be a module of your application at development time is the ideal status for USoft Authorizer, because this enables the combination of two desirable things:

•The restrictions laid down in "USAUTH.con", and thereby the authorization data quality, is automatically enforced.

•The data structure of USoft Authorizer tables is available to developers of your application. For example, they can write constraints directly against the T_AUTH_USER table.