Re: Security for web site accessing i via IWS

Opinion and unbridled honesty warning....

It is amazing to me that in 2015 businesses are still taking this approach
to their next generation of technological viability, which inherently is
business viability. This approach of having such disparate teams will
significantly slow anything produced with this technology stack and the
business will immediately be at a disadvantage to the competition. The
next real competitive advantage is how fast a business can deliver features
and not just delivering "keeping up with the Jones'" technology. Everybody
has technology at this point, but not everybody can move fast because that
takes very careful selection of a technology stack.

The only thing gained is a pretty interface, and that will satisfy
customers for awhile, but only for so long. Soon customers will start
asking why their requested features are taking so long to procure. They
will then point at your competition and comment on how they are progressing
much faster.

One final comment. Of all parts of the stack, the UI layer
(HTML/CSS/Javascript) is the easiest to have on the IBM i because none of
it actually runs on IBM i and instead it is only delivered by the IBM i.

I hope I didn't offend you personally, I just wanted to provide feedback
based on my experiences with many web projects over the years.​

Aaron Bartell
​
KrengelTech
Litmis Team - litmis.com​

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

Hi Aaron.

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

Sorry to say, I don't know... I'm fairly certain they have no familiarity
with IBM i. Most of the contact with that firm has been by mgmt and
marketing. There's supposed to be a meeting where I get to meet with
either a developer or project mgr (probably a joint meeting with marketing
and mgmt), but that hasn't yet happened.

I established awhile back that I would develop web services that would
return an XML document with all the data elements needed for a customer to
navigate the site. I will provide them with a design document describing
what they need to do to request data, and the specifics of the data
elements and types I return. They would take it from there to design a
site that is functionally equivalent to the one currently in use.
Additional features and function are planned, but have not yet been
designed with any detail.

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Aaron
Bartell
Sent: Tuesday, February 03, 2015 8:31 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Security for web site accessing i via IWS

​>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.

--
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.

--
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.