IBM i API security has become a critical concern as organizations expand their integration strategies. Many IBM i teams unknowingly compromise their system security through outdated IBM i access authentication practices. The most concerning vulnerability? Using and storing IBM i credentials for IBM i access from other systems is a practice that creates multiple security risks for your entire system.
Understanding Security Risks
The Danger of IBM i Access Using Native IBM i Credentials from Non-IBM i Systems
Oftentimes, organizations provide access to their IBM i through ODBC connections from Windows or Unix systems. They might start by limiting that access to only certain rows and columns of specific tables. However, experience shows that the outside users often get impatient with waiting for the access they need and are eventually given *allobject authority or some other similar broad access to the IBM i. That means there will be native IBM i credentials with high levels of authority floating around the network on non-IBM i systems stored in plain text.
Sending credentials with every connection creates additional security risks. Even when these connections only travel across internal networks, compromised local machines can intercept the credentials. If malicious actors obtain these powerful system credentials, they can cause severe damage to your organization.
Access via 5250 Terminal Emulators can also be Problematic
Should a bad actor obtain credentials to the IBM i, they could access the system via a 5250 emulator. Or, an internal user could access the IBM i using someone else’s credentials.
Modern Security Solutions
Replacing Direct IBM i Access with API-based access
These and other IBM i credential-based security vulnerabilities are mitigated by creating a secure API layer around the IBM i. Providing access via an API creates a significant barrier that thwarts potential bad actors.
Using an API Layer to Implement Multifactor Authentication
You can use an API layer to verify that a user signing onto a 5250 session via a terminal emulator is who they say they are by demanding an additional identification method. When a user signs on, the system can automatically kick off an initial job that calls the multifactor identification API. The sign-on is denied if the multifactor identification fails (e.g., the user fails to respond to a text message or other MFA technique). You can use this technique to automatically call multifactor and third-party verification systems like Auth0, OKTA, DUO, and others so the IBM I can be integrated with your enterprise’s MFA strategy.
Using an API Layer to Implement Modern Authentication Alternatives
Today’s security landscape demands more sophisticated approaches to API authentication. Modern solutions leverage several key technologies:
- Token-based authentication
- OAuth2 integration
- Encrypted token support
- Multifactor Authentication
These technologies provide significant advantages over traditional credential-based approaches. Modern authentication systems use temporary, revocable tokens that provide limited, specific access instead of transmitting sensitive credentials with each call.
Importantly, by using these techniques, you are not providing outside users with native IBM i credentials. Even if a bad actor could obtain the credentials, they would only be able to access the API, not the IBM i. If you use multifactor authentication, IP Address whitelisting, or other limiting technologies, the bad actors will be unable to use the credentials.
Using an API Layer to Provide Limited Access
The API layer also gives you a place to limit what information the user can access. The rows, columns, and tables they see can be strictly controlled by their sign-on information. Since they will not have IBM i native credentials, they cannot access any data or programs to which they are not given access via the API.
Security Implementation
API Monitoring for Security Issues
By funneling all communication to the API layer, all communication can be easily monitored and controlled.
- The API can automatically shut down or alert security personnel when detecting sudden traffic spikes.
- The API layer automatically denies requests from unknown or blocked IP addresses.
- During denial-of-service attacks, the system throttles traffic and automatically notifies appropriate personnel.
- After detecting multiple failed authentication attempts, the system blocks IP addresses and notifies staff.
Best Practices for Secure API Authentication
Based on our experience with enterprise API implementations, here are critical best practices for secure API authentication:
Never Store IBM i Credentials
- Use tokens rather than native IBM i credentials. They should be stored in memory, not on disk
- Issue temporary tokens that you can quickly revoke if compromised
Implement Modern Security Protocols
- Use up-to-date TLS protocol versions
- Employ secure cipher suites
- Always use HTTPS, even for internal network communications
Adopt Zero Trust Principles
- Authenticate and encrypt all communications
- Don’t trust internal network security alone
- Treat all access attempts as potentially hostile
Monitor and Track All Activity
- Implement comprehensive logging of all API calls
- Track authentication attempts and failures
- Maintain detailed audit trails
Modern Solutions and Future Planning
Modern API security solutions take a fundamentally different approach to protecting your IBM i systems. Instead of relying on stored credentials, they:
- Generate secure tokens that are valid only for specific operations
- Store tokens in memory only until they expire
- Support integration with enterprise-wide security systems
- Provide detailed tracking and monitoring capabilities
The Path Forward
As we move toward increasingly interconnected systems, protecting your IBM i credentials becomes more critical than ever. Organizations need to:
- Assess their current API authentication methods
- Audit and monitor potential credential exposure points
- Plan migration to modern authentication methods
- Implement comprehensive security monitoring
Taking Action
Review your current API authentication practices and ask:
- Are you storing IBM i credentials at external locations?
- Do your API calls transmit credentials?
- Can you track and monitor all API access attempts?
- Are you using modern security protocols for all communications?
The answers to these questions will help you identify potential vulnerabilities in your current system and guide your path toward more secure API authentication. Remember, in today’s security landscape, protecting your IBM i credentials isn’t just about preventing unauthorized access – it’s about ensuring the long-term security and viability of your critical business systems. The security of your IBM i systems is too important to risk with outdated authentication methods. As API usage continues to grow, now is the time to ensure your authentication practices meet modern security standards.
Ready to enhance your IBM i API security? Contact our team at Eradani to learn how we can help implement modern, secure API authentication that protects your critical systems while enabling seamless enterprise integration.
Want to learn more about IBM i integration security? Check out my previous blog, IBM i MFA Security: Breaking Down Enterprise Integration Barriers.
