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:

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 these 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 has ultimately permission to carry out the database actions.

Role-dependent authorization types 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 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 session authorizations, at various levels, and for a specific company or for all companies. For example, you can give users authorizations only for specific sessions in a module or only the sessions in a specific package.

The session authorization priorities in the table show that 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.

You can define the session authorizations with these sessions in AMS:

• , 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):

• , overview session which defines the roles.
• , details session 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 at various levels. You can give the users authorizations for specific tables in a module or only some table fields in a database table and so on.

The table authorization priorities in the table show that 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. See this table:

You can define the database-table authorizations and the database-table-field authorizations with these sessions in 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.

For more information, see To Model a Business Object.

You can specify the library authorizations at several levels. For example, you can give the users authorizations only for specific libraries in a module. Or give the users authorizations only for the libraries in a specific package and so on.

The library authorization priorities in the table show that 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.

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

• Enhanced AMS: