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



Thanks Scott,

Very useful information.

Thanks,
Kelly

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

Kelly,

If you have SSO already set up (such as LDAP, etc) then you can configure Apache to use it.  You would add something like this to your config file for LDAP support:

LoadModule ibm_ldap_module /QSYS.LIB/QHTTPSVR.LIB/QZSRVLDAP.SRVPGM

<DirectoryMatch "^/QSYS\.LIB/YOURLIB\.LIB/[a-z0-9]*\.PGM">
     LDAPConfigFile /www/YOUR-HTTP-INSTANCE/conf/ldap.prop
     PasswdFile %%LDAP%%
     AuthType Basic
     AuthName "Kelly's Service"
     Require valid-user
</DirectoryMatch>

With this, Apache will accept any userids in the LDAP server to sign on. 
  Your application would use the EIM APIs to find the "actual" userid to use on the IBM i side of things, if that's necessary.  You don't have to have userids for every user if you don't want, you can use EIM to map your userids to a generic user profile on the IBM i side if you want.

To answer your questions:

1) True if you want to be 100% perfectly stateless, you'd send the credentials each time.  If you use the above method, you'd do that using basic authentication, which is supported automatically be all web browsers.

If you don't like the credentials sent on every request (the main problem with that is security.  If you're not using SSL/TLS to encrypt the session, the more times you send the credentials, the more likely they'd be intercepted...)  Then you could do something like generate a unique session ID on the first request, and then re-send that with each subsequent request.  That's not 100% stateless, and would require a lot more work, but it does give you more control over how the authentication process works (because in this case you would not let Apache handle it, you'd do it all yourself i your Cobol or other HLL code.)

But, from what I've seen letting Apache handle it suffices for most business applications.  And using SSL/TLS protects the contents, so the danger of being intercepted becomes a non-issue.... and it's a lot easier that way.

2) I'm sure there must be some performance hit, since it has to look up the credentials with each request -- but, honestly, it's been so fast for me that I have never noticed it.

Good luck



On 5/14/2015 12:24 PM, Kelly Cookson wrote:
> I am trying to understand in-depth how to develop RESTful web services using CGI programming on the IBM i.
>
> I am using Fielding's dissertation (https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf) as my primary source for what constitutes REST architectural constraints. One constraint is statelessness. On pages 78-79 of his dissertation, he writes:
>
> "We next add a constraint to the client-server interaction: communication must be stateless in nature...such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client."
>
> "This constraint induces the properties of visibility, reliability, and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests."
>
> The IBM i requires every person or system that accesses it's resources to provide a user name and password. Consequently, it seems to me the client has to store credentials associated with a session, so the user doesn't have to fill out  a new login form for each request to the server. It also seems to me the client has to pass user credentials within each request it makes to a web service on the IBM i that uses CGI programs.
>
> Here are my questions:
>
>
> 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.)
>
> 2.       What kind of performance hit, if any, does one take by having to pass user credentials with each request to the IBM i?
>
>
> 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?
>
> 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.


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.