Re: IBM i authentication and RESTful web service design

Hi Henrick,

The HTTP methods are part of the uniform interface constraint of REST. The ideal situation would be to use all of the HTTP verbs, respecting their safeness and idempotence as defined in the HTTP standard, so the interface would remain truly standard in all respects. I agree with you that most people only use the GET and POST methods. This means people usually "overload" the POST method to perform functions used by the other HTTP methods. I am required to overload the POST method to use CGI programming, since GET and POST are the only methods recognized in CGI. One can still conform to other aspects of the uniform interface even if one only uses the GET and POST methods for requests.

However, statelessness is a separate architectural constraint of REST. It does not have to do with the uniform interface. Statelessness means the server does not store any contextual information related to a client request. Each client request has to contain everything needed for the server to understand and process the request. Any information about a client session has to be stored and managed on the client side. Fielding describes statelessness in the following two paragraphs in his dissertation (pp. 78-79):

"We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), 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."

So statelessness does not have to do with HTTP methods or the uniform interface. The problem is, If a web application stores information for authentication and authorization on the server side, then it is violating statelessness because the server is trying to manage a client session--which is supposed to be managed by the client under REST. That's why I was asking about authentication and authorization under constraints of statelessness.

Thanks,
Kelly


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Henrik Rützou
Sent: Friday, May 15, 2015 2:45 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] 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.
>
>


--
Regards,
Henrik Rützou

 http://powerEXT.com <http://powerext.com/>
--
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.