Hi Brad,

Here's a scenario that I might face. 

I need to develop a web page that will only run inside our firewall. The web page will allow all employees to change their home address, phone number, and email in our human resources system. Our human resources system is on the IBM i.  About half of our employees have IBM i user profiles, and we are very unlikely to create IBM i user profiles for all employees.

So...
1. The web page sends a request to an Apache web server running on the IBM i.
2. The web server routes the request to a COBOL CGI program that processes the request.
3. The web server returns the response from the COBOL CGI program to the web page.

My thought is to use LDAP authentication in the IBM i Apache web server to confirm it's a legitimate employee. We already have an LDAP set up, and we use it as part of our SSO solution for 5250 user interfaces. 

But how do I handle user sign on to access the CGI COBOL program and the DB2/400 file that gets updated?

Thanks,
Kelly

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Bradley Stone
Sent: Thursday, May 14, 2015 12:34 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] IBM i authentication and RESTful web service design

Kelly,

>
> 1.       Am I mistaken that stateless communication requires clients to
> pass user credentials on each request to the server? If not, how do 
> you avoid passing user credentials on each request while keeping all 
> session information on the client? Maybe I'm missing something 
> obvious. (I'm still a newbie in this area.)
>
>
If credentials are required (ie, Basic authentication, session cookies, OAuth 2.0 credentials, etc) then yes, each request needs to send them.


> 2.       What kind of performance hit, if any, does one take by having to
> pass user credentials with each request to the IBM i?
>

Not much.  More of the processing of credentials is done on the server side.  When you're sending credentials it's normally just some soft of "string" in the request headers (to be very generic).


>
>
> 3.       Does anyone have suggestions from personal experience, or know
> some good resources to read, regarding user authentication for web 
> services built on RPG/COBOL CGI programs?
>

"User Authentication" here is very general.  Each web service you interact with may require different types of authentication (or possibly none at all).  So you really need to take it on a case by case basis.

With our GETURI software we've used it for many different types of communication (OAuth, Basic, session cookies, etc).

I hope this helps.  Your question is sort of broad.  If you have a specific web service you want to communicate with, the specs should tell you how you need to do this.

Here's a link to Google OAuth playground that lets you see how OAuth 2.0 works with their APIs:
https://developers.google.com/oauthplayground/

Then again remember, this is only one type of authentication being used.

Brad
www.bvstools.com


>
> Thanks,
>
> Kelly Cookson
> IT Project Leader
> Dot Foods, Inc.
> 1.217.773.4486 ext. 12676
> kcookson@xxxxxxxxxxxx<mailto:kcookson@xxxxxxxxxxxx>
>
>
> --
> 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.


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.