|
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 accountsmapped
to a single IBM i account, when they want multiple Windows accountsmapped
to multiple jobs (and possibly submitted or spawned jobs) all using aIs
single IBM i account, which is sort of the reverse of Paul's situation.
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.