Database grants

Previous Next

Once you have entered or changed authorization definitions in the repository, the corresponding grants need to be updated in the database server. You can either have the Authorizer send these updates directly to the database, or put them in a script file. If you choose the second possibility, you must process the file by means of your RDBMS vendor's middleware.

NOTE 1: The rights that you define in the repository are checked by USoft Developer's conceptual processor from the moment they are saved. End-users of USoft applications, therefore, can never bypass these security measures. However, if you do not generate these rights in the database server, it would be possible for them to access the database directly by means of the RDBMS vendor's middleware.

NOTE 2: When generating scripts, the database is checked to see if certain roles already exist. If so, they are not generated. This means that a generated script can only be run once.

NOTE 3: To be able to Update the Application Rights on Oracle, you need the CREATE ROLE and DROP ANY ROLE privileges

Remember there is more than one way to obtain the same result. From situation to situation, take the approach that involves the least work:

If you do not specify any rights for a certain user group, that user group is allowed to do ALL on all tables. As soon as you have defined one right, however, that is the only right they have.

If you want to give a user group two or more rights on a particular table, you must enter as many records for that table.

You can grant table rights without specifying to which columns these rights apply. In that case, the rights apply to ALL columns.

If you grant a right on a table, specifying to which columns this right applies has no effect, unless you specify column conditions.

You can grant a right on a table, and then specify to which columns this right does NOT apply.

You can deny a right on a table, and then overrule this right at the column level.

In case of supertypes and subtypes, you can refer to supertype columns in your conditions as if they were part of the subtype(s).

See also

Options for granting or revoking access rights

Authorization Tables