Re: validation list usage scenario -- WEB400

Ah, thanks for that Jon, we neither use PHP or Apache (other than as a reverse proxy to Tomcat) so I know nothing about how either work in this respect.

I'm curious how people are using PHP these days, the last time I used it was years ago and it looked like a dreadful mess of SQL statements and business logic entangled in HTML templates. From what I'm reading here, it sounds like people are using PHP to create APIs for single page web apps, instead of as a templating engine for server-side rendering, but I guess this is a discussion for another thread....

________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Jon Paris <jon.paris@xxxxxxxxxxxxxx>
Sent: 23 August 2018 17:59
To: Web400@Midrange. Web400
Subject: Re: [WEB400] validation list usage scenario

"True, I didn't know PHP always runs under that user ..."

It doesn't - at least not any more so than any other method of providing web interfaces. As with anything else it has a default installed user (just like Apache jobs normally use QTMHHTTPn). A quick look at my main server via WRKACTJOB shows this:

SIDCSS QTMHHTTP BCI .0 PGM-php-cgi.bi
SIDCSS QTMHHTTP BCI .0 PGM-php-cgi.bi
SIDCSS TUOHYP BCI .0 PGM-QZSRCGI
SIDCSS HEALYP BCI .0 PGM-QZSRCGI
SIDCSS LANTZA BCI .0 PGM-QZSRCGI
SIDCSS LANTZT BCI .0 PGM-QZSRCGI
SIDCSS QTMHHTP1 BCI .0 PGM-QZSRCGI

The jobs running under specific users occur when a page that requires a valid system user Id is used and sign-in is enforced by Apache. The QTMHHTTPx pages are ones that require no signon. I didn't have any active jobs that were using validation lists at the time of this snapshot or they'd have shown as one of a number of other "non-people" users.

"With Tomcat you can configure the DB connection user and therefore can create a dedicated user and lock it down."

PHP Db2 connections are not really any different. You can use a generic Id, the one currently in use or a specific on for a specific user.

The point I'm trying to make here is that this is not fundamentally a PHP problem. It is a combination of Apache config and Db2 connections approaches.

I'm going to copy Alan Seiden on this because he is probably best able to advise on this - I'm guessing he's behind on his email or he'd have chimed in already.

Jon Paris

https://nam01.safelinks.protection.outlook.com/?url=www.partner400.com&data=02%7C01%7C%7Cb7a643cbe62948cb3ade08d60911828d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636706368139199534&sdata=S5G3xrwSlQqUqFaXp777YEPR3OU65%2FNeRlU8Dhj%2B09U%3D&reserved=0
https://nam01.safelinks.protection.outlook.com/?url=www.SystemiDeveloper.com&data=02%7C01%7C%7Cb7a643cbe62948cb3ade08d60911828d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636706368139199534&sdata=xGDLfLR6kDg8irBplsIL3nvqZelMw9YVm3XmtP%2BKmBY%3D&reserved=0

On Aug 23, 2018, at 4:33 AM, Tim Fathers <X700-IX2J@xxxxxxxxxxx> wrote:

Interesting project Steve! We're doing something similar but we use Angular for the front-end and our own backend instead of PHP and we recently switched from Bootstrap to Material for some projects.

Sounds like you really do need to switch profiles if you want spooled files and messages still going to the right users, always seems a bit risky to me because you have to, of course, be absolutely sure to switch them back again and it seems to leave a potential security hole.

Crossing threads a bit here bit in reply to this:

It would also enable any PHP script on the system, running as user profile
QTMHHTTP, to call that USER(*OWNER) program and switch to another user
profile.

True, I didn't know PHP always runs under that user as I've not used PHP on the IBM i before (and I'm not a big fan of PHP in any case). With Tomcat you can configure the DB connection user and therefore can create a dedicated user and lock it down. As I already explained, we use a token-based authentication system, which would get around this trust issue above, because the switching program would accept a token, which it could validate as being genuine, before proceeding with the switch. I think it would be pretty easy for you to generate a token when you authenticate the user, store it in the session state, and pass that to your backed as proof of id. As I mentioned, our token is just a data-structure containing the user id and a few other bits and bobs, including the expiry time which is then encrypted and converted to base-64. As the secret key is stored on the server, if we can decrypt a token then we know it can have only been generated by us (unless the key was comp

mised) and we accept it as proof of id. If I were you I would look at using a JSON Web Token, which is signed as opposed to encrypted and would be very easy to implement on the IBM i and can be done almost entirely in SQL.

________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Steve Richter <stephenrichter@xxxxxxxxx>
Sent: 22 August 2018 20:34
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] validation list usage scenario

Jon, I do not know enough about the apache config file. Don't think I am
totally dense.

where is the user entered that apache is talking about? Is that a basic
authentication user name?
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttpd.apache.org%2Fdocs%2F2.4%2Fhowto%2Fpublic_html.html&data=02%7C01%7C%7C041a6f2ffe6b4c00115d08d6085df712%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636705596997106956&sdata=eFiM59Ji4Wt%2ByiTq3adgpDEmuUO4O3gvz2h%2F2HVmP5Q%3D&reserved=0

I am writing SPA apps, using vue.js, where 95% of the code of the web app
is written in javascript and runs in the browser. Even the user login is a
bootstrap modal that drops down on the web page and prompts for user name
and password. I have had trouble using basic authentication in this type
of setting. So instead I handle the user name and pass prompt the same as
any other prompt. Send the data to the server as an $.ajax request. Only
the URL is a specific PHP file which validates the password against the
validation list and stores the values in $_SESSION variables.

What I want is to route both user profile users and validation list users
thru the same login and authentication process. Users in the office have
an IBM i profile. Sales reps might not. But sales reps are given access to
customer and orders web pages, same as users in the marketing and customer
service depts.

I want work done thru the web by user profile users to show up in database
journals under their user profile name. If they are running spooled
reports from the web that are being *SAVED, I want those spooled files to
be found under their profile. Same with messages sent to message queue.
And of course, authority to database tables controlled by object authority.

As far as validation list being less than a user profile - why? The
password is just as secure. There is attribute info that can be stored
along with the entry id and password in the validation list entry. ( have
not tested this )
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2Fssw_i5_54%2Fapis%2Fqsyavle.htm&data=02%7C01%7C%7C041a6f2ffe6b4c00115d08d6085df712%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636705596997106956&sdata=kM1GcUPdwGw4WBYSZb5JySOMtPkZSGzpMLq55WvJ9LA%3D&reserved=0
If that attribute info stores the user profile name, why not set the user
profile password to the same as the validation list entry? Then when I
authenticate against the validation list I can switch to the user profile
name stored as a validation list attribute.

If programmers were writing IBM i apps from scratch today there would be no
green screen login. Minimal batch work. All web apps. Would all that work
be running thru just a handful of user profiles?

On Wed, Aug 22, 2018 at 1:34 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

It seems as if you are making this WAY more complicated than it need be
Steve.

We don't (and wouldn't) use a regular user profile in a validation list.
Validation list users do not use the system in the normal sense. It is just
a way of grouping together web users who have no need for a conventional
sign on with all the associated security considerations. For a given group
of web users we assign a specific user profile (identified in the apache
config) to the group. That controls what they can do. Apache takes care of
the switch.

When the user signs in we store the user Id in the session. No need to
store the password - we don't need it. If we need to log any of the actions
as specific to a user we use the stored user Id.

That's it. All security is via the user Id associated with the validation
list group.

What more do you need?

Jon Paris

https://eur01.safelinks.protection.outlook.com/?url=www.partner400.com&data=02%7C01%7C%7C041a6f2ffe6b4c00115d08d6085df712%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636705596997106956&sdata=aEn%2BPpCTK4sDCz9ozF7zu6v172Pe7czhjaRjSNJKeAI%3D&reserved=0
https://eur01.safelinks.protection.outlook.com/?url=www.SystemiDeveloper.com&data=02%7C01%7C%7C041a6f2ffe6b4c00115d08d6085df712%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636705596997106956&sdata=Gno3IIY95WldRXrlhORfrsaxOJ4Bjw7v5ypeTEy4e%2BE%3D&reserved=0

On Aug 22, 2018, at 11:03 AM, Steve Richter <stephenrichter@xxxxxxxxx>

wrote:

is it secure to have a user profile name associated with a validation

list

entry name, and then have the user enter the same password in the
validation list as they do for their IBM i user profile.

The PHP code of a web site could store the validation list user and
password in $_SESSION variables. Then as part of validating to the
validation list, check if the validation list user name has an IBM i user
profile associated with it.

If it does, call QSYGETPH with that user profile name and the validation
list password. If the password is accepted, call QWTSETP to switch to

run

the PHP code as that user profile.

assuming you are running HTTPS, what are security problems with doing

this?

thanks,
--
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: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7C041a6f2ffe6b4c00115d08d6085df712%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636705596997106956&sdata=5ZrzPHCp8nJzKDESxSFutPiomf1vPM8XwJn8sDdIijk%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7C041a6f2ffe6b4c00115d08d6085df712%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636705596997106956&sdata=%2Bv6riKxYAZl1qK93OW9maEBHSNBV7%2FlhQaQGTvixOxg%3D&reserved=0.

--
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: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7C041a6f2ffe6b4c00115d08d6085df712%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636705596997106956&sdata=5ZrzPHCp8nJzKDESxSFutPiomf1vPM8XwJn8sDdIijk%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7C041a6f2ffe6b4c00115d08d6085df712%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636705596997106956&sdata=%2Bv6riKxYAZl1qK93OW9maEBHSNBV7%2FlhQaQGTvixOxg%3D&reserved=0.

--
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: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7C041a6f2ffe6b4c00115d08d6085df712%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636705596997106956&sdata=5ZrzPHCp8nJzKDESxSFutPiomf1vPM8XwJn8sDdIijk%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7C041a6f2ffe6b4c00115d08d6085df712%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636705596997106956&sdata=%2Bv6riKxYAZl1qK93OW9maEBHSNBV7%2FlhQaQGTvixOxg%3D&reserved=0.

--
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: https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7Cb7a643cbe62948cb3ade08d60911828d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636706368139199534&sdata=Z99h4PQ7Xu95MywHoci2bmtVQEC6AS8OcT%2B5qwM%2FJxM%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7Cb7a643cbe62948cb3ade08d60911828d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636706368139199534&sdata=sfXw%2BEYDgnqzpdYu7hZEOn18YVxsHKdwNV8jvsyuVnI%3D&reserved=0.

--
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: https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7Cb7a643cbe62948cb3ade08d60911828d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636706368139199534&sdata=Z99h4PQ7Xu95MywHoci2bmtVQEC6AS8OcT%2B5qwM%2FJxM%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7Cb7a643cbe62948cb3ade08d60911828d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636706368139199534&sdata=sfXw%2BEYDgnqzpdYu7hZEOn18YVxsHKdwNV8jvsyuVnI%3D&reserved=0.