I see much positive value in front-ending an IBM i server with one or more network "appliances" to handle packet routing, firewall, encryption, proxy, cache, denial-of-service prevention, and such.
But I see negative value in front-ending an IBM i server with another application server. It's better to centralize application security under IBM i. Distributed application architecture is harder to develop, more prone to failure, harder to secure, more prone to bottlenecks, harder to analyze and correct performance problems, generally requires multiple or extended skill sets.
You seem to imply that bank customers would need an IBM i profile if your application were centralized and hosted entirely under IBM i, but I don't see a requirement for that. You might have your application authenticate users, and define their access levels, rather than having IBM i do that. My Web portal does that - though there is an option to authenticate against an IBM i profile, if desired.
----- Original Message ----
From: "elehti@xxxxxxxxxxxxxxxxxx" <elehti@xxxxxxxxxxxxxxxxxx>
Sent: Friday, August 14, 2009 1:37:53 PM
Subject: protecting your public-facing, web-enabled IBM i from hackers
My question to all of you who have public-facing, web-enabled IBM I
machines run your core applications.
How do you secure this machine against possible hacking attempts from
If your website has web apps like self-service for your customers and
suppliers, allowing people to inquire on data that resides on your
system, how do you protect?
Or do you keep your system off the internet, and web-enable a secondary
file-server machine instead?
I am aware that thousands of banks and credit unions running their
[censored] core banking applications on the IBM I use a "middleware web
server" that acts as a conduit between the bank customer web page and
the System I, thus enabling banking customers to transact their banking
business without needing a different IBM user profile for each bank
customer. The RPGIV programs running on the System I send and receive
customer-specific information via data queues out to the middleware web
This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact