Role-dependent authorizations

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 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.

This diagram shows an example of the combined authorizations of two different roles:

• Enhanced AMS

  With Enhanced AMS there is no limit to the number of roles that can be assigned to a user. A user can have multiple roles assigned which removes the necessity to support the role hierarchy.

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. If the table authorizations are restricted for one role but not for the other role. The department manager ultimately has permission to carry out the database actions.

Role-dependent authorization types in LN

In LN, you can define the role-dependent authorizations at these component levels:

• 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. This is 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 with the highest priority (1) is stated at the most specific level. 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.

This table shows the session authorization priorities:

	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

In LN ’s AMS, you can define the session authorizations with these sessions:

• , which defines the session authorizations at company level
• , which defines the session authorizations at package level
• , which defines the session authorizations at module level
• , which defines the session authorizations at session level

Enhanced AMS (the ‘classic sessions’ ttams3xxx are replaced):

• Role Data overview (ttams4100m000), which defines the roles.
• Role Data details (ttams4600m000), which defines the different authorizations (session, table, table field, library and role assignments).

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. 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, see the “RDBMS administration” section.

The table authorization with the highest priority (1) is stated at the most specific level. 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.

This table shows the table authorization priorities:

	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 these sessions in LN ’s AMS:

• Enhanced AMS:

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.

See To Model a Business Object in the Infor Enterprise Server Web Help.

You can specify the library authorizations at several levels. 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 with the highest priority (1) is stated at the most specific level. The lowest priority (3) is stated at the most global level.

This table shows the library authorization priorities:

Library per library	1
Library per module	2
Library per package	3

You can define the library authorizations at the various levels with these sessions:

• Enhanced AMS: