IBM i is a robust and reliable operating environment. It is still used by many organizations today, especially for data-heavy applications. Over the years, businesses have heavily customized IBM i applications to suit their business processes. Most of these applications, however, run on an RPG code format that outputs to monolithic 5250 green screens. These screens contrast starkly with modern software expectations.
While 5250 green screens are effective, they don’t provide the rich UX-based experience users demand from modern software applications. In addition, because of the knowledge gap and dwindling talent pool of IBM i developers, most organizations run on multiple computing systems. They generally have a different IBM i development team siloed from developers working on other computing systems. This also adds to the complexity surrounding data and application integration within organizations running on IBM i.
Microsoft’s .NET Framework can address these issues by enabling the development of Windows or Web applications that integrate seamlessly with IBM i. Microsoft .NET Framework applications provide end-users with a rich graphical interface that integrates with IBM i databases as well as existing RPG and COBOL programs and stored procedures. While .NET technology provides a solid foundation for building modern graphical IBM i applications, security is always an issue when it comes to developing IBM i .NET applications.
In this article, you’ll learn how to do IBM i modernization by building secure .NET applications.
How is IBM i .NET Security Different From That Of Other IBM i Applications?
Most IBM i applications use menu-level security. This is where code in the application governs the access rights for different types of users of the same application. However, data access mechanisms like ADO.NET and the .NET Data Provider are not governed by the same menu-level restrictions as 5250-based applications. That doesn’t mean .NET access to the IBM i is insecure. It just means that .NET access is controlled by native IBM i object-level security instead of menu-level security. This fundamental difference underscores the importance of planning and implementing your IBM i object-level security.
The authentication mechanism used by the .NET application is another important security consideration. In order to gain access to IBM i resources, .NET applications need to supply authentication information to the IBM i. Applications using ADO.NET and the IBM UDB .NET Data Provider can either use application-supplied authentication or Windows integrated authentication.
Application supplied authentication passes information to the IBM i using a connection string. Unfortunately, it is not the most secure approach. This is because the connection passes user profiles and passwords in an easily intercepted text format. Even though application-supplied authentication may be acceptable for applications on private internal networks, it is not adequate for applications that use public networks. You must encrypt Public network connections to the IBM i using SSL or other encryption technologies.
Alternatively, Windows Integrated Security provides much stronger network security. It never passes authentication information over the network in plain text. Windows Integrated Security sends authentication requests using the user’s current security token. It is a much more secure method because raw authentication information never surfaces on the network. This security technique, however, requires matching user IDs and passwords on both the Windows client application and the IBM i server.
How Can You Secure Your IBM i .NET Applications?
A layered security approach is the best practice for securing your IBM i .NET applications. Layered security better protects your application data by providing a more granular and manageable security implementation. First, at the network authentication level, you take advantage of Windows integrated security. Then, at the transport layer, you make use of data encryption to protect the contents of the data stream between the .NET client application and IBM i. Finally, encrypting the data stream prevents the application user’s authentication information from being intercepted and secures the data exchange between the client and the server.
Object-level Security and the Principle of Least Privilege
At the server level, be sure to use IBM i’s object-level security to restrict user access to objects required only to perform their jobs. This is the “Principle of Least Privilege”. If a security exposure does occur, restricted access limits the intruder’s access to the objects that the application user has rights to use. This prevents the intruder from accessing any other system objects.
Another example of implementing the principle of least privilege in an IBM i .NET application is to use IBM i’s adopted authority to restrict users from direct access to all base tables and only allow access to a set of stored procedures or data access programs. The system objects can then use adopted authority to access the base data tables.
In this approach, the user has no direct access to any system objects other than stored procedures used for data access. The stored procedures or data access programs use IBM i adopted authority to access the base tables used by the application. This helps prevent SQL injection attacks or other exposures that take over the end user’s credentials in order to access unauthorized system data.
SQL injection attacks are based on an attacker entering unexpected SQL commands data into the application’s data input fields. If the connection and application are compromised, the attacker only gains access to the stored procedures in the data access layer. They have no access rights to the application data or any other system objects.
Input Validation
It’s vital to ensure you properly validate all input fields at the application level. Although you might think of input validation as a data integrity measure, it is also a vital security precaution. Proper data validation ensures that all data sent to the database complies with the organization’s business requirements. It also prevents hackers from performing SQL injection-style attacks.
Input validation blocks these attacks. It ensures that any data used by the application meets the expected data type requirements. You should also validate all data in your application to ensure that it meets the expected data type, only contains expected characters, and falls within length and value boundaries. In addition, consider adding encryption algorithms to the application to protect critical data elements like credit card numbers you may store in your IBM i database.
How Can You Connect Your .NET Applications To Your IBM i Resources?
To access your IBM i resources from the graphical user interface of your .NET applications, you need IBM i middleware. LANSA Open for .NET is powerful middleware. It is also Visual Studio plugin that allows Windows developers to access IBM i (AS/400, iSeries) resources (including data and programs) directly from their .NET applications. It also offers easy integration between IBM i and .NET.
With LANSA Open for .NET, IT departments can safely open up their IBM i data and applications to internal and external .NET applications. Most importantly, they can also do it without risking security or data integrity. The result is a better customer or employee experience.
Let’s look at a step-by-step process flow on how your company can modernize with .NET on this IBM guidance.
How Can You Modernize With LANSA Open for .NET
.NET applications run on graphical user interfaces. With LANSA Open for .NET, you can upgrade your green screens to use the .NET graphical user interface. Other benefits of this solution include, but are not limited to the following:
.NET and IBM i Collaboration
This solution allows you to break down application silos and achieve a single version of the truth. You achieve this by enabling .NET and IBM i to collaboratively share real-time data and automate business processes. You can also eliminate synchronization between Windows and IBM i platforms.
Controlled Access to IBM i Data from .NET
With LANSA Open for .NET, IT departments can safely open up their enterprise IBM i data to various internal and external applications without risking security or data integrity. LANSA’s Business Rules Engine also enforces validation logic and ensures that unacceptable data never hits the database.
Faster Transfer of Data and Information
LANSA Open for .NET implements native record-level access to Db2 data over an encrypted, secure connection. Using native record-level access also means .NET applications can quickly work with large volumes of Db2 data by taking advantage of IBM i’s powerful data processing capabilities.
Tighter IBM i Security from .NET
LANSA Open for .NET’s runtime DLL also encrypts and compresses data during transmission between the client and the server. Overall, this protects sensitive data from compromise by sending it down the wire using industry-standard DES or Twofish.
Easier Resource Management of Dev Teams
Reduce the challenges of managing siloed development teams and multi-platform projects by sharing resources between mixed .NET and RPG, as well as COBOL development environments. With LANSA Open, you can reuse the same enterprise business logic, validation rules, and also calculations.
Are You Ready To Build Secure .NET Applications To Modernize Your IBM i?
Microsoft.NET technology provides a productive and powerful set of tools for developing graphical IBM i applications. While LANSA Open enables a secure and seamless connection between .NET applications and IBM i data, enterprise-level application development also requires attention to real-world application development issues, like security. The guidelines presented in this article can help ensure that your IBM i .NET applications meet the security demands of your organization.
To get started with LANSA Open for .NET, request for demo here.
Explore more information about how your organization can use application modernization to accelerate digital transformation in this article: “What is IBM System i?”
0 Comments