Exposing RPGLE as Webservices - Security Considerations

Secure IBM i files so webservices can read and serve data safely, reliably, and with minimum fuss. 

This lesson covers object authorities, a dedicated service account, least-privilege SQL access, transport protection, encryption, auditing, and operational best practices. All explained with practical examples and some cheesey programmer humour to keep the code from feeling lonely.

Learning Objectives

  • Understand how to structure library and object authorities for webservice-accessible files.
  • Create a dedicated service profile with least-privilege access.
  • Implement SQL views and stored procedures to limit exposure of base files.
  • Apply transport-layer protections and gateway patterns for API access.
  • Enable encryption and auditing for sensitive data.
  • Follow operational controls for credentials, rotation, and monitoring.

You will need some basic familiarity with IBM i object authorities (WRKOBJ, GRTOBJAUT, CHGAUT) and the ability to run SQL on the system (STRSQL, Run SQL scripts). Or you can simply be a brave developer willing to argue with a green screen.

Our web services fetch ingredient details from FOODFILE to power recipe APIs. That file tracks items like 'Tomato with 250 grams expiring November 1, 2025'.

Let's look at the essential techniques to secure it today. We will restrict read access to a specific service profile. We will track every database query.

These steps lock down access. You dodge the classic "oops, the whole pantry spilled online" blunder.

First, let's review Library and Object Authorities:

If you did the previous lesson, you have created a dedicated library for webservice files and placed only web-facing files in there.

Next, you need to remove PUBLIC access from the library and files; grant only the service profile and administrators the required authorities. Then use commands to set and inspect authorities: GRTOBJAUT, CHGAUT, WRKOBJAUT.

Rule of thumb: if anyone can type WRKOBJ and laugh, you’ve given too much access.

Dedicated Service Profile

Some simple rules to remember:

  • Provision a dedicated user profile for the webservice; do not reuse admin or personal accounts.
  • Grant the profile the minimum object authorities needed (typically R for read-only endpoints).
  • Avoid powerful special authorities like ALLOBJ and SECADM for the service account.
  • Store credentials securely and restrict sign-on and network access for the profile.

QTMHHTTP is the default HTTP server runtime user profile on IBM i and is the account under which the HTTP server and its worker jobs run by default. We will be using QTMHHTTP for our code examples.

SQL Layer: Views and Stored Procedures

For this example, we are serving up the data via our RPGLE program (to be created in the next lesson) but you might want to expose your file directly allowing SQL access for example.

Remember to expose only what the webservice needs using SQL VIEWS; grant the service profile access to the view, not the base table. Encapsulate business rules and access filtering inside stored procedures or parameterized queries.

Example pattern:

  • Create view: CREATE VIEW VW_FOOD_PUBLIC AS SELECT INGID, INGNAME, CATEGORY FROM FOODFILE;

  • Grant view: GRANT SELECT ON VW_FOOD_PUBLIC TO SERVICEUSER;

The obvious benefit here is, using this technique reduces risk if the web layer is compromised — the attacker sees only a polite subset of your data.

Transport Security and API Gateway

Require HTTPS for all webservice traffic and terminate TLS at a trusted gateway or load balancer. Use token-based authentication (OAuth2, JWT) or mutual TLS for service-to-service calls.

Put the IBM i behind an API gateway or reverse proxy to centralize authentication, rate-limiting, IP allowlisting, and WAF rules.

Practical tip: the gateway should be the bouncer; IBM i stays in the VIP lounge.

Data Protection and Encryption

Encrypt sensitive columns at the application layer or use DB2 column-level encryption if available.

Use system-level disk encryption for libraries holding sensitive PFs when required by policy.

Manage encryption keys in a secure key-management service; do not hard-code keys in RPG or Node code.

Auditing, Logging, and Monitoring

Enable object and SQL auditing for read, update, and authority changes; capture the service profile in audit records. Consider forwarding logs to a centralized SIEM or log store for correlation and alerting. You should also schedule regular authority reviews and run reports to detect unintended grants.

In my view, logging is great until it becomes your new full-time job; tune what you collect.

Operational Controls and Secrets Management

Rotate service credentials regularly and enforce strong password policies. Use short-lived tokens where possible and revoke immediately on suspected compromise.

Keep production testable in an isolated test library. And you don't need me to remind you to never test destructive scripts directly in production.

If you are not using a change management tool, you will need to automate provisioning of the service profile and grants via your deployment scripts to keep environments consistent.

If an IBM-i library has *PUBLIC *EXCLUDE but the objects in it have *PUBLIC *READ - who can access objects in that library?

Users can open and read an object in that library only if they can reference the object successfully and the object authority grants them read access. Object-level authority is what controls actual open/read access, so *PUBLIC *READ on the objects allows any user to read those objects if they can reach them.

Important practical details

  • A user must be able to name the object (for example by having the library on their library list or using the fully qualified name LIB/OBJ) for the system to attempt object-level authority checks.
  • *PUBLIC *EXCLUDE on the library prevents users from seeing the library contents with commands that list libraries/objects and may block non-qualified access methods that rely on library-list discovery.
  • If a user cannot reference the object (library not in their library list and they don’t use LIB/OBJ), they effectively cannot access it even though the object is *PUBLIC *READ.
  • Special authorities and profile settings still apply; users with *ALLOBJ or an authority that bypasses normal checks can access regardless of these PUBLIC settings.

Rule of thumb -- Library-level *PUBLIC controls discovery and implicit access via the library list; object-level *PUBLIC controls actual read/open permission. Both matter for practical access.

Example Snippets

View current rights on FOODLIB and the /FOODFILE with DSPFTR FILE(FOODLIB/FOODFILE). Use WRKOBJAUT/GRTOBJAUT/CHGAUT to remove PUBLIC and grant SERVICEUSER *READONLY access to FOODFILE.

Let's see what we have by default, after creating our library and file:

EDTOBJAUT OBJ(FOODLIB/FOODFILE) OBJTYPE(*FILE)
Exposing RPGLE as Webservices - Security Considerations 1

We want to block anyone from accessing our file, with the exception of the user that will be connecting via our webservice. We will be using the default webservice profile  QTMHHTTP so we will exclude *PUBLIC and allow *READ for QTMHHTTP:

GRTOBJAUT OBJ(FOODLIB/FOODFILE) OBJTYPE(*FILE) USER(*PUBLIC) AUT(*EXCLUDE)

Nobody reads now. Allow *READ for QTMHHTTP, the HTTP profile: 

GRTOBJAUT OBJ(FOODLIB/FOODFILE) OBJTYPE(*FILE) USER(QTMHHTTP) AUT(*READ)

You should now have a file that is secured so that only USER(QTMHHTTP) is allowed access. In my system I also allow my personal user account to have access:

Exposing RPGLE as Webservices - Security Considerations 2

Alternate setup using an SQL VIEW

Using an SQL VIEW to expose an IBM i physical file to a webservice reduces the attack surface and centralizes access control, filtering, and auditing for service traffic

Security Benefits

  • Least privilege exposure — A view exposes only the needed columns and rows so the webservice never sees sensitive fields.
  • Column and row filtering — Views remove sensitive columns and implement row-level filters so multi-tenant or scoped data is enforced in the database layer.
  • Controlled surface for grants — Granting SELECT on a view to a service account keeps base table grants unnecessary and rare.
  • Encapsulation of business logic — Stored logic in views and procedures prevents business rules being reimplemented insecurely in the web layer.
  • Auditability — Auditing reads against views yields clearer, higher‑level intent for logs than raw table access.
  • Simpler key management for masking and encryption — Encrypted or masked columns remain in the base table while the view returns safe, unencrypted representations to the web tier.
  • Defence‑in‑depth — Views combine with object authority, transport security, and API gateway controls to add an extra protective layer between the internet and your data.

Grant view access:

CREATE VIEW FOODLIB/VW_FOOD_PUBLIC AS SELECT INGID, INGNAME,
CATEGORY, MEASURE, QUANTITY FROM FOODLIB.FOODFILE;

GRANT SELECT ON FOODLIB.VW_FOOD_PUBLIC TO QTMHHTTP;

Additional Best Practices

  1. Use stored procedures or parameterized queries that call the view for any complex access patterns.
  2. Implement row-level security by embedding WHERE clauses or using table functions that filter by tenant or caller identity.
  3. Combine view grants with strict object authorities on the library and objects so discovery and implicit access are limited.
  4. Ensure transport security and authentication are enforced at the API gateway before requests reach the IBM i server.
  5. Audit SELECTs on the view and alert on anomalous patterns.

In summary, you are trying to expose a polite, well-behaved window into your company data with a view, not a blunt instrument, and your database will thank you in fewer helpdesk tickets

Done?
 Mark lesson complete
Previous Lesson
Next Lesson
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>