Re: RPG program - Kerberos Authentication

Hi Jim

The EIM setup has to be done sometime. You first need the IBM i user profile mapping to the respective Windows user.

Then you need to map the application user names to the respective Windows user.

The 2nd one, especially, can be done programmatically - the EIM APIs are available to add identities - the EIM term for a "person", who has different names in different contexts.

The challenge is knowing which Windows user to map to, but once the system EIM stuff is in place, one can pull the Windows user names, then have a selection process on installation.

I think!!

The main thing is to think about an "application registry". I was slow on the uptake - it only took at least 3 times attending Pat Botz' COMMON presentations to get out of the weeds.

The registry is just basically a list of names - it would be the target in EIM terms, the Windows EIM registry would be the source. I kept thinking I somehow had to store the application user file in EIM but no, just the names and then do the associations.

Good luck, man! This stuff can be really powerful, I think.

Vern

On 4/1/2020 5:22 AM, Jim Oberholtzer wrote:

Vern:

Can the EIM registration happen during package installation
programmatically or would it require manual intervention. Does the EIM
domain need to be there prior to the registration or are those separate
items? Where does the LDAP server come into the scenario ?

I’m going to look at this. Might solve a problem for another customer.
I never thought to use it this way.

On Tue, Mar 31, 2020 at 10:10 PM Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

He wants a single Windows principle mapped to a user defined in the
applications authority mapping. This can be done with EIM and the APIs
for that. IIRC, you make target associations that are for the
application - and you use EIM APIs to connect into EIM and see if the
user name that is used for your application is a target where the source
is Windows - and because you trust the authentication from Windows, you
trust that user and authorize them according to the application's rules.

Remember, there are 2 aspects to security - authentication (who is it)
and authorization (what can they do on this playground). Windows takes
care of authentication and you can trust it (that's Kerberos), so now
all your application does is handle the authorization. You used to do
both, such as having a password for the application, in addition to that
of Windows.

I remember now - you add an "application registry" to EIM - this is
where you simply put the user names in your application - they do NOT
have to be the same as their IBM i user or their Windows user.

Application registries are subsets of system registry - IBM i is a
system registry, a target type, I believe.

Here is the essential framework for an application as described by IBM -

Applications that use these APIs to manage or use the EIM information in
an EIM domain typically adhere to the following programming model:

1. Get an EIM handle
2. Connect to an EIM domain
3. Normal application processing (this could be what leads to the login
of the user to the application)
4. Use an EIM administration or EIM identity mapping lookup operation API
5. Normal application processing (this could begin with the normal
authorization - what can the user do in the application)
6. Before ending, destroy the EIM handle

EIM copy member can be found in QRPGLESRC in QSYSINC - the C/C++ copy
member is in file H in the same library.

There is a knowledge center link at
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/sec5.htm

This whole application registry is very powerful and might be less known
- it'll do what the OP wants to do. I've done it myself for a web
application where Apache authentication used SSO but we still had
authorization to apply in the application.

HTH
Vern

On 3/31/2020 6:44 PM, Kevin Wright wrote:

And in this situation they want to have a multiple Windows accounts

mapped

to a single IBM i account, when they want multiple Windows accounts

mapped

to multiple jobs (and possibly submitted or spawned jobs) all using a
single IBM i account, which is sort of the reverse of Paul's situation.

Is

it similarly not possible to use SSO?

Kevin

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Steinmetz, Paul via RPG400-L
Sent: Wednesday, 1 April 2020 9:47 AM
To: 'rpg400-l@xxxxxxxxxxxxxxxxxx' <rpg400-l@xxxxxxxxxxxxxxxxxx>
Cc: Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>
Subject: RE: RPG program - Kerberos Authentication

Keep in mind, SSO works with a single Windows account being mapped to a
single IBM I account.
This is accomplished with the EIM mapping entries.
We are using SSO, and have users that have multiple IBM I accounts.
Those users cannot use SSO.

Paul

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Javier
Sánchez
Sent: Tuesday, March 31, 2020 6:39 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: RPG program - Kerberos Authentication

I understand that once you set your IBM i in the pertinet realm, users
would have access to the system instead of logging in using their ID's
and passwords. The EIM is to map them into the system. At the
application level, it's likely that you may have to do some additional
stuff. whether you need to control some other issues related to the
outside. But in general, once your users' ID's are given the
appropriate rights to systems resources, applications, etc., the only
thing that is different is logging in.

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com