| # Role-dependent authorizations From a user point of view, a role represents a functionality in a company. In LN ’s Authorization Management System (AMS), a role represents a set of authorizations for a functionality in a company. User authorizations that are defined by role instead of by user significantly reduce the redundant data. The authorizations for normal users are, therefore, defined in roles to which the authorizations can be linked. The role concept provides you with a user-friendly method to quickly add new users or to update user authorizations. Because an employee can have more than one functionality in a company, you can assign the user to more than one role. A role can also contain more than one sub-role, which itself can also have sub-roles. All these roles and sub-roles form a role tree, which you can view with the role browser. The role browser shows the role tree in a graphical user interface. Ultimately, the employee’s role is a combination of all the authorizations defined in the user’s roles and sub roles. Recursive role structures are not allowed. For example, a junior software engineer cannot have the authorizations of a senior software engineer in a sub role. The following figure shows an example of the combined authorizations of two different roles: Example of combined authorizations for more than one role For example, a department manager has more responsibilities than the employees in the department and therefore has more database authorizations. Consequently, the manager has two roles: The role of the employee with the appropriate restricted authorizations The manager’s role with additional authorizations, which are only relevant for the manager The restrictions on the table authorizations of the two roles are combined for the department manager. However, if the table authorizations are restricted for one role but not for the other role, the department manager will ultimately have permission to carry out the database actions. Role-dependent authorization types in LN You can define the role-dependent authorizations at the following component levels in LN: Session authorizations Table authorizations Library authorizations If the role-dependent authorizations change, conversion indicators are automatically set. Changes to the session authorizations, table authorizations, and the library authorizations are only converted to the run-time data dictionary when the conversion indicator is set to avoid unnecessary conversion of the authorization data to the run-time data dictionary. Session authorizations The session authorizations define which sessions the users can start and what the users can do with these sessions in LN. You can specify the session authorizations and on several levels for either a specific company or for all companies. For example, you can give the users authorizations for only specified sessions in a module or only the sessions in a specified package. The session authorization priorities in the following table show that the session authorization with the highest priority (1) is stated at the most specific level and the lowest priority (8) is stated at the most global level. The session authorizations that you define for a specific company have a higher priority than those defined for all companies:
| One company | All companies
Session authorizations per session | 1 | 2
Session authorizations per module | 3 | 4
Session authorizations per package | 5 | 6
Session authorizations per company | 7 | 8
You can define the session authorizations with the following sessions in LN ’s AMS: Session Authorizations by Company (ttams3133m000), which defines the session authorizations at company level Session Authorizations by Package (ttams3130m000), which defines the session authorizations at package level Session Authorizations by Module (ttams3131m000), which defines the session authorizations at module level Session Authorizations by Session (ttams3132m000), which defines the session authorizations at session level Table authorizations The table authorizations define the actions the users can perform on specified database tables and the associated fields in the database table. You can specify the table authorizations for a specific company, or for all companies, and on several levels. For example, you can give the users authorizations for specified tables in a module or only some table fields in a database table and so on. The table authorizations that you define in LN ’s AMS are applicable to the databases for which the user is authorized. You can define the databases for which the user must be authorized in the RDBMS Administration module. For more information about the LN ’s table authorization, refer to the “RDBMS administration” section. The table authorization priorities in the following table show that the table authorization with the highest priority (1) is stated at the most specific level and the lowest priority (14) are stated at the most global level. The table authorizations that you define for a specific company have a higher priority than those defined for all companies.
| One company | All companies
Database table field data authorization | 1 | 2
Database table field authorization | 3 | 4
Database table authorization per table data | 5 | 6
Database table authorization per table | 7 | 8
Database table authorization per module | 9 | 10
Database table authorization per package | 11 | 12
Database table authorization per company | 13 | 14
You can define the database-table authorizations and the database-table-field authorizations with the following sessions in LN ’s AMS: Table Authorizations by Company (ttams3144m000) Table Authorizations by Package (ttams3140m000) Table Authorizations by Module (ttams3141m000) Table Authorizations by Table (ttams3142m000) Table Data Authorizations (ttams3145m000) Table Field Authorizations (ttams3143m000) Table Field Data Authorizations (ttams3146m000) Important! Table field authorizations and Table Field Data Authorizations have no effect on reports. If a user has no authorization at all for a table field, the field is still printed. Library authorizations LN uses the Business Object Layer (BOL) integration technology, and OLE, DDE, OCX, and ORB interfaces to integrate programs with the LN environment. These programs communicate with LN through the Dynamic Link Libraries (DLLs). The Library authorizations define whether the users who are linked to the role can access the functions that are defined in DLLs. Note For details on the Business Object Layer (BOL), refer to Modeling a Business Object in the Infor Enterprise Server Web Help You can specify the library authorizations at several levels. For example, you can give the users authorizations only for specified libraries in a module or only the libraries in a specific package and so on. The library authorization priorities in the following table show that the library authorization with the highest priority (1) is stated at the most specific level, and the lowest priority (3) is stated at the most global level:
Library per library | 1
Library per module | 2
Library per package | 3
You can define the library authorizations at the various levels with the following sessions: Library Authorizations by Package (ttams3150m000) Library Authorizations by Module (ttams3151m000) Library Authorizations by Library (ttams3152m000) |