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



This is where something like OAuth comes in nice as long as its an option.
I've been seeing a lot of web services moving that way for security
(FitBit, Google, Microsoft, etc).

We've put together applications for customers that require connections
using OAuth 2.0 with different providers but never set it up on the server
side (which it sounds like is part of your application).

Brad
www.bvstools.com


On Mon, Aug 17, 2015 at 1:58 PM, Koester, Michael <mkoester@xxxxxxxxxxxxx>
wrote:

I developed a SOAP web service a few months back and had similar security
concerns for what was to be a "private" service available only to a
business partner who is developing and supporting a web site application.
It's not yet in production (awaiting someone else to make some decisions),
but the security elements have been approved.

Our web service operations comprise the back-end processing for a Bill-Pay
web site for a Telecom, and involves a series of requests from the web site
script to the web services on the IBM i host as a customer navigates
through committing a payment. The website itself has the
customer-authentication routines, but to thwart someone from accessing the
host web services directly, the requests must carry some key elements that
match what's in the host database. And ours requires a self-signed SSL
certificate, and VPN access through the firewall.

I don't know if your application has elements that the caller must "know",
but mine requires a phone number, account number, and email address to be
passed with the initial request. If that combination does not match active
records on the host, a fail code and message are returned from the web
service.

If everything is cool, the web service returns a unique sessionID number,
which must accompany each subsequent call to the web service for that
"session". If a call to any operation does not carry that Session ID, it
fails. And the sessionID times out after a certain number of minutes since
last activity.

A thread in this list back in early February may give you some additional
considerations and suggestions:
http://archive.midrange.com/web400/201502/msg00000.html

Hope this helps in some small way.

Michael Koester
Programmer/Analyst
DataEast - Granite State Communications

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of p.Caroti
Sent: Monday, August 17, 2015 1:42 PM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] put in safety my Rest Web Services

Hi



I have written and published some web Services to send and receive data
from App (Android and iOs) ; at this moment anybody that know System I
ip
address and web service name could send and receive data from my System
i.
My question is how could protect the Web Service's call . I was thinking
to a dynamic password linked to date and time passed as parameter in uri
..
Which technique do you use in this situations ?



Thanks in advance


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

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.