How to secure API methods?

There are couple of methods to secure API methods in IBMi. In this article I will focus on four of them. It means IBMi way, DC1 secur way, Aperio way and security exit program.

IBMi way

First of all the API methods are ordinary programs or rather objects in IBMi operating system. It means the easiest way to secure them is to define authority to objects. This is pure administration work. System administrator can grant authority only for certain users and programs. The MGRRxxxx programs (managers or wrappers) are used only by aperio. They are not called from other places of DC1 system. If user has no access to specific MGRRxxxx program, it will not harm anything in DC1 flow. Just use WRKOBJ command in IBMi operation system and edit authority for MGRRxxxx object.

Note: The system security must be applied to all version of program. It may happen that the same program exists in two or more libraries. All objects in all libraries must be secured then.

In example bellow I edited authority for MGRR0097 program and maked PLMARKA3 user excluded. Since this moment this user can’t use this object.

Edit authority for object

When user will call this API he gets the result “internal error”, as Aperio can’t call MGRR0097 program.

Result of call in API Tool

When You look into job log the message explicity says that user has no authority to object:

Job log result

Iptor DC1 way

Each program can be secured by DC1 secur routine. The security check is performed during open crossref files routine. So, if method has attribute “openCrossRef”: true, then the security will be performed. Go to “Work with program/user security” table and define manager/wrapper program. Then assign users to the program. Since this moment user has (or not) access to program.

In example bellow I edited authority for MGRR0097 program and maked PLMARKA3 user excluded. Since this moment this user can’t use this program.

Work with program/user security

Assign user

When user will call this API he gets the result “internal error”, as Aperio can’t call MGRR0097 program

Result of call in API Tool

This time there is no information in job log that user has no authority. The authoruty is applied without any notification to Aperio.

Aperio way

Aperio has its own simple secuity mechanism. Here the focus is on the method name. You can secure methods using WRKAPICTL program. There You define security attributes for method. If You want to secure itemBatch.get method, then got to this method and add on of thre attributes:

  • allowedUsers <– This atribute defines list of allowed users. The list can be coma separated. Only listed users has access to this method. The rest of users are excluded and can’t use this method.
  • excludedUsers <– This atribute defines list of excluded users. The list can be coma separated. Listed users has no access to this method. The rest of users are allowed.

Note: Either allowedUsers or excludedUsers can be used.

  • active <– By this attribute You can globally turn on or turn off method.

In example bellow I added “excludedUsers”:PLMARKA3 atribute for itemBatch.get method. By this user PLMARKA3 has no authority to run method.

Work with API control

When user will call this API he gets the result message which says that he has no authority.

Result of call in API Tool

Security exit point

It is possible to add security exit program(s) as S0001002 exit point which is called as the last step of security check, just after Aperio way security mechanism. S0001002 is described here

Look at WRKAPICFG to see how to add exit points.