The two first suggestions work fine for authentication combined with application layer security and auditing, but I agree the third suggestion doesn't sound like a very good fit for the node async model. It would be nice to have OS level user and resource security with auditing/journaling working in conjunction though rather than everything running as a generic application profile (for internal/non-public facing apps obviously).
-----Original Message-----
From: OpenSource [mailto:opensource-bounces@xxxxxxxxxxxx] On Behalf Of Justin Taylor
Sent: 24 October 2017 18:24
To: IBMi Open Source Roundtable
Subject: Re: [IBMiOSS] Node in-house auth?
That's sounds like a disaster waiting to happen.
-----Original Message-----
From: Mark Ford [mailto:Mark.Ford@xxxxxxxxxxx]
Sent: Tuesday, October 24, 2017 3:30 AM
To: IBMi Open Source Roundtable <opensource@xxxxxxxxxxxx>
Subject: Re: [IBMiOSS] Node in-house auth?
If the Kerberos routine that performs the authorisation returns you the user name (id@REALM) you can permit or deny actions in your application code via some sort of application authorisation/permissions file.
If you prefer to further authenticate the user has an actual IBM i ID you can use the eimGetTargetFromSource API to lookup the target ID from the source ID and verify it exists and is enabled.
If you actually want to perform the function under the authority of the IBM i user you could potentially perform a profile switch to the user, do the work, then switch back. Or in the case of database operations through the IBM API you might want to make the connection to the database as the user, issue the requests then disconnect. I should imagine there would be overhead with both of these approaches and there may be issues with async type operations and blocking. You wouldn't want the node process to start servicing a request for another user whilst still switched to the previous.
It makes you realise how much Apache is doing for you as it can take care of all of this by itself.
Disclaimer. I'm a sysadmin, not a developer, so these are just my thoughts/suggestions on an approach and these may or may not be practical.
Mark
nd think before you print this email.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/opensource.
Consider the environment and think before you print this email.
________________________________
Proud partner of The Ageas Bowl.
This email has been sent by and on behalf of one or more of Ageas (UK) Limited (registered no: 1093301 ), Ageas Insurance Limited (registered no: 354568), Ageas Retail Limited (registered no: 1324965), or a subsidiary of Ageas (UK) Limited (together “Ageas UK”). Ageas UK companies are registered in England and Wales, and each entity’s registered office is Ageas House, Hampshire Corporate Park, Templars Way, Eastleigh SO53 3YA.
Ageas Retail Limited is authorised and regulated by the Financial Conduct Authority. Financial Services Register Number: 312468.
Ageas Insurance Limited is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Financial Services Register Number: 202039
This e-mail together with any attachments are intended for the addressee only and may be private and confidential. If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, you must not open any attachments, or copy, disclose, distribute, retain or use this e-mail, including any attachments, in any way whatsoever; please return it to us immediately using the reply facility on e-mail.
Consider the environment and think before you print this email.
midrange.com
