× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



​>Management now wants to have an outside firm with more web design
expertise to manage and maintain the presentation layer, so my challenge is
how to accommodate that

This piqued my curiosity. What language is the web design company
developing the front-end site in?

Aaron Bartell

On Tue, Feb 3, 2015 at 7:24 AM, Koester, Michael <mkoester@xxxxxxxxxxxxx>
wrote:

Thanks Nathan.
The current situation has the scenario you described -- the web site we
developed in 2007 using ASNA's AVR.net with their DataGate interface to the
database has handled all that quite nicely. All access was through a https
URL.

Management now wants to have an outside firm with more web design
expertise to manage and maintain the presentation layer, so my challenge is
how to accommodate that. Where we had a very tight integration with the
database, we will now be passing the required data elements on request to
the outside firm to use to manage the site navigation. When an action
requires posting a settings change (payment account details, auto-pay,
paperless billing) or a payment commitment, I'll handle those with web
service operations that update our database or post the payment and return
a confirmation number.

The session (for my purposes) begins with the request for the data
elements pertaining to an account. Subsequent calls to the "post"
operations include the account number and session number, and are matched
by my programs to the most recent session established for that account.
I'm anticipating those requests to follow generally within a few seconds to
a few minutes of the data request, but will probably consider the session
to be expired in an hour (I keep timestamps when the session IDs are
established). I plan to discuss the particulars of reasonable "timed-out"
expectations with the website people.

I just need to understand what needs to be done to protect the customer
data in transit, and to ensure that the web server is the only way in.

Thanks again,
-- Michael
~~~~~~~~~~~
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan
Andelin
Sent: Monday, February 02, 2015 6:19 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Security for web site accessing i via IWS

Just a couple quick points. It sounds like your interface would be more
streamlined if both your web site and your web service were running on
the
same server, and that security would be easier to establish and maintain
thereby. You might also consider how to expire your sessions, and what to
do after that.





On Mon, Feb 2, 2015 at 10:20 AM, Koester, Michael <
mkoester@xxxxxxxxxxxxx>
wrote:

Seeking advice on security to and from a web site and the IBM i
database...
I'm developing the back-end web services to support a redesign by a
business partner of a website used for Bill Presentation and Payment.
Customers' account details, including payment account info, are to be
inputs to the web service, and obviously need to be secured as they
traverse the communications links. I need to know that what I'm doing
is sufficient -- at least that I've made what is a reasonable effort
to protect customer data.

My web services use the IBM Integrated Web Services (IWS), calling i
7.1 RPG programs to retrieve and update our i database, and staging
committed payment data for ACH transactions. PTF's for HTTP and IWS
are
current.

Here are the elements of my design:
1) The web site will be accessible to the user via SSL. This will be
the responsibility of the web site developer.
2) All traffic to and from the IWS operations will use SSL, with a
self-signed certificate provided by our SysAdmin to the web site
developer.
3) The web site developer is responsible for user authentication prior
to calling the web service operations.
4) When a user is authenticated, the web site script makes a call
using SSL to a web service operation to retrieve the details of the
customer account.
5) My RPG program that retrieves the account details generates a
10-digit "SessionID" which is returned with the account data to the web
site.
6) Calls to subsequent operations (PostSettingschange and PostPayment)
by the web site must include that SessionID, which I use to log the
session activity to a log file, and to track what data has been sent
to the web site.

I'm sure that there are no absolute guarantees of security, and that
there may be a myriad of expensive add-ons to make the process
incrementally "more secure", but have I missed something that would
make my plan irresponsibly inadequate? Are there things about SSL
that I need to check to ensure that SSL flaws exposed last summer have
been remedied? What are other shops doing to handle these concerns?

Many thanks.
Michael Koester
Programmer/Analyst
DataEast


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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 [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.