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:
•Module Name: USAUTH •Load Module: Yes •Description: the USoft Authorizer
•Module Name: USAUTH •File to be used in the synchronization process: <USoft installation directory>\APP\USAUTH.con
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. See Also |
![]() |