Re: IBM i authentication and RESTful web service design

I think that you are mixing things together, what you want is a web-service
that may run STATEless that is a complete other thing and not a REST
service in the original definition that uses HTTP PUT, POST, GET and
DELETE. The Original REST definition is seldom used today because only POST
and GET is normally used in web-services.



What you should do is to create a web-page where the user signs in with
their employee number and a password. The passwords you can put in a
Validation List or better in a File with the employee number as primary
key. The password can easily be hash-encrypted in the File.



When the user signs in the program generate a webpages with a form with
fields on current values from the employee master but this form also has a
hidden field that contains a salted hash-value based on the employee
number. The salt can be more or less sophisticated depending on the
security level you wish, that is the salt can have a fixed value (hardcoded
in programs) or can be stored in the file with the password so it is
individual for each employee.



When a change comes in the web-service that does the changes to the
employee master recalculates the salted hash-value and checks it against
the received hash-value passed from the form and reject the request if they
doesn't match.



The method is simple and it is secure and there is no need for cookies or
anything else and is solely based on using the QC2LE/Qc3CalculateHash
sub-procedure and can easily be expanded to work only within an active
timeframe such as changes may only occur 15 minutes from initial logon.


The password file could look like


- Employee number (key)

- Password Hash Value

- Current Salt Value (set for each login)

- Timestamp for Current Salt



I could make a more in debt description if anybody is interested because it
can also be used to validate server to server conversations.



On Fri, May 15, 2015 at 7:34 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

> Hi Nathan,
>
> Don't feel badly. You pushed me to learn more about the terms and concepts
> of web services. I found an interesting Web Services Glossary published by
> a W3C working group (http://www.w3.org/TR/ws-gloss/). Here is what it
> says about web services:
>
> "There are many things that might be called 'Web services' in the world at
> large. However, for the purpose of this Working Group and this
> architecture, and without prejudice toward other definitions, we will use
> the following definition: A Web service is a software system designed to
> support interoperable machine-to-machine interaction over a network. It has
> an interface described in a machine-processable format (specifically WSDL).
> Other systems interact with the Web service in a manner prescribed by its
> description using SOAP-messages, typically conveyed using HTTP with an XML
> serialization in conjunction with other Web-related standards."
>
> I believe this is the way you are using the term web services. This is
> also why my use of the term was confusing.
>
> To help myself think about the definitions in the glossary, I decided to
> use terms from the glossary (as best I understand them) to explain what I'm
> trying to do and what my original questions were. Here goes:
>
> I am interested in developing web applications comprised of two main
> architectural components: a client, and a server.
>
> The client component consists of a definable set of HTML files, CSS files
> and JavaScript programs that run in a web browser.
>
> The server component is comprised of the following architectural
> components: a web server, a CGI program, and one or more data resources
> (e.g., DB2/400 database files, IFS stream files, data queues, data areas,
> spooled files).
>
> The web server together with a particular CGI program constitute a service
> that allows the client to access data resources. This is not a web service.
> However, it is a service, and it is consumed by a browser client using HTTP
> messaging over a network.
>
> Communication between the client component and the server component via a
> service can, but does not have to, conform to REST architectural
> constraints.
>
> My original questions were how to handle authentication and authorization
> in this kind of web application while conforming to the statelessness
> constraint of REST.
>
> I hope that is a little clearer (if somewhat more "definitiony"). No more
> use of the term web service.
>
> Thanks,
> Kelly
>
>
> -----Original Message-----
> From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan
> Andelin
> Sent: Thursday, May 14, 2015 9:55 PM
> To: Web Enabling the IBM i (AS/400 and iSeries)
> Subject: Re: [WEB400] IBM i authentication and RESTful web service design
>
> Kelly,
>
> I feel a little badly about responding to this thread because I abandoned
> the CGI interface about 15 years ago. I'm torn between recommending a
> license to our web portal, or just dropping out of the discussion to let
> others explain the nuances of CGI interfaces.
>
> The program you use to authenticate users against your LDAP directory,
> which is the entry-point into your "system", needs to place "something"
> that represents each user's "authentication state" in a browser cookie, or
> a query string parameter, or some kind of "session" object on your server,
> which could be accessed by any CGI program which might be subsequently
> called.
>
> That begs the question - must every CGI program called subsequently check
> the user's "authentication state" for each an every subsequent request?
> I'll leave that to others to explain.
> --
> 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.
>
>