We are currently using IMS V9 and Web Application Servers on Unix that
connect to IMS Connect. To ensure that only trusted WAS machines connect
to IMS Connect, we have written a security exit in IMS Connect that
basically just checks every incoming IP-address. The allowed IP-addresses
are hardcoded in a table.
We are now revaluating this security design []
That's probably prudent, Jan, so it's good to hear you're looking at that.
It's easy to spoof IP addresses, and obviously hardcoding IP addresses
leads to a maintainability issue. There's also the not-so-minor issue of
vulnerability to interception of unencrypted IP traffic across a network.
[] and one of the things that
come into scope is SSL for IMS Connect. SSL could be used to validate the
client by exchanging certificates, public and private keys.
These questions pop up:
Are there people amongst you who already do SSL with IMS Connect?
Experiences to share?
Performance issues to look after?
Make sure you take maximum advantage of the crypto hardware inside your
mainframe. (That'll vary according to which model you have.) It's there,
so it's obviously worth using.
Gotchas?
Any other special considerations we need to pay attention to?
Other (better ?) alternatives?
I can think of one alternative which should be rather easy to implement,
and that's to place at least your IMS access EJBs/servlets (and probably
also related business logic EJB/servlets) directly on WebSphere
Application Server z/OS. You'll avoid the need to encrypt (much or at all)
-- you'll have in-memory transfers -- and your WebSphere Application
Server instances can depend on any SAF-compliant security engine (RACF, as
the notable example) for its authorization and authentication. (You get
full security controls through the entire data/transaction access path if
you need/want it.) Everything gets WLM managed, the WAS processing is zAAP
offloadable (thus extremely cost effective), you have z/OS reliability and
availability, your response time will be better (and more predictable),
you can scale up and down instantly to meet business demand, and you will
reduce stress on IMS. (Whether there's a net reduction in CPU is another
question, but IMS at least will work less hard servicing these in-memory
requests. I could imagine many cases where there would be a net reduction
in total CPU compared to connecting remotely via encrypted IP.)
If you're an IMS DB shop then you get the added advantage of being able to
use the IMS JDBC driver -- i.e. provide a JDBC interface to IMS using WAS
z/OS as the intermediary. (WAS z/OS is required for this option.) That's
true as long as you run at least some WAS z/OS in the same LPAR as IMS DB.
WAS z/OS should be quite comfortable if you have WAS experience on other
platforms -- the deployment, management, etc. is vastly more similar than
different, and the code compatibility (APIs) are 100%. (Well, OK, there
are APIs on z/OS like JRIO for accessing mainframe VSAM and QSAM, so I
guess you could say that WAS z/OS is 105%. :-)) The manageability would
likely be improved: easier to identify and remedy performance bottlenecks,
for example. That would avoid some of the finger pointing that goes on
in many shops (IMS is down / No, it's not -- you're down). There are
probably some operational benefits, too, like closer synchronization
between WAS and IMS availabilities (and more graceful mitigation thereof,
such as offlining WAS first and more reliably, and onlining IMS first)
if you don't operate your IMS continuously online. Disaster recovery is
much nicer (and much cheaper), and you open up some interesting options,
like running all your critical WAS applications on z/OS during a DR event
even if you don't run (yet?) everything on z/OS at normal peak production
hours.
You will also have whiter teeth, a healther complexion, and reduced risk
of osteoporosis. :-)
A half step in this general direction (IMS and WAS combination) would be
WebSphere Application Server running on Linux on z. You get HiperSockets
connections there, but the JDBC capability would be missing (different
LPAR). Also very cost effective (i.e. IFLs).
There are other alternatives farther afield, but these two merit first
mention.
Hope that helps!
- - - - -
Timothy F. Sipples
Consulting Enterprise Software Architect, z9/zSeries
Tokyo (Serving IBM Japan and IBM Asia-Pacific)
E-Mail: [EMAIL PROTECTED]
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
