This week I will continue coverage of the User Function Registration APIs. You’ll get more information about the APIs and two new commands that you can call from your CL programs or the command line to add and retrieve User Function usage for a user profile. Also included are some comments and insight into the design and concepts of the User Function Registration APIs provided by Patrick Botz, who is a Senior Technical Staff Member with the eServer Security Architecture & Consulting team of IBM’s Client Technology Center in Rochester.
In part one of this article, I was very concerned about pointing out that User Function APIs as such would not offer any protection against access to resources outside of the application(s) implementing the User Function check. This is, of course, correct and worth considering. Admittedly, I didn’t go into detail about how the User Function APIs will provide an effective authorization facility even when taking this caution into account.
This prompted the following response from Patrick Botz, who emphasized that the User Function APIs were not designed to protect access to unprotected objects, but were rather created to provide the equivalent of Application Defined Special Authority/Privileges. Patrick illustrated this point with the following example:
“Consider a large application. All users must be allowed to use the application programs. However, some programs in the application provide multiple application functions. For example, a program provides the option to create a report of customer credit card balances with and without credit card numbers.
All authorized application users should be allowed to see the report without the credit card numbers, but only a few are allowed to see the reports with the credit card numbers.
No user is authorized to the database files that contain the information. The program adopts enough authority to access the database files. The application programmer can choose to create an application specific function/special authority by using the function usage APIs.
The programmer can design the application to check if the requested user is allowed access to the “CREDIT CARD NUMBER” function. Only if she or he does will the application produce the report with the sensitive data. A user can only see the sensitive data if they:
- Are authorized to the application; and
- Are allowed CREDIT CARD NUMBER functional usage (i.e. have CREDIT CARD NUMBER special authority).
This is essentially the same as existing commands and APIs that require access to the resource and *JOBCTL. In other words, the function acts the same way as a special authority.”
Thanks to Patrick Botz for taking the time to provide background and perspective on the User Function APIs. In the next API by Example column, I will present a sample application based on the methodology described above.
