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



To secure ReST service calls from a client you generally use something like JWT or OAuth2. There is also SAML but I have not used that.

After successful authentication the user is granted a token. This is passed back and forth in the HTTP header. This token is checked on each subsequent request to ensure the request is coming from an authenticated user.

Thanks,
Todd


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Tim Fathers
Sent: Friday, March 23, 2018 12:32 PM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] REST web service APIs

"For those who favor an XMLSERVICE interface over an API interface, I'm curious how you handle end-user access privileges? XMLSERVICE, ODBC, JDBC, and the like allow clients to execute any SQL statement against any database files, to call any program, to run any command. What is your preferred way of controlling that?"

As I mentioned elsewhere, we don't allow any old SQL statements to run, just stored procedures, these are compiled with USRPRF(*OWNER) and the JDBC connection user profile just has use rights to the stored procedures with no rights at all to the files, so that's the first way in which we limit what the caller can do. For individual user access control we pass an authentication token from the HTTP header to the stored procedure via the SET_CLIENT_INFO() function which the called stored procedure decrypts and tests the validity of, as well as figuring out the ID of the caller and whether they are authorised to the stored procedure and the data it accesses. If the token is missing, invalid or expired then the stored procedure sends an exception which is interpreted by our framework and sent back to the client as a 401 - Not authenticated status. The client then redirects to a login page and the user enters their credentials which are posted to the server. This is again just a si mple stored procedure call which validates the credentials and then sends back a token, which the client stores and adds to every subsequent HTTP request in the header.

I don't want to ramble on too much, but I can give you some concrete examples if you like and the source is all on BitBucket anyway.

________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Nathan Andelin <nandelin@xxxxxxxxx>
Sent: 23 March 2018 17:04
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] REST web service APIs

Nadir,

Thanks for your response. I followed the link that you provided and further linked to the following:

https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ibm.com-252Fcloud-252Fintegration-26data-3D02-257C01-257C-257Cb538754bc53145dd794408d590d7e098-257C84df9e7fe9f640afb435aaaaaaaaaaaa-257C1-257C0-257C636574179209041864-26sdata-3D399oqkrfPLLaLjiF-252BFAeZb9bztx8ykov0xiZHDHjnoU-253D-26reserved-3D0&d=DwICAg&c=3QPdAeI_27D-X5fMaNWjvHSofEG0N1gL0BDpYdYg7W4&r=Bu367CgFas-85fVvOuX4zDovctcZsBvjNKPdTZs6lMg&m=EXcbPtseX3AzHAmT1svtuo3E0OoZO9xZ8jj1J9IZLVk&s=3kE7_hfmiVyEVmw4ykQq8LQtYPC-MdoOgFghiPfHvE8&e=

Halfway down that page there is a link to a 3 minute video with the following text:

"Learn how Walmart is building a platform driven by APIs to provide its developers with a self-service portal that supports faster development and helps Walmart deliver new services and improvements at the speed of business."

The technicians at Walmart briefly discuss the benefits of their API architecture. That intrigued me because we've had some shallow comments on this list this past week about Walmart using Node.js for a high-volume shopping site. That video suggest that there is a lot more to the story than just switching to Node.js.

For those who favor an XMLSERVICE interface over an API interface, I'm curious how you handle end-user access privileges? XMLSERVICE, ODBC, JDBC, and the like allow clients to execute any SQL statement against any database files, to call any program, to run any command. What is your preferred way of controlling that?

With APIs, I envision a service that checks a list to see if users have been granted authority to an API, and providing an appropriate error message if otherwise.

Nathan.


On Fri, Mar 23, 2018 at 8:35 AM, Nadir Amra <amra@xxxxxxxxxx> wrote:

Hi, it is a viable alternative. There are multiple ways to do this and
you may choose the best one that suits your needs. I will also point out
that integrated web services server[1] documents it services via Swagger.


[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.p
rotection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.ibm.com-252Fsupp
ort-252Fdocview.wss-253Fuid-253Disg3T1026868-26data-3D02-257C01-257C-2
57Cb538754bc53145dd794408d590d7e098-257C84df9e7fe9f640afb435aaaaaaaaaa
aa-257C1-257C0-257C636574179209041864-26sdata-3DHJsR37r4QpmpgEPF-252FA
qOaZSnZ1mjurfm3-252FsvyfMmcUY-253D-26reserved-3D0&d=DwICAg&c=3QPdAeI_2
7D-X5fMaNWjvHSofEG0N1gL0BDpYdYg7W4&r=Bu367CgFas-85fVvOuX4zDovctcZsBvjN
KPdTZs6lMg&m=EXcbPtseX3AzHAmT1svtuo3E0OoZO9xZ8jj1J9IZLVk&s=-EKtBY9JCMU
ahPAL4yVQDQ12OsnGetiw7EVy7HVAodo&e=


For More Than 85 Years—Delivering Solutions That Exceed Expectations.

This communication and any transmitted documents are intended to be confidential. If there is a problem with this transmission, please contact the sender. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

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.