API authorizations and authorizations for LN database access

Authorizations for access to the LN database can be defined in multiple ways:

  • LN Tools – Authorization Management System – AMS

    We recommend that you do not specify detailed AMS database authorizations for the service user account.

  • The Authorization and Security module in LN Common (tcsec)

    For details, see the Infor LN Common User Guide for Authorization and Security.

  • API authorizations

If detailed database authorizations and restrictions are defined through multiple of these methods, things can become unclear. It may happen that you accidentally create authorizations that contradict each other. For example, you may accidentally create a situation like this:

  • The AMS role of the svc_ln user denies access to a particular table.
  • The API role of the API identity of the svc_ln user grants access to all methods of a service that accesses that particular table.

If the different authorization types (AMS, tcsec, API) contradict each other, the most restrictive authorization applies. So, in the example mentioned, the AMS authorization overrules the API authorization: the API methods do not work, because the svc_ln user has no access to the table involved. If you are not aware of this particular AMS database authorization/restriction, this can be confusing.

Note: To avoid a complicated situation, we recommend that you define the svc_ln user as a normal user with an AMS role that provides FULL access to all tables in the LN database. To deny access to particular tables, you can then define API authorizations to deny the services/methods that access that particular table.